Nach Systemupdate Klötzchen und Hänger

    Hallo!


    Ich habe gestern von woody auf sarge, von einem 2.4er auf den Kernel 2.6.13 und auf den aktuellen CVS-DVB-Treiber aktualisiert. Vorher lief der vdr absolut stabil, auch bei mehreren Aufnahmen gleichzeitig. Jetzt bekomme ich Klötzchen schon bei einer Aufnahme im Hintergrund. Bei zwei Aufnahmen steigt er dann irgendwann aus:


    Und auch cVideoRepacker taucht ab und zu mal auf:


    Bei Klötzchenbildung, bzw. kurzem Bildeinfrieren kann ich beobachten, dass der vdr kurzzeitig die CPU ausnutzt, aber das mag nur ein Folgeproblem sein und nicht die Ursache.


    Die Auskommentierung von TEST_cVideoRepacker in remux.c habe ich schon probiert, leider ohne Besserung.


    Hat jemand einen Tip für mich?


    Marcus


    (LiveBuffer ist zur Zeit ausgeschaltet; Downgrade auf die Firmware dvb-ttpci-01.fw-261f brachte auch keine Änderung)

    Mein vdr:
    Coolermaster 620 Case; Mobo P4S800-MX (SiS 661FX); Celeron Northwood 2.4Ghz;CPU-Lüfter Super Silent 4 Ultra TC
    Debian Sarge; kernel 2.4.28; CVS DVB-Treiber 080905; Nexus und Nova;
    vdr-1.4.0 mit Bigpatch; Werner Fink's AV7110 AC3-firmware-2620

    Einmal editiert, zuletzt von mini ()

    Hi,


    ja, ich hab das Problem auch seit einer Weile. Da ich öfter mal neue vdr Versionen teste und die skystar2 bei mir die sekundäre Karte ist, ist es mir erst gar nicht aufgefallen, auf der primären, einer DVB-s FF ist alles ok.
    Ich hab schon ziemlich viel ausprobiert, dachte zuerst gar, meine Schüssel wäre verdreht. Am rewrite der sykstar2 Treibers liegt es wohl auch nicht, ich glaube mit dem original skystar2.ko modul treten die Fehler auch auf.


    Dann habe ich festgelstellt, mit einer gebooteten Kanotix ist alles 1a, also ist die Hardware komplett ok.


    Ich muss mal weiter testen *seufz* :(


    P.S.: ich habe natürlich auch mal testweise alle plugins deaktiviert, hat aber nix gebracht

    Welchen Kernel und welche Version von vdr, dvb-Treiber und firmware benutzt du denn? Vielleicht können wir es ja eingrenzen.


    Marcus

    Mein vdr:
    Coolermaster 620 Case; Mobo P4S800-MX (SiS 661FX); Celeron Northwood 2.4Ghz;CPU-Lüfter Super Silent 4 Ultra TC
    Debian Sarge; kernel 2.4.28; CVS DVB-Treiber 080905; Nexus und Nova;
    vdr-1.4.0 mit Bigpatch; Werner Fink's AV7110 AC3-firmware-2620

    Das Verrückte ist, es läuft hier jetzt mit nem frisch installierten mini-debian mit dem gleichen kernel 2.6.13, der gleichen firmware (f) und mit dem gleichen vdr 1.3.31 anstandslos mit dem es auf meiner normalen Installation nicht tat.
    Allerdings hatte ich mit der alten Installation mit nem 2.6.9er kernel und einem vdr 1.3.22 deutlich weniger Probleme.


    Ich bin zZ recht ratlos. Es kann eigtl. nur durch irgendeinen Hintergrund-Prozess oder irgendwelche anderen shared libs zu dem Effekt kommen.


    Zum Testen stelle ich nen Kanal mit hoher Bandbreite fest auf DVB2 ein und starte uf der DVB1 eine Aufnahme. Dann passieren die Probleme recht oft.

    Um es vielleicht mal etwas allgemeingültiger zu machen hier nochmal ein komplettes Log (vom start bis emergency exit) unter einem plain vanilla vdr.


    vdr 1.3.31 ohne patches und plugins
    CVS-DVB-Treiber von heute
    Firmware 261f
    Kernel 2.6.13


    Beim Start existieren zwei aktive Timer.


    Mein vdr:
    Coolermaster 620 Case; Mobo P4S800-MX (SiS 661FX); Celeron Northwood 2.4Ghz;CPU-Lüfter Super Silent 4 Ultra TC
    Debian Sarge; kernel 2.4.28; CVS DVB-Treiber 080905; Nexus und Nova;
    vdr-1.4.0 mit Bigpatch; Werner Fink's AV7110 AC3-firmware-2620

    Zitat

    Original von mini
    Um es vielleicht mal etwas allgemeingültiger zu machen hier nochmal ein komplettes Log (vom start bis emergency exit) unter einem plain vanilla vdr.


    vdr 1.3.31 ohne patches und plugins


    Für 1.3.31 gibt es einen Repacker-Fix von Reinhard. Den sollte man unbedingt einspielen, sonst kriegt man möglicherweise beschädigte Aufnahmen.


    CU
    Oliver

    Zitat

    Original von UFO


    Für 1.3.31 gibt es einen Repacker-Fix von Reinhard. Den sollte man unbedingt einspielen, sonst kriegt man möglicherweise beschädigte Aufnahmen.


    CU
    Oliver


    Ich habe gerade danach gesucht, von "Reinhard" existieren gerade mal so vier Beiträge, und mit "Repacker-Fix" hab ich auch so ad hoc nichts neues gefunden. Kannst du uns bitte nen Hinweis geben, wo wir das finden?

    Gemeint ist wohl


    http://home.vrweb.de/~rnissl/vdr-1.3.31-dvbplayer5.patch


    von Roland Nissl. (Siehe auch http://home.vrweb.de/~rnissl/vdr-patches-README.txt und http://home.vrweb.de/~rnissl/)


    Weder dieser Patch noch die auf der Mailingliste von Roland gepostete aktualisierte Version von remux.c brachte meinem vdr Linderung. :(


    Gruss,
    Marcus

    Mein vdr:
    Coolermaster 620 Case; Mobo P4S800-MX (SiS 661FX); Celeron Northwood 2.4Ghz;CPU-Lüfter Super Silent 4 Ultra TC
    Debian Sarge; kernel 2.4.28; CVS DVB-Treiber 080905; Nexus und Nova;
    vdr-1.4.0 mit Bigpatch; Werner Fink's AV7110 AC3-firmware-2620

    Zitat

    Original von Pilotfish
    [Ich habe gerade danach gesucht, von "Reinhard" existieren gerade mal so vier Beiträge, und mit "Repacker-Fix" hab ich auch so ad hoc nichts neues gefunden. Kannst du uns bitte nen Hinweis geben, wo wir das finden?


    Ich meinte den Fix von der ML:
    http://linuxtv.org/pipermail/vdr/2005-September/004793.html


    CU
    Oliver

    mini: was hast du denn für DVB Hardware? Der Firmware nach zu urteilen zumindest eine FF, aber sonst?


    Bei mir spackt nur die SS2 rum, und ich vermute auch, dass es nicht an vdr liegt sondern dass die Karte einfach Fehler im Strom produziert. Der Artikel von der maillingliste bestärkt diese Vermutung.


    Ich habe ja auch nicht nur die Meldungen im log sondern auch klötzchen wenn ich mit der SS2 live kucke, ich tippe auf ein Treiberproblem.


    Ich weiß nicht, ob man mal eben einen älteren Treiber für nen 2.6er kernel übersetzen und installieren kann, muss heute Abend mal kucken.

    Pilotfish: Eine Nexus und eine Nova und soweit ich verstehe macht auch bei mir die Budgetkarte Probleme.


    EDIT: Stimmt doch nicht. Wenn ich zwei Aunahmen auf unterschiedlichen Transpondern und damit unterschiedliche Karten starte, dann habe ich nacher in beiden Aufzeichnungen Störungen.


    > Ich weiß nicht, ob man mal eben einen älteren Treiber für nen 2.6er kernel
    > übersetzen und installieren kann, muss heute Abend mal kucken.


    Den Versuch habe ich jetzt einigermassen entnervt aufgegeben. Nicht leicht Kombinationen zu finden die kompilieren und immer wieder testweise Kernel backen dauert mir zu lange.


    Mag jetzt überhaupt nichts damit zu haben, aber ich überleg halt was an meinem vorherigen 2.4er Kernel anders war: Wozu stehen stehen im insmod.sh vom DVB-Treiber die folgenden modprobes: i2c-core, crc32, firmware_class, videodev, v4l1-compat, v4l2-common? Die Module habe ich alle nicht und der vdr läuft trotzdem.


    Gruss,
    Marcus

    Mein vdr:
    Coolermaster 620 Case; Mobo P4S800-MX (SiS 661FX); Celeron Northwood 2.4Ghz;CPU-Lüfter Super Silent 4 Ultra TC
    Debian Sarge; kernel 2.4.28; CVS DVB-Treiber 080905; Nexus und Nova;
    vdr-1.4.0 mit Bigpatch; Werner Fink's AV7110 AC3-firmware-2620

    Einmal editiert, zuletzt von mini ()

    Ich lass nicht locker... :rolleyes:


    Wenn ich den vdr beende und bei geladenen CVS Treiber zweimal szap aufrufe


    Code
    ./szap -c channels.conf-dvbs-astra n24 -a 0
./szap -c channels.conf-dvbs-astra zdf -a 1


    bekomme ich absolut unauffällige Werte, also BER und UND auf 0 und SIGNAL und SNR zwischen a000 und d100.


    Mach ich einen Denkfehler oder heisst das, dass DVB-Treiber und firmware schuldlos sind und es ein vdr Problem ist?


    Marcus

    Mein vdr:
    Coolermaster 620 Case; Mobo P4S800-MX (SiS 661FX); Celeron Northwood 2.4Ghz;CPU-Lüfter Super Silent 4 Ultra TC
    Debian Sarge; kernel 2.4.28; CVS DVB-Treiber 080905; Nexus und Nova;
    vdr-1.4.0 mit Bigpatch; Werner Fink's AV7110 AC3-firmware-2620

    Hi,


    Zitat

    Original von mini

    Code
    Sep  8 13:14:44 vdr vdr[18364]: cAudioRepacker: skipped 579 bytes while syncing on next audio frame
Sep  8 13:14:44 vdr vdr[18364]: cAudioRepacker: skipped 96 bytes to sync on next audio frame
Sep  8 13:14:44 vdr vdr[18364]: cAudioRepacker: skipped 579 bytes while syncing on next audio frame
Sep  8 13:14:44 vdr vdr[18364]: cAudioRepacker: skipped 96 bytes to sync on next audio frame


    Anbei zwei alternative Dateien: die eine enthält nur die Fixes seit 1.3.31, und die andere zusätzlichen Logging-Code, wodurch evtl. das Problem ergründet werden kann.


    Bye.

    Hi,


    habe auch die selben Probleme wie zuvor beschrieben.


    Zitat

    Anbei zwei alternative Dateien: die eine enthält nur die Fixes seit 1.3.31, und die andere zusätzlichen Logging-Code, wodurch evtl. das Problem ergründet werden kann.


    Wie spiele ich den loggin code ein.
    Hat kein patchformat oder übersehe ich was ?


    Edit:
    Hab jetzt einfach die Datei kopiert.
    Wo findet man den Login code?


    Eine paar Erläuterungen wären hilfreich !


    Gruß
    kalium

    rnissl: Danke für's feedback. Ich habe mittlerweile entnervt aufgegeben und bin zurück zu meinem 2.4er Kernel. (Die volle Unterstützung meiner Fernbedienung, was der Grund für die Updates waren, habe ich jetzt dort auch realisieren können. Siehe hier)


    Vorher hatte ich allerdings nochmal deine logging version von remux.c laufen die du auf der Mailinglist gepostet hattest. Den gezippten Output von nur vielleicht 30 Sekunden Aufnahme auf beiden Karten findest du hier (ca. 890 KB).


    Es treibt mich jetzt nicht direkt zurück zum Kernel 2.6, aber wenn du einen Ansatz zum weiteren Testen und Debuggen hättest, könnte ich meine symlinks nochmal umbiegen.


    Gruss,
    Marcus

    Mein vdr:
    Coolermaster 620 Case; Mobo P4S800-MX (SiS 661FX); Celeron Northwood 2.4Ghz;CPU-Lüfter Super Silent 4 Ultra TC
    Debian Sarge; kernel 2.4.28; CVS DVB-Treiber 080905; Nexus und Nova;
    vdr-1.4.0 mit Bigpatch; Werner Fink's AV7110 AC3-firmware-2620

    Hi,


    Zitat

    Original von mini
    rnissl: Danke für's feedback. Ich habe mittlerweile entnervt aufgegeben und bin zurück zu meinem 2.4er Kernel. (Die volle Unterstützung meiner Fernbedienung, was der Grund für die Updates waren, habe ich jetzt dort auch realisieren können. Siehe hier)


    Vorher hatte ich allerdings nochmal deine logging version von remux.c laufen die du auf der Mailinglist gepostet hattest. Den gezippten Output von nur vielleicht 30 Sekunden Aufnahme auf beiden Karten findest du hier (ca. 890 KB).


    Es treibt mich jetzt nicht direkt zurück zum Kernel 2.6, aber wenn du einen Ansatz zum weiteren Testen und Debuggen hättest, könnte ich meine symlinks nochmal umbiegen.


    Ich benötige noch den zugehörigen Auszug aus /var/log/messages.


    Bye.

    Hi,


    Zitat

    Original von mini
    rnissl: Danke für's feedback. Ich habe mittlerweile entnervt aufgegeben und bin zurück zu meinem 2.4er Kernel. (Die volle Unterstützung meiner Fernbedienung, was der Grund für die Updates waren, habe ich jetzt dort auch realisieren können. Siehe hier)


    Vorher hatte ich allerdings nochmal deine logging version von remux.c laufen die du auf der Mailinglist gepostet hattest. Den gezippten Output von nur vielleicht 30 Sekunden Aufnahme auf beiden Karten findest du hier (ca. 890 KB).


    Es treibt mich jetzt nicht direkt zurück zum Kernel 2.6, aber wenn du einen Ansatz zum weiteren Testen und Debuggen hättest, könnte ich meine symlinks nochmal umbiegen.


    Ich habe trotztem mal eine Datei rausgegriffen. Ein

    Code
    od -Ax -w188 -v -t x1 ts_3918_-1390797904_0xC0_013_3011_100.log | less -S


    zeigt gegen Ende


    In der markierten Spalte folgen normalerweise die Ziffern 0-9 und A-F nacheinander. Fehlen ein oder mehrere Einträge, dann passiert dies typischerweise aufgrund atmosphärischer Störungen.


    Es kann aber auch ein Treiberproblem sein, oder ein Konfigurationsproblem des Systems (DMA, IRQ, etc.).


    Wenn unter Kernel 2.4 diese Probleme nicht auftreten, dann kann man die atmosphärischen Störungen wohl ausschließen.


    Wie ich in der Mailingliste geschrieben hatte, kann ich solche Probleme nicht fixen. Dass sie VDR jetzt meldet ist meines Erachtens sinnvoll, auch wenn viele Leute jetzt cAudioRepacker die Schuld für "zerstörte" Aufnahmen geben.


    Bye.

    Hi,



    Soweit hast du alles richtig gemacht. Man beachte aber den Unterschied von "Logging" != "Login" ;)


    In /var/log/messages (hier bei SuSE 9.3) sollten nun ähnliche Einträge auftauchen:

    Code
    Sep  9 21:32:35 video vdr[8291]: cAudioRepacker(0xC0): no valid audio frame header (0x5736B1A7) at expected location
Sep  9 21:32:35 video vdr[8291]: cTSLogger: dumping to file '/video/ts_8291_229387_0xC0_000_22_22.log'


    Die Logfiles enthalten dann die TS-Pakete, die zum Fehler führten und später auch diejenigen, welche cAudioRepacker wieder "eingeränkt" (= synchronisiert) haben.


    Interessant sind vor allem jene Dateien, welche erst ab ca. 60 Sekunden nach dem Start einer Aufnahme auftreten, da am Beginn aufgrund des Kanalwechsels solche Störungen normal sind und vernachlässigt werden können.


    Mit obigem "od" Kommando kann man die TS-Pakete anschauen und in der markierten Spalte den "continuity counter" prüfen. Wenn es hier Abweichungen gibt, dann liegt das Problem bereits vor VDR, d. h., Ausrichtung der SAT-Schüssel, Qualität von LNB und Kabeln, oder auch im Treiber bzw. System (IRQ, DMA, etc.).


    Bye.

    Ich reih' mich hier auch mal mit ein. Hab' gestern einen neuen Kernel 2.6.13(-0) gezogen und mit den aktuellen DVB-Treibern aus dem CVS gepatcht. Zusätzlich kam noch der vt1211-Patch (lm_sensors-Unterstützung für Epia-Mainboards) dazu.


    Hatte mit dem Kernel das gleiche Verhalten, bei zwei laufenden Aufnahmen waren sowohl Live-Bild als auch die Aufnahmen nicht zu gebrauchen.


    Zurück zu meinem 2.6.8 mit den Treibern aus 12/2004 und alles läuft butterweich. Ich hab' sogar das Gefühl, das bei dem 2.6.13 die Umschaltzeiten ein wenig länger sind und auch das Einblenden des OSD (Enigma-Skin) einen Tuck länger dauert (man sieht, wie das OSD von links oben nach rechts unten aufgebaut wird).

    VDR-User #992
    Server: Asrock N3700-ITX mit Cine S2 6.5 headless
    System: Ubuntu 22.04.LTS
    VDR: VDR 2.2.0 mit epgsearch, live, vnsiserver
    Client: Raspberry Pi v4 mit LibreElec

    Einmal editiert, zuletzt von Sledge Hammer ()

    Habe das gleiche Problem:
    Kurz nach der Aufnahme kackt VDR ab und schmeißt einen emergency exit aus.
    Allerdings nur bei Kanälen mit Dolby Unterstützung, auf Kanälen mit normalen Stereo Ton läuft alles prima.
    Habe folgende Konfig:


    Kernel 2.6.13.2
    vdr-1.3.30
    aktuelle cvs DVB Treiber
    Haupauge Nexus-S
    Haupauge Nova


    Habe hier im Forum gelesen, dass es das Problem mit dem 2.6.12 Kernel nicht geben soll. Werde mal downgraden und gucken wie es dann läuft.

Jetzt mitmachen!

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

Benutzerkonto erstellen Anmelden