Posts by zimuland

    Hallo,

    vor einiger Zeit habe ich die neue Version 2.4.1 installiert. Danach kamen mehrmals unerklärliche Konfliktmeldungen, ich hatte aber keine Zeit das näher zu untersuchen.


    Inzwischen konnte ich den Fehler reproduzieren. Die Fehlalarme betreffen unverschlüsselte Sender.

    Im System sind drei DVB-Karten vorhanden. Es werden vier Timer auf drei Transpondern angelegt. Mit der Version 2.4.0 werden keine Konflikte angezeigt (VDR-Version ist 2.4.7.). Mit der neueen Version wird der erste Timer auf Karte 2 gestartet. DIe zweite Aufnahme auf dem gleichen Transponder wird vom epgsearch der Karte 3 zugeordnet, vom VDR aber wie erwartet ebenfalls auf Karte 2 gestartet. Die letzten beiden Timer brauchen dann jeweils eine eigene Karte.

    channels.conf

    Das Erste:338000:C0M256:C:6900:101=2:102=deu@3,103=mis@3;106=deu@106:104;105=deu:0:28106:1:1101:0

    ZDF:450000:C0M256:C:6900:110=2:120=deu@3,121=mis@3,122=mul@3;125=deu@106:130;131=deu:0:28006:1:1079:0

    rbb Berlin;ARD:458000:C0M256:C:6900:601=2:602=deu@3,603=mis@3:604:0:28206:1:1073:0

    3sat:450000:C0M256:C:6900:210=2:220=deu@3,221=mis@3,222=mul@3;225=deu@106:230;231=deu:0:28007:1:1079:0


    timers.conf

    1:C-1-1079-28007:2021-12-06:1755:1800:50:99:3sat:<epgd><timerid>2415</timerid></epgd>

    1:C-1-1079-28006:2021-12-06:1756:1800:50:99:ZDF:<epgd><timerid>2416</timerid></epgd>

    1:C-1-1073-28206:2021-12-06:1757:1800:50:99:rbb Berlin:<epgd><timerid>2417</timerid></epgd>

    1:C-1-1101-28106:2021-12-06:1758:1800:50:99:Das Erste:<epgd><timerid>2418</timerid></epgd>


    epgsearch.log

    Gruß Zimuland

    Das SetVolumeDevice() kam ja ursprünglich schon durch den Patch von MarkusE rein. Ich habe in meiner Variante jetzt nur noch die Unterscheidung mit IsMute() ergänzt. Ohne das SetVolumeDevice() wird die Lautstärke bei mir aber jedem Kanalwechsel auf einen Default-Wert gesetzt, nicht nur wenn man einen externen Player nutzt. Mir war das auch nur aufgefallen, weil ich den Ton beim letzten Test ziemlich leise eingestellt hatte.
    Die Umschaltzeiten liegen mit SetVolumeDevice() bei HD-Sendern auf dem gleichen Transponder bei etwa zwei Sekunden und bei unterschiedlichen Transpondern bei reichlich drei Sekunden. Getestet habe ich mit einen Terratec Cinergy HTC Stick mit DVB-C mit einem Raspi 3.

    Vielen Dank für Deine ausführliche Analyse. Deine Version des Patches löst das Problem im Endeffekt ebenfalls.

    Das Setzen vom m_playMode hätte ich aber noch in den Lock() verschoben.


    Code
    1.     m_playMode = PlayMode;
    2. m_mutex->Unlock();
    3.     return true;
    4. }



    Quote

    ich finde keine Stelle im Plugin, wo dabei auch m_playmode auf 5 gesetzt wird!

    Das SetPlayMode() wird direkt vom VDR aufgerufen und kommt wahrscheinlich von dieser Zeile im mplayer-Plugin:

    Code
    1. cMPlayerPlayer::cMPlayerPlayer(const cFileObj *File, bool Rewind)
    2. :cPlayer(pmExtern_THIS_SHOULD_BE_AVOIDED)
    3. {


    Quote

    Das TV-Bild kommt nach dem Beenden des mplayer-Plugins trotzdem normal zurückt? Das ist interessant: Nach einem Kanalwechsel im Plugin selbst will die Hardware neu initialisiert werden, aber nach Verwendung des externen omxplayers ist das nicht nötig.

    Die Initialisierung findet ja trotzdem statt. Nach dem Beenden des Plugins wird wieder zuerst pmNone und danach pmAudioVideo gesendet.


    Quote

    ich habe hier übrigens SetVolumeDevice(CurrentVolume()); rausgelassen, denn der Sinn im ursprünglichen Patch erschließt sich mir nicht. Es würde ja dazu führen, dass ein vorher stumm gemuteter vdr beim Kanalwechsel wieder laut wird.

    Das war mir bisher noch gar nicht aufgefallen, ist aber tatsächlich so.

    Der Ton scheint aber nach der Reinitialisierung immer an zu sein. Damit sorgt der Aufruf im Endeffekt nur dafür, dass die im VDR eingestellte Lautstärke verwendet wird. Damt sollte die folgende Variante korrekt sein, damit das Mute auch beibehalten wird:

    Code
    1. SetVolumeDevice( IsMute() ? 0 : CurrentVolume() );


    Quote

    Das Resetten findet hier also komplett in pmNone statt und damit auch bei jedem Kanalwechsel. Keine Ahnung, ob das Umschaltproblem damit auch gelöst ist und ob es Einfluss auf die Umschaltdauer hat.

    Das führt im Fall von pmExtern_THIS_SHOULD_BE_AVOIDED im Endeffekt dazu, dass eine Initialisierung durchgeführt wird, die am Ende nicht gebraucht wird.


    Das pmExtern_THIS_SHOULD_BE_AVOIDED im Plugin nicht behandelt wird ist meiner Meinung nach so gewollt, da ja der externe Player alle Arbeit übernimmt. Die Variable m_playMode bleibt auf pmNone, bis sie in PlayAudio() oder PlayVideo() auf den entsprechenden Mode gesetzt wird. Wurde keine dieser Funktionen aufgerufen ist wahrscheinlich auch kein FlushStreams() notwendig.

    Hallo,

    bei der Verwendung des mplayer-Plugins (mit omxplayer-patch) gibt es auch das Problem, dass beim Beenden des Plugins der VDR neu startet.


    Beim Start des Plugins wird SetPlayMode() zurerst mit 0 (pmNone) und danach mit 5 (pmExtern_THIS_SHOULD_BE_AVOIDED) aufgerufen.

    Beim Beenden des Plugins folgt dann wieder ein Aufruf mit 0 (pmNone). Dabei kommt es beim Aufruf von FlushBuffers() zum Absturzin in SetClock() bzw. ResetClock() aufgrund eines Null-Pointers.


    Dieser modifizierte Patch hat das Problem für mich gelöst: rpihddevice-fix_playmode_zimuland.patch


    Gruß Zimuland

    Hallo zusammen,


    nachdem ich schon ein paar mal bei "Das Erste HD" keinen Ton hatte und dann auf "Das Erste" ausgewichen bin, konnte ich am Samstag mal eine Aufnahme davon machen.


    Beim Abspielen der Aufnahme mit VLC war der Ton vorhanden. Also habe ich mich mal auf die Suche nach der Ursache des Problems gemacht.


    Code
    1. Input #0, mpegts, from '00001.ts':
    2. Duration: 00:05:00.11, start: 46217.329656, bitrate: 9124 kb/s
    3. Program 132
    4. Stream #0:0[0x13ed]: Video: h264 (High) ([27][0][0][0] / 0x001B), yuv420p(tv, bt709, progressive), 1280x720 [SAR 1:1 DAR 16:9], 50 fps, 50 tbr, 90k tbn, 100 tbc
    5. Stream #0:1[0x13ee](deu): Audio: ac3 ([6][0][0][0] / 0x0006), 48000 Hz, 5.0(side), fltp, 448 kb/s
    6. Stream #0:2[0x13ef](mis): Audio: ac3 ([6][0][0][0] / 0x0006), 48000 Hz, stereo, fltp, 192 kb/s
    7. Stream #0:3[0x13f1](deu): Subtitle: dvb_subtitle ([6][0][0][0] / 0x0006) (hearing impaired)


    Hier wird im ersten Audio Stream ein Channel Layout 5.0 genutzt, das von rpihddevice nicht unterstützt wird. Der folgende Patch hat das Problem für mich gelöst.



    Gruß Zimuland

    Hat jetzt nicht direkt mit deinem Problem zu tun, aber es würde mich interessieren, wieso es in den Logmeldungen ': Doku~Terra X' (mit Doppelpunkt und Blank) heißt, die Timer-Definition aber "Doku~Terra X" (ohne Doppelpunkt und Blank) lautet.

    Das liegt wahrscheinlich nur daran, dass ich die Timerdefinition nicht aus der timers.conf kopiert habe. Das Verzeichnis heißt wirklich ": Doku", damit es immer am Anfang der Aufnahmeliste steht.

    Ich habe es jetzt erstmal auf 8640 (6 Tage) gestellt. Damit fällt ja schon das Event von letzter Woche Samstag raus. Wie erwartet funktioniert dann nach einem Neustart des VDR auch der EPG-Scan wieder.


    Hier noch die entsprechenden Log-Einträge:


    Vorher:

    Jan 30 15:15:53 WS-E-DEBIAN vdr: [10794] timer 1 (2 1930-2015 VPS ': Doku~Terra X') set to event Son 24.01.2021 19:30-20:15 (VPS: 24.01. 19:30) 'Terra X'

    Jan 30 15:15:53 WS-E-DEBIAN vdr: [10794] timer 2 (1 1600-1630 VPS ': Doku~W wie Wissen') set to event Sam 23.01.2021 16:00-16:30 (VPS: 23.01. 16:00) 'W wie Wissen'

    Jan 30 15:15:56 WS-E-DEBIAN vdr: [10794] timer 1 (2 1930-2015 VPS ': Doku~Terra X') set to event Son 31.01.2021 19:30-20:15 (VPS: 31.01. 19:30) 'Terra X'


    Nach der Änderung:

    Jan 30 15:17:44 WS-E-DEBIAN vdr: [10879] timer 1 (2 1930-2015 VPS ': Doku~Terra X') set to event Son 24.01.2021 19:30-20:15 (VPS: 24.01. 19:30) 'Terra X'

    Jan 30 15:17:47 WS-E-DEBIAN vdr: [10879] timer 1 (2 1930-2015 VPS ': Doku~Terra X') set to event Son 31.01.2021 19:30-20:15 (VPS: 31.01. 19:30) 'Terra X'

    Die Kanalnummer 1 ist "Das Erste" und 2 ist "ZDF". Beide sind auf unterschiedlichen Transpondern. Beim Start des VDR schaltet er automatisch auf Kanal 1.

    Das ganze läuft am Kabelanschluss. Das EPG ist je nach Sender für die nächsten 3 bis 6 Tage verfügbar.


    channels.conf

    Das Erste;ARD:338000:C0M256:C:6900:101=2:102=deu@3,103=mis@3;106=deu@106:104;105=deu:0:28106:1:1101:0

    ZDF;ZDFvision:450000:C0M256:C:6900:110=2:120=deu@3,121=mis@3,122=mul@3;125=deu@106:130;131=deu:0:28006:1:1079:0


    timers.conf

    5:C-1-1079-28006:------S:1930:2015:50:99:| Doku~Terra X:

    5:C-1-1101-28106:-----S-@2021-01-31:1600:1630:25:99:| Doku~W wie Wissen:


    Ich hatte das Problem vor zwei oder drei Wochen schon einmal.

    In der Programmübersicht war mir aufgefallen, dass dort bei den Sendern die ich nicht regelmäßig nutze noch Sendungen vom Vortag angezeigt wurden. Wenn man dann auf diesen Sender umschaltet wird auch das EPG aktualisiert.

    Danach hatte ich dann ohne Erfolg nach und nach alle Plugins deaktiviert und jeweils den EPG-Scan über das Menu und das SVDRP-Kommando gestartet.

    Am Ende hat das Löschen der Datei epg.data erstmal zum Erfolg geführt. Danach füllte sich das EPG wieder ohne auf den Sender umschalten zu müssen.


    Ich vermute, dass das Problem bei mir durch die doch recht große EInstellung "Alte EPG-Daten anzeigen (min): 10080" verursacht wird. Ich hatte das mal irgendwann auf 7 Tage eingestellt um nachvollziehen zu können, warum etwas nicht aufgenommen wurde und bis heute einfach so belassen.

    Hallo,


    nach dem Update des VDR von 2.2.0 auf 2.4.6 ist mir aufgefallen, dass manchmal keine automatische Aktualisierung des EPG mehr stattfindet. Jetzt konnte ich den Fall reproduzieren:


    Es sind wöchentliche VPS-Timer gesetzt:


    2 ------S 19:30 20:15 Doku~Terra X

    1 -----S- 16:00 16:30 Doku~W wie Wissen


    Die Timer werden beim Start des VDR zuerst auf das bereits vergangene Event gesetzt, dabei ist "Alte EPG-Daten anzeigen (min):" auf 10080 (7 Tage) eingestellt:


    Jan 25 19:59:56 WS-E-DEBIAN vdr: [1994] timer 1 (2 1930-2015 VPS ': Doku~Terra X') set to event Son 24.01.2021 19:30-20:15 (VPS: 24.01. 19:30) 'Terra X'

    Jan 25 19:59:56 WS-E-DEBIAN vdr: [1994] timer 2 (1 1600-1630 VPS ': Doku~W wie Wissen') set to event Sam 23.01.2021 16:00-16:30 (VPS: 23.01. 16:00) 'W wie Wissen'


    Danach wird der eine Timer auf das kommende Event gesetzt. Für den anderen Timer funktioniert das nicht, weil der nächste Termin wegen einer Sportübertragung ausfällt.


    Jan 25 19:59:58 WS-E-DEBIAN vdr: [1994] timer 1 (2 1930-2015 VPS ': Doku~Terra X') set to event Son 31.01.2021 19:30-20:15 (VPS: 31.01. 19:30) 'Terra X


    Anschließend wird kein EPG-Scan ausgeführt, obwohl 3 DVB-Karten vorhanden sind und keine Aufnahme läuft. Auch ein manuelles Starten des Scans bringt keinen Erfolg.



    Wenn man dann den ersten Tag für den Timer 2 auf den 31.01.2021 setzt startet der EPG-Scan.


    Jan 26 23:24:26 WS-E-DEBIAN vdr: [21275] modified timer 2 (1 1600-1630 VPS ': Doku~W wie Wissen')

    Jan 26 23:24:26 WS-E-DEBIAN vdr: [21275] timer 2 (1 1600-1630 VPS ': Doku~W wie Wissen') set to no event



    Dabei ist mir auch noch aufgefallen, dass auch das Deaktivieren des Timers mit der roten Taste in diesem Fall nicht funktioniert.



    Gruß Zimuland

    Den Kernel kann man per rpi-update installieren.

    Wichtig sind die Header-Files!

    Ich habe mir den Source heruntergeladen und daraus die Header-Files erstellt. Eine einfachere Möglichkeit habe ich nicht gefunden.

    Ich kann mich erinnern, dass es analog zu rpi-update auch noch ein rpi-source zum Update der Kernel-Sourcen gab. Allerdings habe ich das schon lange nicht mehr benutzt.

    Meine Lösung war mit rpi-update die letzte funktionierende Kernel-Version zu installieren. Ich hatte damals die Liste der Versionen Schritt für Schritt durchprobiert. Eine Lösung für die neueren Kernel-Versionen kenne ich bisher auch nicht.

    Code
    1. rpi-update 26620cc9a63c6cb9965374d509479b4ee2c30241

    Nach einem Upgrade meines RPI 3B+ habe ich ein interessantes Verhalten:

    Nach dem Start werden Bild und Ton ganz normal angezeigt. Nach dem Umschalten oder beim Abspielen einer Aufnahme gibt es dann jedoch kein Bild mehr, Ton gibt es aber sporadisch. Im Logfile findet sich die Meldung "ERROR: 1 TS packet(s) not accepted in Transfer Mode". Wenn der VDR ohne Reboot neu gestartet wird wiederholt sich das Verhalten.


    Der beim Upgade neu istallierte Kernel war 5.4.72-v7+, davor hatte ich 5.4.51-v7+.


    Ein paar weiter Experimente mit verschiedenen Kerneln via rpi-update führte zum Ergebnis, dass es bis zu folgender Änderung funktionierte:


    26620cc9a63c6cb9965374d509479b4ee2c30241 => ok

    Linux RPI-VDR 5.4.68-v7+ #1343 SMP Mon Sep 28 12:38:29 BST 2020 armv7l GNU/Linux


    64391b28301e92914ba35e345da6e11fab3afd6b => fail

    Linux RPI-VDR 5.4.68-v7+ #1343 SMP Mon Sep 28 12:38:29 BST 2020 armv7l GNU/Linux


    firmware: video_decode: Only shutdown codec on both ports being disabled

    firmware: vc_image_helper: Avoid misaligned exception due to uninitialised pointer

    firmware: arm_loader: Make arm clock accesses only see their own boosts

    See: raspberrypi/firmware#1469


    Kennt jemand eine Lösung des Problems?


    Gruß Zimuland

    Hallo,


    ich hab hier noch zwei eigene Patches rumliegen.


    Beim ersten hatte ich nur das Ausführen eines Kommandos rausgeworfen, da es beim Compilieren Probleme machte und ich es selbst nicht verwendete.
    Im zweiten sind zusätzlich noch alle i18n-Zugriffe rausgeflogen, die ab VDR 1.7.27 nicht mehr unterstützt wurden.


    Vielleicht hilft es ja weiter.


    Gruß zimuland

    Ich hatte vor einiger Zeit einen ähnlichen Effekt als die Platte voll war und er seine Config-Datei daher nicht mehr schreiben konnte. Ich habe dann das Speichern der Konfiguration abgeschalten. Welche Einstellung genau das war weiß ich aber nicht mehr aus dem Kopf.


    Gruß Zimuland

    Hallo,


    ich habe heute auch mal auf die neue Version des Plugins aktualisiert. Nach dem Update scheint das Plugin osdteletext nicht mehr richtig zu funktionieren.
    Wenn ich den Teletext aktivieren wird nichts angezeigt. Auch im Logfile ist nichts zu finden. Ich habe von beiden Plugins die aktuellen Versionen aus dem GIT instaliert.
    Nach der Deaktivierung der OSD Beschleunigung funktioniert es wieder.


    Gruß Zimuland