Posts by Dr. Seltsam

    So I still think about a solution for the problem regarding 24 and 50Hz videos, Right now one has to start Kodi just because of this ...

    You could add a line to your commands.conf, calling a script like

    Bash
    #!/bin/bash
    export DISPLAY=:0
    xrandr --output HDMI-0 --mode 1920x1080 --rate 24

    That assumes that you already know the correct rate.

    When I used the mplayer-Plugin to start mpv, I called their mpv-identify-Script. Have a look in HowTo: mplayer-Plugin mit mpv (mplayer-fork) benutzen

    There was a time when linuxtv had a git which provided a media_build for using current drivers with older kernel versions. This git is no longer maintained. The official statement was that there haven't been any new devices for a long time. If one can use a not too old kernel, than this is the best way. Only in rare cases it is necessary to backport new derivers to old kernel versions. This applies to ARM-Boxes with amlogic-Chipset. They use a special 4.9 kernel with proprietary drivers.

    Ich halte einen Hardwaredefekt der S2-6400 für am wahrscheinlichsten. Kannst Du sie in einem Windows-Rechner gegenprüfen?

    Die gesamte Audioverarbeitung findet m.E. innerhalb der Karte statt, es kämen also nur Treiber oder Plugin in Frage. Die sind aber proprietär und werden nicht bei einem Systemupdate (sofern überhaupt eines stattfand) verändert bzw. erneuert. Wenn der Fehler von heute auf morgen aufgetreten ist, spricht das eher für ein Hardwareproblem.

    Bei "radio" habe ich vor ein paar Tagen schonmal eine Anfrage hier gestellt: https://github.com/siricco/vdr-plugin-radio/issues/1

    Zwei Jahre Inaktivität sieht für mich da aus als wäre das auch "verwaist". Ich würde dann nach einem Monat Wartezeit die Änderungen dort in einen Pull Request verpacken und nach https://github.com/vdr-projects/vdr-plugin-radio übertragen welches dann auch "Community maintained" wäre.

    Das ist das git des leider 2022 verstorbenen HelmutB.

    Beim Radio-Plugin haben wir die Situation, dass es neben seinem Fork, dessen Entwicklung hier diskutiert wurde, noch den älteren Stand von Ulrich Eckhardt gibt, wo aber seit 7 Jahren nichts mehr passiert ist.

    Dein Vorschlag klingt für mich sinnvoll.

    Starte ich am gleichen PC den easystream kommt der Ton normal an,
    obwohl es über den gleichen Receiver geht.

    Gibt easystream den Ton auch über die FF-Karte aus? Oder erfolgt das über das Mainboard, und Du wählst dann einen anderen Eingang am Yamaha? Laut Deiner Signatur hast Du ja auch Kodi auf dem Rechner mit Ausgabe über Mainboard. Funktioniert dort der Stereoton? Du kannst ja das Video-Verzeichnis des vdr als Quelle in Kodi hinzufügen und dann direkt eine TS-Datei abspielen.

    Um zu prüfen, ob die Tonausgabe der FF-Karte das Problem ist, kannst Du ihren HDMI-Ausgang auch mal direkt in den TV statt in den AVR stecken. Wenn der TV den Stereoton dann korrekt wiedergibt, liegt es wohl am AVR.

    Gegenprobe am AVR: Gibt er Stereoton von anderen Geräten mit HDMI-Ausgabe korrekt wieder? Macht aber nur Sinn, wenn auch Kodi mit HDMI-Ausgabe über Mainboard die gleichen Probleme hat. Dann brauchst Du ein unabhängiges Gerät, um etwaige Probleme mit gemeinsam von vdr und Kodi genutzten Bibliotheken auszuschließen.

    Hat jemand mal geprüft, ob diese keys wirklich aufgerufen werden oder einfach toter code sind?


    --switch(Key) {
    ++switch (int(Key)) {

    Zumindest beim mp3- Abspielen sollten die u.a. zum Springen noch benutzt werden. Bei dem ebenfalls im Plugin enthaltenen mplayer-Code dürfte das nur eine Rolle spielen, wenn mplayer im Slave-Modus benutzt wird. Das war nach meiner Erinnerung auf Code für die alten FF-Karten beschränkt. Benutzt noch irgendwer mplayer heutzutage? Ich hatte das mplayer-Plugin lange Zeit zum scriptbasierten Abspielen mittels mpv benutzt. Muss aber gestehen, dass ich dafür inzwischen Kodi benutze.

    Beschreib doch mal den Server, auf dem Du die dualHD angeschlossen hattest. Mit welchem Programm erzeugst Du dort Streams für den Client?

    tvheadend?

    minisatip?

    ??

    Welches Ausgabedevice verwendest Du auf dem Client? Und wie empfängst Du dort den Stream von der dualHD? Mit dem satip-Plugin? Wenn ja, welche Version? Es gibt eine verbesserte Version von Wirbel.

    Bei minisatip auf dem Raspi 4 (Gigabit-LAN) und vdr+satip-Plugin auf dem Client (100 MBit LAN) hatte ich erhebliche Probleme. Das funzte nur mit einem Gigabit-fähigen Client. Ansonsten gibt es eigentlich nur einen weiteren Fallstrick, der mir einfällt: Es ist bei sei satip zwingend eine 1:1-Zuordnung Tuner zu Client notwendig. Wenn minisatip mit der dualHD zwei Tuner bereitstellt, kannst Du einem Client 2 satip devices zuordnen. Oder zwei Clients je ein satip-device. Was nicht geht ist, ist eine dynamische Nutzung. Wenn bei einem Client 2 satip-devices konfiguriert sind, sind am Server beide devices besetzt und ein weiterer Client kriegt keinen Empfang - auch dann nicht, wenn der erste Client vermeintlich nur einen Tuner benutzt. Stichwort egp-Hintergrundscan!

    Ich würde zum Justieren lieber einen DVB-Receiver mit Signalstärkeanzeige nehmen. Ich weiss nicht, wie es bei den command-line-Tools ist, aber vdr + Ausgabeplugin haben da zuviel Buffer - die Auswirkungen einer Ausrichtungsveränderung kommen zeitverzögert im OSD an.

    Die Kräfte des Sturms wirken zwar primär auf den Azimuth (links-rechts), können aber ggf. auch auf die Elevation (Höheneinstellung des LNB-Arms) gewirkt haben. Ist die Schüssel an einem Mast befestigt? Steht dieser noch exakt senkrecht, oder hat er sich in seiner Halterung gelöst und hat Schieflage? Immer erst den Mast exakt senkrecht justieren und die Schüssel dann am Mast verstellen. Niemals einfach den Mast drehen. Sitzt das Quattro-LNB richtig in der Aufnahme der Antennenhalterung? Rein mechanisch lässt es sich oft in verschiedenen Stellungen festschrauben. Optimalen Empfang bringt es nur im Brennpunkt. Es sind zwar meist nur wenige Zentimeter Spiel, aber ruhig mal dichter zur Antenne schieben oder oder weiter weg. Wichtiger ist die Kreuzpolarisationsentkopplung. Der Winkel, in dem das LNB montiert wird (auch Skew genannt), ist dafür entscheidend. Hier gehen die Angaben nun auseinander. Die meisten Quellen sagen, die Astra-Satelliten hätte bereits eine eingebaute Korrektur, so dass man in der Kernausleuchtzone das LNB mit nahezu 0 Grad (exakt senkrecht nach unten führendem Kabel) montieren kann. Siehe https://www.satlex.de/de/faq_install…l_lnb_tilt.html

    Ich meine aber auch schon gelesen zu haben, dass diese Grundkorrektur teilweise auch in den LNBs schon eingebaut ist, was aber ja nur Sinn machen würde, wenn diese ausschließlich für Astra-Empfang gedacht sind. Deshalb glaube ich das nicht so recht.

    Die letzten Schüsseln habe ich vor vielen Jahren montiert, und dabei war es eigentlich immer so, dass der beste Empfang mit einer leichten Schräglage (wahrscheinlich um 7 Grad) des LNB erreicht wurde.

    Off Topic - Kuriose Randnotiz: Bei einer Baumarkt-Antenne eines Freundes bin ich mal verzweifelt. Die einzige Stellung, in der beide Polarisationsebenen empfangen wurden, war mit schräg nach oben geführten Anschlusskabeln. Ich rätsele heute noch, ob das ein Fabrikationsfehler im LNB war, oder ein LNB, das eine eingebaute Skew-Korrektur für die südliche Halbkugel hatte. Keine Ahnung, ob es sowas überhaupt gibt.

    Welche vdr-Version wird verwandt? Eventuell liegt es daran, dass vdr < 2.6.8 den gescannten Kanal mit einer falschen stream-id überschreibt. Das ganze hatten wir kürzlich, Licht ins Dunkel kam dann ab hier

    SHF
    May 26, 2024 at 10:30 PM

    uff.

    Der log level steht schon auf 3. Ich kriege nur diese Meldungen:

    Code
    Dec 01 14:10:20 CoreELEC kernel: fb: clear: osd 0
    Dec 01 14:10:21 CoreELEC vdr[4242]: [4242] [softhddev]CreateOsd: left 130, top 752, level 0, using OpenGL OSD support
    Dec 01 14:10:21 CoreELEC vdr[4242]: [4242] [softhddev]cOglOsd osdLeft 130 osdTop 752 screenWidth 1920 screenHeight 1080
    Dec 01 14:10:22 CoreELEC kernel: fb: clear: osd 0

    hier erstmal meine Konfiguration:

    ein paar Werte von vdr:

    Code
    OSDSkin = nOpacity
    OSDTheme = lightblue
    OSDMessageTime = 1
    ProgressDisplayTime = 0
    ChannelInfoTime = 5

    Moin Kamel,

    eins stört mich schon länger: Wenn man während einer Wiedergabe die ok-Taste zum Einblenden des OSD (Fortschrittsbalken) drückt, kann man das OSD normalerweise mit einem zweiten Druck auf die ok-Taste sofort wieder schließen. Das klappt nicht immer - manchmal muss man mehrere Sekunden warten, ehe ein erneuter Druck das OSD schließt. Ich habe mit mehreren Skins und allen möglichen Werten für Ein- und Ausblendezeiten experimentiert, aber der Fehler tritt immer wieder auf. Üblicherweise reicht es, 5-10 mal die OK-Taste im Wechsel zu drücken, um ihn zu provozieren. Es tritt aber manchmal auch schon beim ersten Schließen (also zweiter Druck) auf.

    Beim Live-TV gibt es bei der Anzeige der Kanalinformation dieses Problem nach meiner Beobachtung hingegen nicht.

    Vielleicht kannst Du Dir das mal anschauen.

    Ich mache das ganz quick and dirty im chroot-System in der runvdr vor dem Start von vdr.

    (CoreElec startet beim Booten vdr in chroot)

    Der erste check prüft, ob CE eine externe Platte erkannt hat (device node vorhanden). Es wird unterstellt, dass das immer der Fall sein sollte.

    Der zweite check führt beim ersten Aufruf der runvdr immer dazu, dass die Platte innerhalb der chroot-Umgebung in /srv gemounted wird. Auf den erfolgreichen Abschluss des Mountens (die auf der Platte unterhalb srv vorhandenen Ordner sind dann vorhanden) wird abschließend dann nochmal gewartet.

    Wenn die Platte nicht dranhängt oder aus anderem Grund nicht eingebunden werden kann, kommt vdr nicht hoch. Dann weiss ich, wo ich suchen muss.

    Das Problem tritt schon ewig auf, obwohl ich regelmäßig den Ordner lösche und das Plugin mit git clone neu auschecke. Das klappt immer reibungslos. Nur wenn Änderungen vorliegen und ich die mit git pull übernehmen will, kommt die Meldung.

    Ich habe mal die Makefiles von skinflatplus mit vdr und anderen Plugins verglichen. Dabei fielen mir diese Unterschiede auf:

    Das minus bezieht sich auf skinflatplus und das plus auf andere Makefiles. Kann es damit zu tun haben?