RPi2 LiveTV Problem

    Nach einigen Zeit bleibt Bild auf FTA HD Sender stehen, im Log sind dann viele "ERROR: TS packet not accepted in Transfer Mode" zu sehen. Beim Umschalten wird nach 90sec watchdog getriggert und VDR startet neue (keinen coredump), danach funktioniert LiveTV wieder. Hat jemand welche Idee was das sein kann? Passiert schon ofter in der Woche.


    Im Einsatz:
    RPi2 mit Sundtek DVB-S2 2015 Karte mit externen Stromversorgung.


    /boot/config.txt Alles default bis auf:

    Code
    # custom settings
decode_MPG2=0xXXXXX
decode_WVC1=0xXXXXX
gpu_mem=256


    Und wie im Log unten zu sehen ist, hat es von "Jan 23 23:49" bis "Jan 25 16:04" funktioniert, dann ist das Bild stehen geblieben. Da wo die punkten sind "...." wird ganzen Zeit im Log "TS packet not accepted in Transfer Mode" geschrieben.


    Memory Auslastung war meiner Meinung nach ok:

    Code
    # free -mt
              total        used        free      shared  buff/cache   available
Mem:            732          87         431           5         213         619
Swap:             0           0           0
Total:          732          87         431
#



    Nach fast ein Tag beim umschalten ist das BIld stehen gebleiben und dann : vdr.service: State 'stop-sigterm' timed out. Killing. <- es ist keinen coredump generiert


    Hi crow

    Zitat von crow

    Nach einigen Zeit bleibt Bild auf FTA HD Sender stehen, im Log sind dann viele "ERROR: TS packet not accepted in Transfer Mode" zu sehen. Beim Umschalten wird nach 90sec watchdog getriggert und VDR startet neue (keinen coredump), danach funktioniert LiveTV wieder. Hat jemand welche Idee was das sein kann? Passiert schon ofter in der Woche.


    Schwer zu sagen, wo das Problem liegt. Ich habe zwar den Dauerbetrieb im Live-Mode auf verschiedenen Kanälen getestet, aber nicht auf ServusTV HD. Im Live-Mode ist speziell, dass die Abspielgeschwindigkeit immer minimal angepasst werden muss, damit es keine Buffer Over- und Underruns gibt. Der erste Schritte wäre nun zu testen, ob es damit was zu tun hat. Kannst du rpihddevice mal mit "make DEBUG_BUFFERSTAT=1" übersetzen und beobachten, wie sich die Bufferbelegeung entwickelt?


    Aber selbst wenn es an einem Buffer-Overrun liegt, sollte eigentlich kein "Stream Corrupt" auftreten, da VDR in einem solchen Fall einfach cDevice::Clear() aufruft - zwar unschön beim zusehen, aber kein Grund stehen zu bleiben...


    Davon unabhängig natürlich die üblichen Fragen:
    - Firmware aktuell?
    - Overclocking?
    - Unterspannungswarnung aktiv? (kleines Regenbogenquadrat in der rechten, oberen Ecke) Auch nicht in config.txt unterdrückt?


    Gruss
    Thomas

    Firmware aktuell? Ja RPi2 Firmware ist aktuell, Archlinuxarm wurde am 16.02 Aktualisiert:
    ArchLinuxArm


    VDR


    Overclocking? Ich habe da selbst nichts gemacht, es sind wie im Anfangspost geschrieben default Werte. Anbei eine Ausgabe vom 'vcgencmd get_config int'.


    Unterspannungswarnung aktiv? (kleines Regenbogenquadrat in der rechten, oberen Ecke) Auch nicht in config.txt unterdrückt?
    Ich sehe im LiveTV kein Regenbogenquadrat in der rechten, oberen Ecke, ich hoffe die Ausgabe vom "get_config init" zeigt ob so etwas aktiviert und unterdrückt ist.


    Es ist gestern wieder passiert, da war LiveTV ok (Audio und Video) und beim Umschalten ist es wieder passiert.
    Da hat Klaus selbst so ein Verhalten mit seinem RPi2 auch:


    Wegen obengenannter Aussauge von Klaus habe ich auf dem RaspberryPi github Repository ein Issue erstellt, anbei link dafür:
    https://github.com/raspberrypi…45#issuecomment-184747254


    Anbei das Log (leider war logleve=2), jetzt habe ich rpihddevice mit "make DEBUG_BUFFERSTAT=1" kompiliert und loglevel erhöt. Melde mich dann mit neueren log.

    So gestern nach 23 Uhr auf ServusTV HD gelassen, heute auf ein anderen Channel geschaltet (davor war alles perfekt im LiveTV, also video/audio in sync), und ist wieder ein crash passiert. Da steht etwas von ci.c ich glaube das war rendom crash da ich auf einen Verschlüsselten sender geschaltet habe. Für morgen abend wird es ein FTA sein.



    Dieses mal wurde coredump erstell (ist im Anhang).

    Dateien

    rpi2_crash01.txt 16,76 kB – 202 Downloads
    Zitat von crow

    Dieses mal wurde coredump erstell (ist im Anhang).

    Danke für den Backtrace. Das Problem kommt mir bekannt vor, da scheint ein Video-Buffer irgendwo "festzuklemmen", wodurch das Plugin beim Initialisieren des Decoder stecken bleibt. Komischerweise hatte ich das Problem aber schon länger nicht mehr, und ServusTV HD läuft bei mir jetzt >24h ohne Probleme.


    Vielleicht wäre es sinnvoll, die entsprechenden Zeilen beim Issue auf github anzufügen:


    ilclient ist eine Abstraktionsschicht vom OMX IL und wurde von Broadcom entwickelt - vielleicht haben die eine Idee, weshalb VDR dort feststeckt.


    Gruss
    Thomas

    Scheinbar hatten andere ähnliche Probleme: Crashing when seeking


    Ich vermute, dabei handelt es sich um das selbe Problem - jedenfalls scheint der Fix zu wirken, denn ich konnte ich das Problem auf dem 3er-Raspi nicht mehr nachstellen. VDR lief letzte Woche 5x24h durch und ich konnte jeweils abends den Sender wechseln ohne dass es zu einem Hänger kam.


    Gruss
    Thomas

    Ich habe gehofft dass das Problem behoben wurde, leider passiert wieder nach mehrere stunden (meist über 12) so das Bild schwarz ist und im log sind viele Fehlermeldungen zu sehen. Auch ein coredump wird erstellt leider meiner Meinung nach der beinhaltet nichts was brauchbares (weiß jemand wie anderes zu Debuggen)?


    Anbei logs und coredump

    Code
    coredump: https://cryptobin.co/7500c9g0
vdr log: https://cryptobin.co/f1g6d9i0
dmesg: https://cryptobin.co/n0p610t1


passwort: vdr

    nein habe ich nicht (kann auch derzeit nicht), sobald ich stop und start von vdr mache ist alles wieder in Ordnung, passiert auch wenn das nulldevice bzw kodi aktiv ist.

    Hab vor ein Tag USB verlängerungskabel von Suntek getauscht, und jetzt ist im dmesg nicht zu sehen von disconnected USB device jedoch nach 12+ stunden bleibt das Bild stehen, in hinterground kommt ab und zu audio, und beim channel switch wird gecrasht. Sieht jemand etwas merkwürdiges im coredump oder ist der nur wegen watchdog generiert?


    Code
    url: https://cryptobin.co/b135y8c0
pass: vdr

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!

Benutzerkonto erstellen Anmelden