massenhaft Einträge Audio-/Videorepacker in syslog

Hi,

ich habe den Patch nochmals überarbeitet.

Bye.

Na dann hoffe ich mal, daß der sich genau so gut auch auf 1.3.37 anwenden läßt, wie die erste Version...

Vielen Dank!

Hi,
erst mal muss ich diesem Thread danken. Ihr habt mich mal wieder aus einer völlig verzweilfelten Situation gerettet.
Ich habe vor kurzem auf 1.3.37 upgegradet (vorher 1.2.26) weil ich endlich DD haben wollte. (Nexus-S FF) Seit diesem Upgrade (bei dem ich auch von SuSE 9.1 auf 10.0 und von einer 266MHz CPU auf eine 1000MHz CPU gewechselt habe) funktionierten plötzlich keine Aufnahmen mehr. Will sagen ich hatte alle zwei drei Sekunden ziemlich grobe JPEG Artefakte und Jitter im Ton. Natürlich hab ich wie manch einer hier im Thread erst mal an den Kernel gedacht (DMA Modus, IDE unterstützung etc.) Mein altes System mit der ziemlich mageren CPU hatte NIE probleme. Letztendlich hat aber dieser Thread geholfen. Und zwar eins der ersten Postings. Ich habe die zwei TEST_c*Repacker defines auskommentiert um die Repacker zu deaktivieren. Dann neu compiliert und schwups - alles wieder in ordnung. Vorher hatte ich ca. 50% meines Logfile voll mit Meldungen a la:

Dec 27 16:48:16 tv vdr[3223]: cAudioRepacker(0xC0): skipped 130 bytes to sync on next audio frame

Die Probleme hatte ich auf allen Kanälen. Ich werde mich vielleicht auch noch an die anderen Patches und TS continuity geschichten ransetzen um mehr Details zur Problembehebung beizusteuern. Letztendlich kann ich aber bisher nur sagen: Lasst bitte die Repacker so wie im Moment auskommentierbar. Die Idee ist gut, die Umsetzung anscheinend noch suboptimal. Insbesondere mit meiner alten CPU hätte ich eh keine Chance mehr gehabt. Und dafür hab ich ja schließlich die FF Karte für teuer Geld gekauft. Damit die CPU nicht so schnell sprich laut sein muss.

Muss mich leider korrigieren. Das Deaktivieren der Repacker hat nicht zum gewünschten Erfolg geführt. Zwar sind die Aufnahmen nur noch auf wenigen Kanälen Fehlerhaft (BR Alpha ist der schlimmste) aber das ist absolut nicht akzeptabel, da ich vorher mit einem 266er PII und genau der gleichen Platte keine Probleme hatte. Ich habe auch mal VDR 1.3.22 probiert, half aber auch nicht. Jetzt setze ich nochmal ein System mit SuSE 9.1 auf (Kernel 2.6.4) da ich nun den 2.6.13er Kernel von der SuSE 10 im Verdacht habe. Ich melde mich dann wieder wenn ich das ganze fertig habe.

So. Jetzt hab ich nochmal eine Nacht bis drei Uhr morgens rumexperimentiert und bin zu folgender Erkenntnis gekommen: Es ist das Mainboard. Ich weiß zwar nicht, warum ein ASUS P3V133 mit einer 1GHz CPU schlechter daher kommt als ein weißnichtwiealtes ASUS Board mit einer PII 266MHz CPU aber so ist das Leben nun mal. Auf manche Fragen gibt es einfach keine Antworten. Beobachten bzw. hören konnte ich zumindest folgendes: Mit dem schnellen Board hat die Platte gerappelt wie sonst was. Das gnaze Gehäuse hat gezittert. Ich hab auch ein wenig mit dem cUnbufferedfile rumexperimentiert und die Buffer kleiner gemacht (1Mb). Dadurch schrieb der VDR öfter und auch ein wenig kontinuierlicher auf Platte und es kam zu weniger Fehlern. Aber ganz weg bekam ich die Fehler nur mit dem alten Board. Das läuft jetzt auch brav mit SuSE 10.0, 2.6.13er Kernel und 1.3.37er VDR. Ich werd jetzt mal ein BIOS update auf das schnellere Board hetzen und schauen, warum die Platte so grottenschlecht performed hat. hdparm -tT hat brav 390Mb cached und 40Mb buffered disk reads gemeldet und natürlich ist auch UDMA 4 an. Trotzdem ist die Platte am langsamen Board viel ruhiger und die Aufnahmen klappen auch besser, obwohl hdparm nur 160Mb / 20 Mb transferrate bescheinigt. Was ich bei dem P3V133 auch sehr merkwürdig fand ist, dass Aufnahmen auf ein NFS share auch fehlerhaft sind. Es scheint also gar nicht so sehr an der Platte zu liegen sondern vielmehr am PCI Bus oder was auch immer. Ich hoffe mal ein BIOS Update bringt da Besserung. Ansonsten vielleicht auch noch PCI-Slots tauschen etc. Das übliche Drama halt. Aber der Wohnzimmer-VDR läuft jetzt erst mal mit dem 266MHz Board weiter und die c*Repacker hab ich auch wieder aktiv. DivX schau ich mir halt wieder aufm DVD-Player an. Vielleicht hat ja einer von euch auch Erfahrungen mit o.g. ASUS Board - auch wenn es in diesen Thread eigentlich nicht 100% rein gehört.

