VDR bleibt stehen. Wegen /opt/lib/libmediaclient.so (sundtek Treiber)?

    Hi,

    Es passiert mir recht selten, aber gelegentlich bleibt VDR stehen. D.h. es passiert einfach nichts mehr, es gibt keine Einträge mehr im log, svdrpsend ping führt zu einem timeout, das Web UI (vdr-plugin-live) erscheint nicht mehr im Browser, ...

    Gestern ist das mal wieder passiert. Der letzte Eintrag von VDR im syslog:

    Code
    2025-07-16T23:14:39.086039+02:00 rpi4s vdr: [2638973] epg data writer thread started (pid=2631331, tid=2638973, prio=low)                                                                                                                     
2025-07-16T23:14:41.085524+02:00 rpi4s vdr: [2638973] epg data writer thread ended (pid=2631331, tid=2638973)                                                                                                                                 
2025-07-16T23:19:54.655570+02:00 rpi4s vdr: [2631331] switching device 2 to channel 19 S19.2E-1-1011-11130 (zdf_neo HD)

    Der sundtek Treiber scheint nicht richtig zu funktionieren, /opt/bin/mediaclient --testastra -d /dev/dvb/adapter0/frontend0 führt zu

    es gibt also keinen lock. Ich habe mich mal mit gdb an den stehenden VDR gehängt und einen Backtrace erstellt, s. attachte Datei.

    Auffällig ist, das es bei ein paar threads Backtrace stopped: previous frame identical to this frame (corrupt stack?) gibt, und in jedem dieser threads taucht in ?? () from /opt/lib/libmediaclient.so auf.

    Nach einem VDR restart (ohne mediasrv zu restarten) hängt VDR wieder, gleiches Verhalten wie oben beschrieben.

    Sundtek , könnt ihr Euch das bitte mal anschauen? Sieht irgendwie nach einen Fehler in Eurem Treiber aus.

    Hi,


    gibt's zu dieser Zeit einen Eintrag in "dmesg"? z.B USB Probleme?


    /opt/bin/mediaclient --lc zeigt an welche Clients auf den Treiber zugreifen.


    Ansonsten könnte ich wohl im Laufe der nächsten Woche auch eine Debug Version von libmediaclient bereitstellen.


    Auch Logfile einschalten /etc/sundtek.conf

    dort folgende Zeile hinzufügen:

    loglevel=max


    So viele Informationen wie möglich zusammentragen und jeweils mit Timestamp damit man eingrenzen kann was da los war, bzw. was es getriggert hat.


    Wenn testastra kein Lock bringt (Du verwendest ja Unicable oder?) müsste etwas gröberes passiert sein.


    Auch welche Kernelversion wird verwendet? Insbesondere 6.8.10 war ja "gefährlich" bezüglich USB.

    Edited 2 times, last by Sundtek (July 18, 2025 at 1:07 AM).

    Hi,

    Ich verwende Linux rpi4s 6.6.51+rpt-rpi-v8 #1 SMP PREEMPT Debian 1:6.6.51-1+rpt3 (2024-10-08) aarch64 GNU/Linux

    loglevel=max habe ich jetzt eingefügt.

    USB Probleme gab es keine. Am USB hängen auch die Festplatten, die problemlos funktioniert haben. Auch keine Einträge zu USB im Log.

    Unicable verwende ich nicht, jeder Empfänger hat ein eigenes Kabel zum Multiswitch.

    testastra zeigt normalerweise einen lock. Gelegentlich kann VDR nichts mehr aufzeichnen, dann zeigt testastra keinen lock. Re-start von VDR und mediasrv hilft, danach geht es dann wieder.


    ~Markus

    Wenn es auftritt bitte alle Logs zusammen in ein Archiv stecken und hochladen oder uns zusenden.

    (syslog, mediasrv.log, mediaclient.log, /opt/bin/mediaclient --lc (auch mittels ps aux | grep pid überprüfen ob die IDs die dort angezeigt werden existieren), einfach alles was es gibt und was Dir ggf. einfällt).

    Auch testastra bei beiden Tunern durchführen.

    Wichtig im ersten Schritt ist immer dass es irgendwie reproduzierbar ist dann kann man das Problem auch lösen (genau so wie beim 6.8.10er Kernelbug, das Problem wurde innerhalb eines Tages identifiziert und gelöst - als es reproduzierbar war). Die Arbeit liegt üblicherweise darin es reproduzierbar zu machen ...

    > Wichtig im ersten Schritt ist immer dass es irgendwie reproduzierbar ist

    Na ja, reproduzierbare Fehler können natürlich leichter gefunden und korrigiert werden. Ist hier aber nicht der Fall.

    Ich werde die Logs posten, wenn es wieder auftritt.

    Ich bekomme wieder keine locks. Nach dem herunterfahren von VDR:

    /opt/bin/mediaclient --testastra -d /dev/dvb/adapter0/frontend0 :

    /opt/bin/mediaclient --testastra -d /dev/dvb/adapter1/frontend

    /opt/bin/mediaclient --lc

    wie geschrieben, VDR war heruntergefahren.


    Achtung: die attachte mediasrv.log.xz.zip ist eine xz Datei! Also

    Code
    mv mediasrv.log.xz.zip  mediasrv.log.xz

    und danach mit xz de-komprimieren. Das Forum verbietet Dateien mit der Endung .xz :(

    Ich schicke die syslog als pn

    Der 2. Tuner ist okay kein Lock beim ersten Transponder kommt daher da sich die Referenzfrequenz bei Astra verändert hat (wird mit dem nächsten Update aktualisiert).

    Der erste Eingang scheint bei einigen Transpondern starke Empfangsprobleme zu haben (aber ich weiß jetzt natürlich nicht ob das beim 2. Tuner auch auftritt, die Frequenzen aus der Logfile sollten gesondert überprüft werden). Der Treiber braucht n Ratelimit bei den Transportstream fehlern; denke wir gehen das erst mal in den Direktmessages durch.


    Auf der Digitalseite habe ich soweit keine Probleme in den Logfiles entdeckt, scheint eher auf der Analog Seite zu sein.

    Na ja, nach einem Restart des Treibers:

    /opt/bin/mediaclient --testastra -d /dev/dvb/adapter0/frontend0

    /opt/bin/mediaclient --testastra -d /dev/dvb/adapter1/frontend0


    Also, wenn es vor dem Restart des Treibers nicht mehr geht, nach dem Restart des Treibers aber wieder geht, dann ist das für mich ein Fehler im Treiber

    Laut Logfile werden Diseqc Befehle geschickt.

    Testastra resettet keine Diseqc Einstellungen und schickt auch keine Diseqc Befehle - "testastra" lockt ja nur auf bekannten Astra 19.2 Transpondern auf der aktuellen Position. Schau Dir bitte die Nachrichten an die ich dir geschickt habe. Die Fehlersuche muss Schritt für Schritt durchgeführt werden.


    Wenn mittels VDR und Diseqc auf eine andere Position geschalten wurde und diese aus einem Grund nicht vom Switch angenommen wurde kann das Signal Routing eventuell nicht dem entsprechen was man eigentlich erwarten würde.

    Überzeugt mich jetzt nicht. VDR schickt ja die Diseqc Befehle zum Umschalten auf Astra. Und VDR bekommt auch keinen Lock auf zdf_neo HD.

    Jetzt könnte man natürlich vermuten, dass der Multischalter die Diseqc Befehle nicht korrekt ausführt. Andererseits: Wieso geht es dann nach einem Restart des Sundtek Treibers?

    Ich kann Dir so leider nicht weiterhelfen.


    Habe Dir ja die Nachrichten geschickt, entweder wir schauen uns das gemeinsam direkt an oder eben nicht.
    Wir haben hier Systeme die nur mit 4.75V auf USB arbeiten die sind auch nicht brauchbar, es kann alles mögliche sein wenn da nicht versucht wird Dein Problem einzugrenzen.

    Ich hatte Deine PNs übersehen, sorry.


    Das ist ein RPI4, /opt/bin/mediaclient --arch gibt also

    Architecture: arm64


    aus.

    Ich empfange Astra 19-2 (gute Qualität) und Astra S28.2E (schlechte / schwankende Qualität).

    Trotzdem sollte der Treiber stabil laufen.

    Bei sehr schlechten Sendern kann es sein dass Du ein Y USB Kabel je nach System verwenden musst da der Stromverbrauch erhöht wird, ich weiß jetzt nicht wie viel Volt bzw Power Du beim Raspberry PI rausbekommst - ist im Regelfall bei Sendern akzeptabler Signalqualität kein Problem;

    Die jeweiligen Transponder welche so gut wie keinen Empfang haben sollten sich ohnehin in der Logfile finden lassen Transponder mit nicht akzeptablen Empfang gab's laut Logfile ja (und da hat das logging derart gewütet dass der Treiber eine volle Auslastung verursacht hat; deshalb wiegesagt die Frage welcher Treiber (mediaclient --arch)).

    Ich schicke Dir dann einen Link zu einem Treiber wo das Logging etwas entschärft wird, mit ratelimit max 10 Einträge pro Sekunde und nicht tausende.

    Wir hatten vor einiger Zeit ein System wo wir Input an Output brücken mussten um selbst den MediaTV Pro stabil an's laufen zu bekommen.

    > Bei sehr schlechten Sendern kann es sein dass Du ein Y USB Kabel je nach System verwenden musst da der Stromverbrauch erhöht wird, ich weiß jetzt nicht wie viel Volt bzw Power Du beim Raspberry PI rausbekommst - ist im Regelfall bei Sendern akzeptabler Signalqualität kein Problem;

    Ich habe einen aktiven Switch mit eigener Stromversorgung der die LNBs mit Strom versorgt.

    Da sollte das doch kein Problem sein (?).

    Quote from MarkusE

    > Bei sehr schlechten Sendern kann es sein dass Du ein Y USB Kabel je nach System verwenden musst da der Stromverbrauch erhöht wird, ich weiß jetzt nicht wie viel Volt bzw Power Du beim Raspberry PI rausbekommst - ist im Regelfall bei Sendern akzeptabler Signalqualität kein Problem;

    Ich habe einen aktiven Switch mit eigener Stromversorgung der die LNBs mit Strom versorgt.

    Da sollte das doch kein Problem sein (?).

    Meiner Erfahrung nach kann man das nicht garantiert sagen, schließ den Tuner mal direkt an; Mit aktiven USB Hubs gibt's auch gemischte Erfahrungen es gibt soviel Wildwuchs garantieren kann man da nie etwas (ist ja bei PCI-e bei einigen Systemen auch so),

    Ich würde aber zur Sicherheit eher die schlechten Sender aus der Logfile rauspicken und aus Deiner channels.conf entfernen. Steck den Tuner mal direkt an und schau Dir das Problem an, werde Dir bis morgen nen arm64 Build mit entschärftem Logging/Ratelimiting bereitstellen; spätestens dann können wir die Sender welche keine ordentlichen Transportstreams zurückliefern schön rausfiltern.

    Ich habe heute den Treiber upgedatet und neu gestartet.

    Aus mediasrv.log:

    das verstehe ich nicht. Ich habe extra in der /etc/sundtek.conf den ir Support ausgeschaltet ("ir_disabled=1"). Das wird auch in der mediasrv.log bestätigt: "Infrared Control Support is disabled in configuration file".

    Warum macht er dann trotzdem das IR Setup, und warum gibt es dann IR Events wie "RC: IR Event /dev/input/event0"? Der Rechner+Sundtek Sticks sind im Dachboden, da gibt es keine Fernbedienung ...


    Ich werde weiter berichten und vollständige Logs schicken, wenn es wieder Probleme gibt. Hier noch meine /etc/sundtek.conf:

    Code
    use_hwpidfilter=on
ir_disabled=1
loglevel=max

Participate now!

Don’t have an account yet? Register yourself now and be a part of our community!

Register Yourself Login