streamdev stürzt ab bei aktiviertem Filter Streaming unter 1.6

  • Hallo,


    vielleicht liest hier jemand von den streamdev developers mit.


    Und zwar habe ich auf vdr 1.6 umgestellt. Ich habe hier eine Client/Server Umgebung. Also alles auf 1.6 umgestellt.


    Dabei habe ich festgestellt, dass bei 1.6 das streamdev nicht filter streaming aktiviert haben darf (sonst raucht der client reproduzierbar ab). Ohne Filter Streaming gehts.


    Unter vdr 1.4 hatte ich Filter Streaming aktiviert. Hat das jemand auch gehabt bzw. eine Lösung dafür?

  • Zitat

    Original von neumann2k
    Unter vdr 1.4 hatte ich Filter Streaming aktiviert. Hat das jemand auch gehabt bzw. eine Lösung dafür?


    ... auch wenn es dir nur wenig bringt: kenne ich eigentlich nur vom *erstmaligen* Aktivieren auf einem Client. Da crasht der VDR stets reproduzierbar. Wenn's aber einmal aktiviert ist, läuft's bei mir danach völlig stabil. Das Synchronisieren des EPG hingegen führt auch hier zu kompletten Hängern des Clients; darauf sollte man wohl tunlichst verzichten.


    Reden wir hier vom Streamen unverschlüsselter Kanäle?


    Gruß
    Holger


    PS: Signatur ignorieren; ich setze auch VDR 1.6 ein.

  • Das von euch geschilderte Problem hab ich auch, allerdings auf meinem Client mit VDR 1.4.7. Da es nicht immer auftritt, kann ich nicht genau sagen warum - auf jeden Fall aber passiert es, wenn EPG Sync aktiviert ist. Aber auch dann passiert es nicht immer. Oft deaktiviere ich dann einfach den streamdev-client und aktiviere ihn nach einem VDR Neustart wieder. Dass ist das Problem oft wie weggeblasen. Mit der Option "Filter Streaming" hat es bei mir offenbar also nichts zu tun.


    Gruss Kai

    VDR1 - Gen2VDR 3.0 Release Upd.10 (VDR 1.7.23): Gigabyte GA-K8N, AMD X2 3800 (S.939), 2 GB Ram, Sparkle GeForce 9500 GT, SBLive 5.1 per SPDIF, Cine-S2 Rev.5.5
    VDR2 - Gen2VDR 4.0 Release Upd.9 (VDR 2.0.4): AMD X2 3800 (S.939), 3 GB Ram, GeForce GT430 HDMI

    AUDIO: YAMAHA RX-V 1065 an Nubert NuBox 460, CS-3 Center, Rear: NuBox 360/5, Sub: Acoustic Research Chronos W38.

  • Hier mal ein Backtrace vom Absturz. Vielleicht hat es was mit unterschiedlichen LANG einstellungen zu tun?


    (gdb) bt
    #0 0x40017410 in ?? ()
    #1 0x496fee4c in ?? ()
    #2 0x00000006 in ?? ()
    #3 0x40204f29 in abort () from /lib/tls/libc.so.6
    #4 0x40e78cc4 in signal_handler () from /usr/lib/libdirect-1.0.so.0
    #5 <signal handler called>
    #6 cHashBase::Get (this=0x83788e4, Id=1216308600) at tools.h:407
    #7 0x080b0bdb in cSchedule::GetEvent (this=0x83788a8, EventID=260, StartTime=1216308600) at tools.h:538
    #8 0x080acbd4 in cEIT (this=0x496ff960, Schedules=0x8162040, Source=35008, Tid=81 'Q', Data=0x496ffa50 "Qø¬.ãÅ(¸\004A",
    OnlyRunningStatus=false) at eit.c:58
    #9 0x080adc4c in cEitFilter::Process (this=0x8375fb0, Pid=18, Tid=81 'Q', Data=0x496ffa50 "Qø¬.ãÅ(¸\004A", Length=2223)
    at eit.c:330
    #10 0x080eb783 in cSectionHandler::Action (this=0x8375a70) at sections.c:212
    #11 0x08102038 in cThread::StartThread (Thread=0x8375a70) at thread.c:244
    #12 0x400479dd in start_thread () from /lib/tls/libpthread.so.0
    #13 0x4029464a in clone () from /lib/tls/libc.so.6

  • Hm - im Backtrace taucht streamdev als solches gar nicht auf (höchstens indirekt durch die Daten die es dem Section-Handler übergibt). Der Aufruf fällt auf die Nase, wenn geprüft wird, ob bereits ein Event zur angegebenen Startzeit bekannt ist. Der dazu genutzte Hash scheint kaputt zu sein (erster Zugriff auf den ermittelten Bucket schlägt fehl).


    Nun macht streamdev-client hier nichts eigenes. Es werden ausschließlich VDR-Funktionen für die Verarbeitung der EPG-Daten verwendet. Sowohl im SectionHandler als auch ausgehend vom Streamdev EPG-Sync habe ich die Aufrufe geprüft: Alles schön gelockt. Läuft evtl. noch ein anderes Plugin oder Tool, das EPG-Daten manipuliert oder von außen zufüttert und sich ggf. nicht um Locks kümmert?


    Zum EPG-Sync als solches: Das streamdev EPG-Sync blockiert die VDR Haupt-Programmschleife. Je nach Netzwerkanbindung und Umfang des Server-EPGs kann die Übertragung dauern. VDR ist in dieser Zeit nicht bedienbar. Schlimmstenfalls schießt der Watchdog den VDR ab. Ich rate daher grundsätzlich von der Nutzung des streamdev EPG-Sync ab. Sofern einem Filter-Streaming nicht schon genügt, bitte das epgsync-Plugin verwenden.


    HolgerR: Wie muss ich mir das erstmalige Aktivieren auf dem Client vorstellen? Im Setup den streamdev-client anschalten?


    @all: Gebt doch bitte noch mit an, welche streamdev-Version ihr nutzt.

  • Hi,


    Zitat

    Original von schmirl
    HolgerR: Wie muss ich mir das erstmalige Aktivieren auf dem Client vorstellen? Im Setup den streamdev-client anschalten?


    Ja, so ungefähr. Konkret aktiviere ich immer zuerst den Client, lasse ihn streamen und stelle dann das Filterstreaming von "nein" auf "ja" um. Direkt nach Betätigung der "OK"-Taste steht der Stream (=Standbild ohne Ton); Der VDR bleibt aber bedienbar. Nach einem VDR-Neustart läuft dann alles.


    Bitte nicht überbewerten. Ich habe das nie als echtes Problem angesehen. Dieses Verhalten existiert übrigens schon seitdem Filterstreaming wirklich genutzt werden kann und besteht bis hin zur aktuell über Tobi beziehbaren Version (0.3.3~cvs20080406.1321-3)


    Gruß
    Holger

  • Zitat

    Konkret aktiviere ich immer zuerst den Client, lasse ihn streamen und stelle dann das Filterstreaming von "nein" auf "ja" um. Direkt nach Betätigung der "OK"-Taste steht der Stream (=Standbild ohne Ton); Der VDR bleibt aber bedienbar. Nach einem VDR-Neustart läuft dann alles.


    Also kein Absturz (Du hattest von einem "crash" gesprochen)? Langt es in dem von Dir beschriebenen Fall nicht, einfach nochmal den Kanal zu wechseln damit die Bilder wieder laufen lernen?

  • Zitat

    Original von schmirl


    Also kein Absturz (Du hattest von einem "crash" gesprochen)? Langt es in dem von Dir beschriebenen Fall nicht, einfach nochmal den Kanal zu wechseln damit die Bilder wieder laufen lernen?


    Jupp, sorry! Hätte vielleicht besser "picture freeze" verwenden sollen. ;) Nein, Umschalten brachte bisher nichts. Es muß dann schon ein VDR(!)-Neustart sein. Allerdings habe ich das auch nicht sehr hartnäckig versucht.


    Eigentlich müßtest du das doch auch haben, oder? Du kennst dieses "Problem" bisher nicht?


    Gruß
    Holger

  • Zitat

    Eigentlich müßtest du das doch auch haben, oder? Du kennst dieses "Problem" bisher nicht?


    Bei mir gibt's keine Probleme, ich bin aber auch noch bei VDR 1.4. Streamdev mit Filter-Streaming ist bei mir immer an, da ich nur reine Clients mit Headless-Server habe.

  • Hallo auch ich kann seit dem wecksel vom vdr 1.4.7 zu 1.6 b.z 1.7 auch von diesem Problem berichten.
    Hatte schon den noepg patch und externes EPG im verdacht. Doch war es das offentsichltich auch nicht.
    Jetzt fellt mir ein das ich ja auch noch das premiereepg Plugin nutze kann es das sein?


    Bei mir hat der Cleint immer erst am zweite Abend oder nach längerer benutzung begonnen sich zu verabschiden.
    Könnte wohl daran liegen das ich nach dem ändern einer Einstellung immer mit einer frichen epg.data Datei begonnen habe.
    Hatte mich schon daran gewöhnt das ich kein filter epg einsätzen kann. Aber wenn das doch noch wo anders auftaucht werde ich noch mahl schauen in welchen kombinationen das bei mir auftritt.


  • Hallo,


    erstmal vielen Dank für Deine Antwort.


    Also ich benutze die aktuelle CVS Version von gestern Abend.


    Ich habe mittlerweile neue Erkenntnisse:


    Das "crashen" des VDR passiert nun auch ohne aktiviertes EPG und OHNE aktiviertem Filter Streaming.


    Allerdings bleibt der VDR ca. 10 - 15 Minuten in Betrieb. Dann crasht er. Als Plugin habe ich außer streamdev nur softdevice am laufen. Sonst nix, keine Patches etc. Rein VDR Vanilla.


    Ich benutze die multiproto Treiber, weil ich im Server 2x NOVA HD-S2 habe, aber das kann es ja denke ich nicht sein.


    Was mir noch aufgefallen ist:


    Der Server läuft ja jetzt auch mit vdr-1.6, der Client im Schlafzimmer ist aber noch auf 1.4.7.


    Dort passieren diese Crashs nicht. Ich werde jetzt mal den Client im Schlafzimmer upgraden, um auszuschließen, dass es am softdevice plugin liegt (Client im Schlafzimmer verwendet DXR3).


    Fällt Dir vielleicht noch etwas ein, was schuld sein kann? Ich füttere kein externes EPG oder so in den VDR.


    Zitat

    Der Aufruf fällt auf die Nase, wenn geprüft wird, ob bereits ein Event zur angegebenen Startzeit bekannt ist. Der dazu genutzte Hash scheint kaputt zu sein (erster Zugriff auf den ermittelten Bucket schlägt fehl).


    Wieso passiert das? Wer könnte der Verursacher sein?

  • Jetzt wirds immer mysteriöser...


    Wenn ich den VDR ohne Streamdev plugin starte, schmiert er nicht ab, beende ich ihn aber hart per crtl + C gibt es ebenfalls einen Crash.


    Der sieht dann so aus:


    (gdb) bt
    #0 0x081068dc in cHashBase::Clear ()
    #1 0x08106bb6 in cHashBase::~cHashBase ()
    #2 0x080b3723 in cSchedule::~cSchedule ()
    #3 0x0810678a in cListBase::Clear ()
    #4 0x08106a65 in cListBase::~cListBase ()
    #5 0x080b0981 in cEvent::SetSeen ()
    #6 0x40206220 in exit () from /lib/tls/libc.so.6
    #7 0x401f14ba in __libc_start_main () from /lib/tls/libc.so.6
    #8 0x0808ba61 in _start ()


    Irgendwas stimmt doch hier nicht. Das ganze passiert unter vdr-1.4.7 nicht.

  • Und noch komischer...


    Lasse ich das Softdevice weg und benutze das dummydevice crasht der vdr ebenfalls beim beenden mittels strg + c. gdb ausgabe ist dann:


    (gdb) bt
    #0 0x0839cd19 in ?? ()
    #1 0x080eb597 in cSectionHandler::Action ()
    #2 0x08102538 in cThread::StartThread ()
    #3 0x400479dd in start_thread () from /lib/tls/libpthread.so.0
    #4 0x4029464a in clone () from /lib/tls/libc.so.6


    Ich glaube, hier kann nur noch kls selber Licht ins Dunkle bringen.

  • neumann2k: Ein allgemeines Problem in VDR 1.6 halte ich für eher unwahrscheinlich - auch wenn einer der Stacktraces schon wieder auf einen kaputten Schedule-Hash hinweist. Es müssten doch viel mehr Leute Probleme haben.


    Sicher vielleicht mal Deine epg.data weg und probiere es der Reihe nach nochmal (zuerst nur dummydevice, dann softdevice, dann streamdev ohne alles, dann mit Section-Filter und schließlich mit EPG-Sync).


    Was mir bei Deinen backtraces noch fehlt: Welcher Fehler wird eigentlich gemeldet? "Double free or corruption"?


    HolgerR: Habe gestern mal VDR 1.6 als Client gestartet. Dass das Bild einfriert wenn im Setup bestimmte Einstellungen geändert werden passiert sowohl unter 1.4 als auch unter 1.6 (das ist ein Feature, kein Bug ;)). Bei beiden Versionen langt bei mir aber ein Kanalwechsel und es geht weiter.

  • Zitat

    Original von schmirl
    HolgerR: Habe gestern mal VDR 1.6 als Client gestartet. Dass das Bild einfriert wenn im Setup bestimmte Einstellungen geändert werden passiert sowohl unter 1.4 als auch unter 1.6 (das ist ein Feature, kein Bug ;)). Bei beiden Versionen langt bei mir aber ein Kanalwechsel und es geht weiter.


    Na guuut. Ich teste das nochmal. Wie gesagt, ich habe mir da bisher auch nicht *wirklich* viel Mühe gegeben. ;)


    Ansonsten kann ich eigentlich nur sagen, dass Streamdev im Allgemeinen und Filterstreaming im Speziellen hier allerbest funktioniert unter VDR 1.6.x. Ein allgemeines Problem kann ich daher ebenfalls ausschließen. Ich verwende hier übrigens ebenfalls "premiereepg" und "noepgmenu"; daran liegt's also auch nicht.


    Leicht OT:
    Die epg.data kopiere ich übrigens einmalig beim Start des Clients per NFS vom Server, der die ganze Zeit brav EPG-Daten sammelt. Zusammen mit dem Filterstreaming liefert das ein sehr akzeptables Ergebnis. Das ist "mein Weg" an ein aktuelles EPG zu kommen. ;)


    Gruß
    Holger

  • Huhu,


    ähnliches habe ich hier in einem reinen 1.7.0er-Verbund auch! Allerdings stürzt der VDR nicht ab, nur streamdev-client beendet seine Arbeit. Wenn man dann wieder auf einen/denselben Sender tuned, geht's normal weiter. Dies passiert auch nur, wenn Filter-Streaming aktiviert ist. Ist das auch gewollt?
    Der betreffende Auszug aus dem Log:


    Ich verwende auch premiereepg und noepg(menu) - aber nur auf dem Server. Der VDR ist mit Extension-Patch-62 gepatched. Streamdev-Client und -Server sind die neueste CVS-Version.


    Viele Grüße,
    Chriss

Jetzt mitmachen!

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