(bitte nicht schlagen, hab das in einem anderen thread...) auch schon gepostet)

Hi xnalpf!

Wollte Dir nur sagen, dass Du nicht der einzige bist!!!

Update von PII400 mit 256MB auf PIII800 mit 512MB: resultat: cAudiorepacker Fehler en masse....

nach langem Ärgern hab ich den zweiten ide-kanal als schuldigen identifiziert: wenn ich auf hda aufnehme kein problem, auf hdc oder hdd krachts ....

vielleicht hilft diese feststellung ja bei der lokalisierung des problems (vielen dank an Reinhard für das verbratene Gehirnschmalz!!!)

Werde das aukommentieren heut noch testetn und mich wieder melden...

lg
Bax

Ja, mit primärem und sekundärem IDE-Kanal hab ich auch rumgespielt. In meinem ursprünglichen Setup war der DVD-Brenner am sekundären und die Platte am primären Kanal. Das war die reine Hölle. Dann hab ich den Brenner mit an den Kanal der PLatte gepappt und es wurde besser. Aber eben nicht gut. (Alles 80-Adrige Kabel und der Brenner läuft mit UDMA 2)
Was mich am meisten verwundert ist halt, dass es im alten Board prima läuft, egal ob ein oder zwei Kanäle und egal ob mit oder ohne Brenner. Und dass die Platte mit dem schnellen Board so laut rumrappelt wenn sie schreibt.
Aber ich werde weiter rumexperimentieren. Jetzt kann ich ja wenigstens wieder sauber aufnehmen. (Mit dem alten Board)

Hallo Leidenskollege!

Der Wife Acceptance Faktor war mit dem neueren Board und Prozessor dafür mit defekten Aufnahmen eher gering: "Wozu brauchen wir einen schnelleren Prozessor wenn es dann nicht geht?" - Berechtigte Frage, "Weil es eigentlich schneller sein sollte ..." hmmmm

Jedenfalls: altes Board angesteckt, karten rumgepfropft, panisch syslog und messages nach cAudioRepacker Fehlern durchsucht - geht alles wieder....

Tja fürs erste bleib ich dem PII400 treu, wenn Du "die Lösung" findest, mal schaun, vielleicht probier ichs mal wieder

lg
Bax

PS: Getestet: 2.6.12, 2.6.14, 2.6.15, IDE 2 ausschalten, PCI-Raid Controller hinein, Aufnahmen nur uaf spezielle Platten leiten, sämtliche Bios Parameter, Kabel auf Sitz geprüft, Reihenfolge Master Slave gewechselt, und so weiter - grrrrrrr

Zitat

Original von rnissl
Hi,

ich habe den Patch nochmals überarbeitet.
vdr-1.3.36-remux2.patch.gz (1 KB, 80 mal heruntergeladen)

Bye.

Hi,

brauchts den Patch bei vdr-1.3.41 auch noch?

Aktuell habe ich 1.3.38, dvb-cvs und neueste firmware, und schaffe es nicht, einen Film fehlerfrei von Premiere aufzunehmen. Wenn ich nichts mache waehrend der Aufnahme (nicht umschalten, keine Wiedergabe bestehender Aufnahmen), dann kommt ab und an zwar kein c*Repacker Fehler, aber vdrsync meldet trotzdem Fehler in der Aufnahme ("cut detected").

