[solved] VDR 1.3 auf Kernel 2.6 instabil, vdsb error

    Hallo,


    'tschuldigung das ich meinen persönlichen Kummer-Thread wieder zurück ins Leben rufen,
    wollte aber meine heutige Erkenntnis nicht für mich alleine behalten.


    Code
    Jul 18 20:13:41 TuxVision vdr[7641]: ERROR: unknown picture type '7'
Jul 18 20:13:41 TuxVision vdr[7665]: ERROR: unknown picture type '7'
Jul 18 20:14:13 TuxVision vdr[7641]: ERROR: video data stream broken

    Mit der CVS von heute habe ich es zum allererstenmal den sagenumwobenen UPT Fehler bei mir gehabt,
    wohlgemerkt mit nur einer aktiven FF DVB Karten, echt supi!

    Zitat

    Original von AnK
    Mit der CVS von heute habe ich es zum allererstenmal den sagenumwobenen UPT Fehler bei mir gehabt,
    wohlgemerkt mit nur einer aktiven FF DVB Karten, echt supi!


    Hi AnK!


    Kann das nicht auch am Wetter liegen (ohne Scheiß)? Ich meine, wenn die Karte irgendwann keinen Empfang mehr auf einem Kanal hat (weil einfach SS oder SNR nicht mehr reicht) und die Karte sich dann an den Daten verschluckt, kann es dann nicht auch zu so einem Fehler kommen?


    Gruß,


    Jogi

    Zitat

    Original von Space
    Kann das nicht auch am Wetter liegen?


    Prinzipiel geb ich dir natürlich recht, aber das Wetter war heute bei mir noch nicht mal soo schlecht,
    bzw. war schon deutlich schlechter und der VDR hatte trotzdem noch Empfang.


    Naja wie dem auch sein, bin grad dabei nen 2.4 Kernel zu konfigurieren...

    Hi,


    ich glaub eher das das Zufall war mit dem UPT und mit am Wetter lag...ich hatte übers WE mit meiner SS2 auch nur verhältnismäßig kurze Laufzeiten von 30-90min statt wie sonst 2-3h.


    BTW: Ich kloppe mich immer noch damit rum die Ursache zu finden und habe inzwischen auf eine gezielte Vermutung was da passiert.


    Normalerweise sollte ein Kanalwechsel folgendermaßen vonstatten gehen: alle Filter schließen, neu tunen (Diseqc, Tone, Voltage, Frontend), Filter neu setzen.


    vdr geht in etwa auch diesen Weg...übergabe eines Parameters an den Section Threat um die Section Filter zu schließen, schließen eventueller PES-Filter (Live Pids!, nicht während EPG Scan), tunen wie oben, eventuell PES-Filter öffnen, übergabe eines Parameters an den Section Threat um die Section Filter zu starten, wobei hier sogar noch ein usleep greift falls man noch keinen Lock hat.


    Verteilt man nun einige printk´s im Treiber an entscheidenden Stellen, sieht das leider meist ganz anders aus:(


    Nahezu immer werden Diseqc, Tone, Voltage zuerst ausgeführt, danach meist der Frontend getuned, danach die Filter geschlossen und gleich wieder geöffnet...hin und wieder werden die Filter auch mal früher geschlossen..und gleich wieder geöffnet, obwohl das tuning immer noch nicht fertig ist...alles in allem sieht das also recht wild aus...


    Im Prinzip unterbricht man einen Datenstrom, und setzt ihn mit einem anderen, nicht mehr passenden fort...das scheinen die Core Chips auf den Karten nicht zu mögen...


    Läßt man die Karten auf einem Kanal stehen, dann arbeiten die Duracell-like (läuft unf läuft und läuft....), ebenso wenn man den EPG-Scan ohne Section Filter laufen läßt (wobei allerdings dann auch 0 Daten verarbeitet werden;)).


    Ich habe mal versucht das mit ein paar usleeps zu syncen, im besten Falle lief das dann auch 2h mal so wie erwartet, um dann doch "auseinander zulaufen". Im schlimmsten Fall hatten die usleeps auswirkungen an einer gänzlich unerwarteten Stelle...



    Zumindest meiner Meinung nach müßte das die Ursache sein, denn der Frontend Demod wird vom Treiber nicht angehalten (und wurde ja auch für solche Bedingungen gebaut), und der dvb-core hat keinen Einfluss darauf ob die Chips auf der Karte Daten verarbeiten oder nicht. Und im Karten Treiber selbst wird im einfachsten Fall (TT Budget`s) gerade mal die Verarbeitung des Streams gestartet und gestoppt.


    Ich versuche zumindest weiterhin einen Workaround zu finden, mit dem man den Dev´s zeigen kann wo das Problem liegt...


    Andy

    Hmm,


    wenn man mal die Section Filter aussen vor läßt und sich nur die PES_Filter ansieht, die teilweise gesetzt werden *bevor* der Frontend seinen FE_SET_FRONTEND bekommt, obwohl vdr im gleichen Threat die Filter definitiv erst nach der Frontend I/O setzt, isses ein Treiber Problem.


    Das Threating in vdr machts allerdings nicht gerade leichter das irgendwie als workaround zu syncen....und um da (Treiber und vdr) größere Teile umzuschreiben, dazu bin ich nicht in der Lage:(


    Nachtrag: Sollte ich recht haben, dann sollte der Treiber normalerweise keine Filter setzen solange kein Lock da ist, bzw. die Filter löschen wenn der Lock verloren geht, um abstürze bei schlechtem Wetter zu vermeiden. Im core Treiber (dvb_frontend.c)ist eine solche Callback Funktion wohl sogar vorhanden, aber irgendwie scheint da gar nix im Demux anzukommen bzw. es existiert nix was die Callback Daten weiter benutzt.


    Andy

    Seltsam:


    Nachdem ich nun wieder mal eine ganze Zeit beim 2.4er Kernel geblieben bin, dachte ich mir, noch mal den neuesten 2.6er Kernel mit CVS DVB Treiber zu testen...


    Hatte wieder einmal Probleme mit Systemabstürzen, Nun habe ich einfach mal 2 von 3 Rambausteinen rausgenommen und siehe da,
    es scheint nun stabil zu laufen...


    Nun ist es ja nicht so, dass ich zum ersten Mal an einen Ram-Fehler gedacht hätte, aber sowohl ein intensiver 24 stündiger Ram-test, als auch einige Monate mit 2.4er Kernel sind ohne Absturz verlaufen...


    Frage: Warum arbeiten die Rams bei nem 2.4er Kernel zusammen und bei nem 2.6er nicht??


    MGf


    Robsta


    Hardware: Antec Fusion Remote Black, Asus P5N7A-VM, E5200, Mystique SaTiX-S2 Dual V2, Stereo-Atmo
    TV: Samsung UE32B6000, BenQ W1070
    Software: yaVDR


    Hallo,


    ich möchte mich auch mal kurz melden obwohl ich kein gentoo user bin ;)


    Mit Suse 8.0 kernel 2.4 läuft alles wie geschmiert. Mit Suse 9.1 und kernel 2.6 schmiert meine Nova-s immer ab :(


    Habe eine FF DVB-s rev. 1.6 und als zweitkarte eine Nova-s !


    Ich habe jetzt mal einen kernel 2.6.9-rc3-mm3 (www.kernel.org) mit den darin enthaltene treiber ausprobiert und was sehr "schönes" beobachten können !


    Hoffentlich kann jemand was damit anfangen bzw. ihr könnt es dann vieleicht nachvollziehen ...


    Ich denke mal das hilft uns weiter :)


    Auf der konsole (SSH) kam :

    Code
    Message from syslogd@vdr at Sat Oct  9 02:06:46 2004 ...
vdr kernel: Disabling IRQ #18



    im syslog fand ich dann :


    Es scheint so als ob sich keiner um die interruppts der karte kümmert und er sich deshalb aufhängt ...


    mit Suse 8.0 hatt ich auch mal VDSB aber als ich dann die nova-s eine eigene Int. besorgte war alles gut.
    D.h. die Nova hat eine eigene Interrupt und zwar die 18 die sich gemeldet hat !


    lspci -v :



    # cat /proc/interrupts



    Gruß
    Viking

    Ich möchte mich hier auch mal wieder zu Wort melden, nicht das ihr denkt, die Probleme wären gelöst!

    • Also jeder Kernel bis 2.6.10-rc1 bzw jedes CVS-Snapshot der DVB Treiber,
      und jede VDR Version bis 1.3.15 rufen den vdsb error hervor!


    • Ja, jede Karte hat einen eigenen nicht geshareden IRQ!


    • Im Kernel sind so Sachen wie Preemtiv und SMP deaktiviert!


    • Das Problem besteht mit allen Kernel-Sourcen, sogar mit den ungepatchten plain vanilla von kernel.org,
      da man für die neue Lirc Version nicht mal mehr einen Kernelpatch benötigt.


    • Die glibc ist ohne nptl support kompiliert, da es diesbezüglich ja auch mal Probleme gab!


    • Ich habe ein neues Mainboard für den VDR besorgt um zu testen ob es etwa, wie behauptet wurde an SiS-billig-Chipsets liegt,
      aber auch mit dem edel Asus Intel-Chips-only Board, ist es nicht besser geworden!


    • Die Karten mal in anderen PCI Slots zu betreiben, habe ich natürlich auch schon versucht!


    Olaf hilf mir, warum geht es bei dir mit 4 DVB- und 1 Analog Karte(n)
    und bei mir läuft es nicht mal mit lumpigen 2... :weinen


    Also in diesem Sinne:

    Code
    TuxVision vdr[6242]: ERROR: video data stream broken


    PS: Wenn es bis Weihnachten nicht gelöst ist, dann werde ich den Windowsweg versuchen, Neuinstallieren!
    Dann aber LFS

    Hallo Ank,


    isch hab echt keinen Plan...ich kann dir nur ma schreiben, was ich genau für nen Board habe, welche Bios-Version ich einsetze, was in meiner Kernelconfig alles drin ist und was für Karten ich genau habe.


    Das können wir gerne per PM, aber so das Superrezept fällt mir jetzt hier auch an dieser Stelle auch nicht wirklich ein :(


    Ich nehme mal an, du wohnst nicht wirklich in meiner Ecke, sonst wäre das der nächste Schritt gewesen.


    Manchmal isses schon alles recht merkwürdig...


    Greets Olaf

    Ollie jetzt auch im Internet !!! ->> http://www.ohms.ws << VDR mit ASUS A7V8X-X, Athlon XP 2 Ghz, 512 MB DDR-RAM und gentoo 2008.0 Linux, ner Menge Platten (1 TB), 2 Brennern und Karten-Vollausstattung (1 X Nexus 4 MB Mod, 3 x Nova, 1 PVR 350) , TFT/Sony PSOne, Nvidia Graka und und und * Linux - wir geben ihrem Computer das Leben zurück *

    Zitat

    Original von olafhenkel
    Ich nehme mal an, du wohnst nicht wirklich in meiner Ecke


    Nee, nicht wirklich, grobe Richtung = Nürnberg.


    So ich glaube ich fange langsam an Grünemännchen zu jagen, aber folgende Beobachtung:


    Zusammen mit der Umstellung auf den neuen Kernel habe ich auch das VDR aktualisiert,
    da im ebuild aber das vdrshutdown.sh nicht richtig funktionierte,
    lief er einfach fast ne Woche durch bzw. war immer länger an als normalerweise.


    Seitdem der shutdown und nvram-wakeup wieder funktioniert
    bin ich aber zu der Erkenntnis gekommen, das der vdsb error nur auftritt wenn der VDR durch nvram geweckt worden ist
    und gleich nach dem Hochfahren damit beginnt etwas aufzuzeichen.


    Ja für alle kritischen Beobachter, ich weiss wie doof die Theorie ist,
    habe selbst schon über Users geschmunzelt die von Problemen beim "Kaltstart" bereichteten.


    PS: Ich kämpfe nicht alleine gegen Windmühlen, siehe ML
    http://www.linuxtv.org/mailing…003/09-2003/msg00001.html


    [EDIT]
    So hab jetzt mal 'was einbaut damit jede Karte schon mal einen Lock hatte,
    bevor der VDR überhaupt startet mal sehen, hoffentlich ist das "Der Bringer"


    [EDIT 2]
    Bringt gar nix, verfluchte scheiße, war der Analogreciever toll... :§$%

    Hallo Ank,


    du bist nicht alleine ;)


    Nutze übrigens auch nvram-wakeup !? Denke aber nicht das es daran leigt, eher an den kaltstart kurz vor aufnahme ...


    Hast du schon mal drüber nachgedacht die nvram-wakeup startzeit vorzuverlegen ?



    Ich habe jetzt eine neu (parallel) installation mit Suse 9.1 den ich jetzt produktiv nutze.


    Mit Suse 8.0 lief es sehr schlecht mit 2 x FF DVB-s (1.6/1.3) - immer wieder UPT und zwar wenn er für eine zeit gelaufen ist.
    Als ich dann wieder meine Nova als zweite karte eingebaut hatte lief es alles viel besser. Nur selten hatte ich bei der ersten aufnahme (kurz nach aufwachen) einen VDSB error, da aber die erste datei 0 bytes groß ist tut es nicht so "weh". Alle aufnahmen danach leifen durch :)
    Ich hatte so gut wie immer vorher "IRQ Loop" fehler beim starten von VDR im syslog !? so das ich irgendwann einfach ein script geschrieben habe der VDR in dem falle der "IRQ Loop" neu startet dann ar alles gut :).


    So jetzt mit Suse 9.1 und kernel 2.6 ist alles anders. Mit 1xFF (1.6) und die WinTV Nova-s klappte es überhaupt nicht. VDR folg mir nur so um die ohren, egal was für einen treiber/kernel ich genommen habe ...
    Als ich dann wieder meine zweite FF eingebaut habe (rev. 1.3) lief es wieder sehr stabil :)


    Ich habe manschmal immer noch einen VDSB bei der ersten aufnahme, aber seit 1.3.14 bisher nicht (läuft schon seit 5 tagen ohne :)) Wobei ich selten eine aufnahme direkt nach dem aufwachen hatte ...


    Die Zweite karte hat einen eigenen IRQ, die erste teilt sich einen mit der Netwerkkarte und Soundkarte (anders geht es leider nicht :()


    Gruß
    Viking

    Tja auch ich bin im Club.


    Oct 26 21:44:13 chaplin vdr[2303]: ERROR: video data stream broken


    Muss dann wohl mal auf 1.3.15 umsteigen.

    debian 6.0.7 64-bit, kernel 3.10.0, 2xBudget-CI,Cine S2 V6.5,vdr (2.0.2/2.0.0), vdr-sxfe,remote-plugin + EPSON EH-TW4400 HD Beamer :)

    AnK


    Hallo,


    anbei wie per PM besprochen :)


    Greets Olaf

    Dateien

    Kernel.conf 30,73 kB – 89 Downloads

    Ollie jetzt auch im Internet !!! ->> http://www.ohms.ws << VDR mit ASUS A7V8X-X, Athlon XP 2 Ghz, 512 MB DDR-RAM und gentoo 2008.0 Linux, ner Menge Platten (1 TB), 2 Brennern und Karten-Vollausstattung (1 X Nexus 4 MB Mod, 3 x Nova, 1 PVR 350) , TFT/Sony PSOne, Nvidia Graka und und und * Linux - wir geben ihrem Computer das Leben zurück *

    Habe keine Probleme seit 1.3.15 und 2.6.10-rc1.


    Mal schaun wie lange noch.



    Gruss,


    Jörg

    debian 6.0.7 64-bit, kernel 3.10.0, 2xBudget-CI,Cine S2 V6.5,vdr (2.0.2/2.0.0), vdr-sxfe,remote-plugin + EPSON EH-TW4400 HD Beamer :)

    Hallo,


    Zitat

    Original von AnK
    Bei mir tritt der vdsb error trotz VDR 1.3.14 und Kernel 2.6.10
    bzw dvb-cvs treiber auf, meistens jedoch nur beim Kaltstart!


    wie gesagt, du könntest ja dann evt. die nvram-wakeup vorlaufzeit, ich glaube es ist normalerweise 10 min., auf eine stunde oder so etwas erhöhen. Vieleicht muß die karte erst "warm" werden.


    Habe jetzt auf vdr-1.3.15 umgestellt - jetzt wieder mit LD_ASSUME - mal schauen ob es gut geht ...


    Gruß
    Viking

    Hallo,


    ich habe richtig schön reproduzierbar den VDSB.
    System:
    Suse 9.0
    Kernel 2.6.8.1
    dvb-CVS (diverse von Juli bis 14.11.2004)
    vdr-1.3.1[235] mit einigen Plugins
    1 FF 2.1
    1 Budget


    Der vdr-1.3.12 mit irgendeinem Patch (dvbdevice oder sowas) hat nie Probleme. Läuft perfekt.


    Alle ab 1.3.13 haben den VDSB, wenn man eine Aufnahme startet (Pause-Taste oder Timer) und der VDR schon etwas länger (30 min) läuft (EPG-Scan abgeschlossen, oder Budget im sleep?). Es gibt dann einen VDR-Restart mit Neuladen der Treiber - das hilft aber nicht. Erst nach einem Kaltstart (Reset) läuft der VDR und die Aufzeichnung wird durchgeführt.


    Frisch gebootet (Timer-Aufnahme) nehmen auch die Versionen ab 1.3.13 problemlos auf.


    Kann ich beim debuggen helfen, auch wenn es eine suse ist ;) ?


    Thomas

Jetzt mitmachen!

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

Benutzerkonto erstellen Anmelden