Ich werde es jetzt nochmal mit 1.3.41, plain vanilla (+cUnbufferedFile Patch v5) versuchen.

So, die Aufnahmen heute Nacht haben fehlerlos geklappt. Allerdings habe ich die Audio- und VideoRepacker deaktiviert, dafuer findet vdrsync keine Fehler. Also werde ich es erstmal so belassen.

Zitat

Original von andreash
Allerdings habe ich die Audio- und VideoRepacker deaktiviert

kannst Du mal beschreiben, wie Du das gemacht hast? ich habe auch den Verdacht, dass die repacker den Stream unnötig verschlimmbessern.

Zitat

Original von Dr. Seltsam
... ich habe auch den Verdacht, dass die repacker den Stream unnötig verschlimmbessern.

Hallo Dr. Seltsam,

same Problem bei mir, auch mit Deinem letzten Kernel. Du bist ja immer sehr um Aktualität bemüht und hast eine der letzten Firmwares aus dem CVS integriert.

Wenn ich das richtig gelesen habe, gibts die Repacker aber offenbar erst in den letzten Firmware-Versionen. Ist es zu einfach gedacht, wenn man dann einfach zunächst mal wieder auf eine ältere Firmware zurückswitcht? Kann ich die einfach mit "Copy&Paste" austauschen?

Starter

ich mag nicht so recht an die Firmware als Ursache glauben. Da hat sich in den letzten Versionen eigentlich auch nur was in bezug auf WSS (16:9) getan.

Hingegen sind seit 1.3.38 die repacker-Routinen in vdr erweitert worden. Interessant wäre nun, ob das Problem mit 1.3.37 auch auftritt.

Zitat

Original von Dr. Seltsam
Interessant wäre nun, ob das Problem mit 1.3.37 auch auftritt.

Ja leider, ich habe 1.3.37 laufen, aktueller Log:

Feb  1 21:33:41 linvdr user.err vdr[7038]: cDolbyRepacker: skipped 824 bytes to sync on next AC3 frame
Feb  1 21:33:41 linvdr user.err vdr[7038]: cDolbyRepacker: skipped 840 bytes to sync on next AC3 frame
Feb  1 21:33:42 linvdr user.err vdr[7038]: cDolbyRepacker: skipped 456 bytes to sync on next AC3 frame
Feb  1 21:33:42 linvdr user.err vdr[7038]: cDolbyRepacker: skipped 104 bytes to sync on next AC3 frame
Feb  1 21:33:42 linvdr user.err vdr[7038]: cAudioRepacker(0xC0): skipped 24 bytes to sync on next audio frame
Feb  1 21:33:42 linvdr user.err vdr[7038]: cAudioRepacker(0xC0): skipped 24 bytes to sync on next audio frame
Feb  1 21:33:42 linvdr user.err vdr[7038]: cAudioRepacker(0xC0): skipped 16 bytes to sync on next audio frame
Feb  1 21:33:42 linvdr user.err vdr[7038]: cDolbyRepacker: skipped 472 bytes to sync on next AC3 frame
Feb  1 21:33:42 linvdr user.err vdr[7038]: cDolbyRepacker: skipped 16 bytes to sync on next AC3 frame
Feb  1 21:33:42 linvdr user.err vdr[7038]: cDolbyRepacker: skipped 704 bytes to sync on next AC3 frame
Feb  1 21:33:42 linvdr user.err vdr[7038]: cAudioRepacker(0xC0): skipped 400 bytes to sync on next audio frame
Feb  1 21:33:42 linvdr user.err vdr[7038]: cAudioRepacker(0xC0): skipped 24 bytes to sync on next audio frame
Feb  1 21:33:42 linvdr user.err vdr[7038]: cAudioRepacker(0xC0): skipped 392 bytes to sync on next audio frame
Feb  1 21:33:42 linvdr user.err vdr[7038]: cAudioRepacker(0xC0): skipped 16 bytes to sync on next audio frame

Edit:

War auch schon unter 1.3.36, habe erst heute auf 1.3.37 upgedatet. Ich stelle das Problem aber erst seit ein paar Tagen fest, nachdem mein VDR in letzter Zeit ab und zu restartet, was er vorher (seit Erscheinen von 1.3.36 und unter Deinem Kernel 2.6.14 und 2.6.14.2) nie gemacht hat.

Starter

Zitat

Original von Dr. Seltsam

kannst Du mal beschreiben, wie Du das gemacht hast? ich habe auch den Verdacht, dass die repacker den Stream unnötig verschlimmbessern.

In remux.c nach "TEST" suchen. Dort gibt es zwei defines:
#define TEST_cVideoRepacker
#define TEST_cAudioRepacker

Beide auskommentieren:
//#define TEST_cVideoRepacker
//#define TEST_cAudioRepacker
und vdr neu kompilieren (die "ifdefs" in Ruhe lassen).

Ich weiss nicht, ob ich damit vielleicht nur die Fehler unterdruecke, die der Repacker sonst erkennen wuerde. Allerdings hatte ich auch mit aktivierten logging dafuer keine "TS continuity error", die zwangslaeufig Repacker-Fehler nach sich ziehen wuerden.

Das einzige, was ich jetzt noch ab und an im Log habe, sind cDolbyRepacker Meldungen. Mal sehen, ob ich den auch noch deaktiviere, aber fuers erste werde ich es mal beobachten.

Heute abend wieder dasselbe Problem:

Live-Programm läuft auf meiner TT-1.6, während im Hintergrund ein Timer auf der Budget-Karte mit der Aufnahme beginnt. Das führt sofort zu den Problemen:

Feb  2 22:42:05 linvdr user.err vdr[3269]: cAudioRepacker(0xC0): skipped 16 bytes to sync on next audio frame
Feb  2 22:42:05 linvdr user.err vdr[3269]: cDolbyRepacker: skipped 992 bytes to sync on next AC3 frame
Feb  2 22:42:05 linvdr user.err vdr[3269]: cDolbyRepacker: skipped 696 bytes to sync on next AC3 frame
Feb  2 22:42:05 linvdr user.err vdr[3269]: cAudioRepacker(0xC0): skipped 128 bytes to sync on next audio frame
Feb  2 22:42:05 linvdr user.err vdr[3269]: cAudioRepacker(0xC0): skipped 24 bytes to sync on next audio frame
Feb  2 22:42:05 linvdr user.err vdr[3269]: cAudioRepacker(0xC0): skipped 416 bytes to sync on next audio frame
Feb  2 22:42:05 linvdr user.err vdr[3269]: cDolbyRepacker: skipped 872 bytes to sync on next AC3 frame
Feb  2 22:42:06 linvdr user.err vdr[2883]: ERROR: thread 6150 won't end (waited 3 seconds) - canceling it...
Feb  2 22:42:06 linvdr user.info vdr[2883]: stopping plugin: solitaire

Feb  2 22:42:07 linvdr user.debug vdr[2883]: max. latency time 14 seconds
Feb  2 22:42:07 linvdr user.info vdr[2883]: exiting
Feb  2 22:42:07 linvdr user.err vdr[2883]: emergency exit!
Feb  2 22:42:16 linvdr user.warn kernel: saa7146: unregister extension 'budget_av'.
Feb  2 22:42:16 linvdr user.warn kernel: saa7146: unregister extension 'budget_ci dvb'.

Feb  2 23:01:24 linvdr user.err vdr[4135]: cDolbyRepacker: skipped 288 bytes to sync on next AC3 frame
Feb  2 23:01:24 linvdr user.err vdr[4135]: cAudioRepacker(0xC0): skipped 208 bytes to sync on next audio frame
Feb  2 23:01:24 linvdr user.err vdr[4114]: ERROR: unknown picture type '4'
Feb  2 23:01:24 linvdr user.err vdr[4114]: initiating emergency exit
Feb  2 23:01:24 linvdr user.err vdr[4134]: ERROR: unknown picture type '4'
Feb  2 23:01:24 linvdr user.err vdr[4115]: cDolbyRepacker: skipped 840 bytes to sync on next AC3 frame
Feb  2 23:01:24 linvdr user.err vdr[4115]: cDolbyRepacker: skipped 16 bytes to sync on next AC3 frame
Feb  2 23:01:24 linvdr user.err vdr[4135]: cDolbyRepacker: skipped 840 bytes to sync on next AC3 frame
Feb  2 23:01:24 linvdr user.err vdr[4135]: cDolbyRepacker: skipped 16 bytes to sync on next AC3 frame
Feb  2 23:01:24 linvdr user.err vdr[4115]: cAudioRepacker(0xC0): skipped 392 bytes to sync on next audio frame
Feb  2 23:01:24 linvdr user.err vdr[4135]: cAudioRepacker(0xC0): skipped 392 bytes to sync on next audio frame
Feb  2 23:01:24 linvdr user.err vdr[4115]: cAudioRepacker(0xC0): skipped 16 bytes to sync on next audio frame
Feb  2 23:01:24 linvdr user.err vdr[4135]: cAudioRepacker(0xC0): skipped 16 bytes to sync on next audio frame
Feb  2 23:01:25 linvdr user.err vdr[4115]: cDolbyRepacker: skipped 152 bytes to sync on next AC3 frame
Feb  2 23:01:25 linvdr user.err vdr[4135]: cDolbyRepacker: skipped 152 bytes to sync on next AC3 frame
Feb  2 23:01:25 linvdr user.err vdr[4115]: cDolbyRepacker: skipped 840 bytes to sync on next AC3 frame
Feb  2 23:01:25 linvdr user.err vdr[4135]: cDolbyRepacker: skipped 840 bytes to sync on next AC3 frame
Feb  2 23:01:25 linvdr user.err vdr[4084]: emergency exit requested - shutting down
Feb  2 23:01:25 linvdr user.info vdr[4084]: stopping plugin: weatherng
Feb  2 23:01:25 linvdr user.info vdr[4084]: stopping plugin: tvonscreen
Feb  2 23:01:25 linvdr user.info vdr[4084]: stopping plugin: trayopen

Schalte ich dann auf den Kanal (ProSieben Austria) wo die Aufnahme läuft, sind dort auch Klötzchen zu sehen und Femon zeigt eine BER die nicht mehr 0 ist.

Ich habe dann mal den Timer gelöscht und damit die Aufnahme gestoppt und zunächst eine Aufnahme auf einem anderen Transponder (ZDF) -auf der Budget-Karte- gestartet, um dann anschließend wieder ProSieben Austria aufzunehmen -auf der TT-Karte-. Problem verschwunden! Auch wenn ich nun wieder wechsle und die ProSieben Austria-Aufnahme auf der Budget mache, tritt kein Problem mehr auf.

Sieht für mich so aus, als ob durch mehrfaches "Retuning" die Budget wieder sauber aufnimmt. Ich meine auch schonmal früher von solchen Problemen mit Budgets gelesen zu haben...

Die Firmware habe ich bereits auf FD2623 aktualisiert, liegts am VDR oder am DVB-Treiber?

Starter

Hat sich eigentlich in der Zwischenzeit in dieser Richtung was getan?
Hintergrund der Frage ist, dass ich heute morgen ein Syslog mit mehr als 1,5 MB hatte, welches fast komplett aus cAudioRepacker und PES packet shortened Fehlern bestand. Ich muss gleich mal gucken, ob die beiden Aufnahmen von gestern abend was abbekommen haben, aber ich vermute es fast

Reihnold
leider nicht viel,(oder doch? bitte korrigieren falls ich was nicht mitbekommen habe)
mein derzeitiger Erkenntnisstand:
1. kernel konfiguration prüfen ob preemtives Multitasking an ist und die Timerfrequenz auf 1000Hz steht
2. in /boot/grub/menu.lst den kernelparameter elevator=cfq setzen
3. (gestern ausprobiert) im VDR die maximale Dateigrösse auf 100MB gestellt, dann bleibt auch beim Schneiden eines > 3GB Films und fast voller Platte das OSD noch erträglich schnell, aber das Schneiden wird langsamer( macht nichts).

Frage : hat mal jemand ext3 für die videoplatte getestet?
Viele Grüsse Frithjof

Nachtrag:
in
/usr/src/linux/drivers/media/dvb/dvb-core/dmxdev.h
habe ich nach einem Hinweis aus dem DVB Forum noch

#define DVR_BUFFER_SIZE (100*188*1024) // war 10*188*1024
eingestellt

Zitat

Original von frithjof
Frage : hat mal jemand ext3 für die videoplatte getestet?

Hatte noch nie etwas anderes. Null problemo.

CU
Oliver