massenhaft Einträge Audio-/Videorepacker in syslog

mbc · 20. November 2005

Hi Reinhard

Wie soll ich denn jetzt am besten vorgehen, kann leider keine eindeutige Zuordnung as deinem letzten Beitrag lesen.

Soll ich den Patch auch einmal anwenden und zusätzlich den cTSBuffer vergrößern ?

Wenn ja, auf welchen Wert kann man den Buffer vergrößern, was ist da sinnvoll ? Es gibt doch bestimmt einen Grund warum der von Anfang an nicht schon größer ist, oder ?

Mir persönlich wäre egal, ob die Fehler im Stream immer noch wären, das Problem ist (bei mir) halt, das die Aufnahmen, die vom Repacker korrigiert wurden, (zur Zeit noch) unbrauchbar sind ... das ist schade.
Bei mir scheints wie beschrieben an der Umschaltung des Formates zu liegen.

MFG
Marco

gerald · 20. November 2005

Hi,

denn patch habe ich jetzt noch nicht angwendet, allerdings habe ich heute mal einen Patch aus der ML getestet http://www.linuxtv.org/piperma…2005-November/006232.html
mit dem patch gab es keine audio oder videorepacker Nachrichten mehr in log-dateien.
Allerdings hat der Patch eine Macke wurde ebenfalls schon gepostet
http://www.linuxtv.org/piperma…2005-November/006263.html
Wenn die Aufnahme geschnitten wird und die geschnittenen Aufnahme sofort angeschaut wird hat man einen Bild hänger und läuft dann kurz danach wieder an. Anschliessend gabs bei mir keine Probleme, auch scheller Vorlauf getestet.

Gruss
Gerald

chock · 20. November 2005

Hi,

werde ich testen. Bin aber jetzt schon wieder auf die Versin von MT VDR1.3.24 zurückgegangen. Dort gib es keine Probleme.

Zitat

Original von rnissl
Hi,

deine Meldungen stammen aus user.err. Gibt es weitere Meldungen in anderen Logfiles (Vermutung: user.warn oder user.info)?

Hast du in remux.c, ts_to_pes() das loggen von TS continuity Fehlern eingeschaltet?

Wenn TS Fehler vorliegen können die c*Repacker nicht anders reagieren. cVideoRepacker nimmt eine Sonderstellung ein: da keine Längeninformationen vorliegen geht ein Frame immer bis zum nächsten Start-Code und wäre dann halt länger oder kürzer, aber trotzdem fehlerhaft (Klötzchen). Eine Meldung erscheint hier nur, wenn ein falscher Startcode (System-Startcode) gefunden wird.

Bzgl. TS Fehlern: evtl. hilft es, in dvbdevice.c, OpenDvr() den cTSBuffer zu vergrößern.

Bzgl. Premiere: man hat mir gemeldet, dass cVideoRepacker hier evtl. falsch arbeiten würde. Leider kann ich das nicht nachvollziehen (kein Premiere), und der Melder hat mich auch noch nicht unterstützt.

Bitte mal den Anhang einspielen, und falls tatsächlich was geloggt wird, mir bitte zukommen lassen.

Bye.

Alles anzeigen

rnissl · 20. November 2005

Hi,

ich habe jetzt um 20:15 das Problem beim Umschalten von Dolby 2.0 auf 5.1 auf Pro7 Austria nachvollzogen. Es geht tatsächlich ein TS-Paket verloren und infolge dessen meckert cDolbyRepacker.

Ich habe jetzt mal auf Pro7 umgeschaltet und beobachte mal den Übergang zum ersten Werbeblock.

Kann mal jemand in alten Logfiles nachschauen (evtl. noch zu einem Zeitpunkt, als VDR bis zu 5 Sekunden auf das Einrasten des Tuners (Tuner-Lock) gewartet hat), wieviele TS discontuities VDR am Ende einer Aufnahme oder beim Umschalten auf einen anderes Programm gemeldet hat?

Ich denke, dass das Problem schon länger besteht, aber man erst durch die Meldungen der c*Repacker darauf aufmerksam wird.

Ansonsten sollten sich durch Weglassen unvollständiger Frames keine Probleme ergeben. Ich werde mal den Übergang von 2.0 nach 5.1 auf Pro7 Austria aufnehmen. Wie kann ich dann das Problem mit der Aufnahme nachvollziehen (Software, Vorgehensweise)?

Bye.

rnissl · 20. November 2005

Hi,

also mein Patch ist nur zum Nachstellen des vermutlichen cVideoRepacker-Problems bei Premiere gedacht.

Was cUnbufferedFile betrifft: da ich keine FF-Karte habe, läuft bei mir immer der Transfer-Mode. Da ich trotzdem beim Übergang von 2.0 auf 5.1 eine TS discontinuity hatte kann es mangels Aufnahme eigentlich nicht an cUnbufferedFile liegen.

Bye.

rnissl · 20. November 2005

Hi,

also beim Übergang 5.1 auf 2.0 auf Pro7 gab es keine Probleme. Ich habe dann auf Pro7 Austria geschaltet, wo der Werbeblock noch nicht begonnen hatte, und eine Aufnahme gestartet.

Beim Übergang von 5.1. auf 2.0 gabs dann wieder ein TS discontinuity, und cDolbyRepacker hat sich beschwert.

Bye.

rnissl · 20. November 2005

Hi,

so, beim Übergang 2.0 auf 5.1 auf Pro7 Austria war wieder ein TS discontinuity zu beobachten und cDolbyRepacker hat wieder gemeckert.

Ich werde nun in Kürze die Aufnahme, welche nun zwei dieser Übergänge enthält, beenden. Was nun?

Bye.

mbc · 20. November 2005

Tut mir leid, ich kann nichts machen, da mein VDR 100km weit weg steht, ich komme frühtens zum WE erst wieder dran.

Was nun ??

Hmm ... eine gute Frage ... von mir aus kann das Frame wegbleiben .. sofern das keine anderen probleme macht.

Also als software zum umwandeln benutze ich unter windows Projectx ich kann dir einen Link zum runterladen schicken, sofern du e damit nachvollziehen möchtest ...

Ansonsten kannst du mir auch einen Patch schicken, der das Paket dann wegläßt, dann kann ich den am WE einspielen und die Aufnahme (muß sehen das ich dann eine erwische) direkt noch am WE prüfen.

BTW: DANKE fürs Nachvollziehen

MFG
Marco

rnissl · 20. November 2005

Zitat

Original von mbc
Tut mir leid, ich kann nichts machen, da mein VDR 100km weit weg steht, ich komme frühtens zum WE erst wieder dran.

Was nun ??

Hmm ... eine gute Frage ... von mir aus kann das Frame wegbleiben .. sofern das keine anderen probleme macht.

Nun, es bleibt ja schon weg, aber es scheint Probleme zu verursachen.

Zitat

Original von mbc
Also als software zum umwandeln benutze ich unter windows Projectx ich kann dir einen Link zum runterladen schicken, sofern du e damit nachvollziehen möchtest ...

Link wäre mir ganz recht, damit ich die gleiche Version verwende. Ansonsten hätte ich auch gern das ini-File mit den Einstellungen und eine Beschreibung der Bedienschritte, bis das Problem auftritt.

Zitat

Original von mbc
Ansonsten kannst du mir auch einen Patch schicken, der das Paket dann wegläßt, dann kann ich den am WE einspielen und die Aufnahme (muß sehen das ich dann eine erwische) direkt noch am WE prüfen.

Verstehe ich nicht: die c*Repacker werfen die "fehlerhaften" Daten je bereits weg.

Zitat

Original von mbc
BTW: DANKE fürs Nachvollziehen

Keine Ursache.

Bye.

mbc · 21. November 2005

Nach der ersten Email mit den Programmen nun eine zweite mit der ini und der Beschreibung.

MFG
Marco

Trekkie2 · 21. November 2005

Hallo,
muß mich leider auch mal wieder melden:

Gestern sollte mein vdr "Alle Spiele Alle Tore" von Prmiere aufnehmen. Als ich zum Ende der Aufnahme nach dem vdr geschaut habe, habe ich gesehen, daß er in einer endlosen Neustart-Schleife hing. Das log (mit log-Level 3) sah etwa so aus:

Code

Nov 20 16:40:09 Streamer vdr[2377]: Title: '[2] Alle Spiele, alle Tore' Subtitle: ''
Nov 20 16:40:09 Streamer vdr[2377]: executing '/etc/vdr-1.3.34/rec_cmd before "/video/#5B2#5D_Alle_Spiele,_alle_Tore/2005-11-20.1
6.40.95.99.rec"'
Nov 20 16:40:09 Streamer vdr[2377]: record /video/#5B2#5D_Alle_Spiele,_alle_Tore/2005-11-20.16.40.95.99.rec
Nov 20 16:40:09 Streamer vdr[2377]: creating directory /video/#5B2#5D_Alle_Spiele,_alle_Tore
Nov 20 16:40:09 Streamer vdr[2377]: creating directory /video/#5B2#5D_Alle_Spiele,_alle_Tore/2005-11-20.16.40.95.99.rec
Nov 20 16:40:09 Streamer vdr[2377]: recording to '/video/#5B2#5D_Alle_Spiele,_alle_Tore/2005-11-20.16.40.95.99.rec/001.vdr'
Nov 20 16:40:09 Streamer vdr[2377]: file writer thread started (pid=2377, tid=-1359230032)
Nov 20 16:40:09 Streamer vdr[2377]: recording thread started (pid=2377, tid=-1373131856)
Nov 20 16:40:09 Streamer vdr[2377]: receiver on device 2 thread started (pid=2377, tid=-1381520464)
Nov 20 16:40:09 Streamer vdr[2377]: TS buffer on device 2 thread started (pid=2377, tid=-1406690384)
Nov 20 16:40:13 Streamer vdr[2377]: closing SVDRP connection
Nov 20 16:40:25 Streamer vdr[2377]: ERROR: no useful data seen within 10545296 byte of video stream
Nov 20 16:40:25 Streamer vdr[2377]: initiating emergency exit
Nov 20 16:40:26 Streamer vdr[2377]: emergency exit requested - shutting down
Nov 20 16:40:26 Streamer vdr[2377]: stopping plugin: recstatus
Nov 20 16:40:26 Streamer vdr[2377]: stopping plugin: radio
Nov 20 16:40:27 Streamer vdr[2377]: ERROR: thread -1298138192 won't end (waited 1 seconds) - canceling it...
Nov 20 16:40:27 Streamer vdr[2377]: stopping plugin: femon
Nov 20 16:40:27 Streamer vdr[2377]: stopping plugin: skinelchi
Nov 20 16:40:27 Streamer vdr[2377]: stopping plugin: autosort
Nov 20 16:40:27 Streamer vdr[2377]: stopping plugin: aide
Nov 20 16:40:27 Streamer vdr[2377]: stopping plugin: undelete
Nov 20 16:40:27 Streamer vdr[2377]: stopping plugin: director
Nov 20 16:40:27 Streamer vdr[2377]: stopping plugin: premiereepg
Nov 20 16:40:27 Streamer vdr[2377]: stopping plugin: streamdev-server
Nov 20 16:40:30 Streamer vdr[2377]: ERROR: thread -1289749584 won't end (waited 3 seconds) - canceling it...
Nov 20 16:40:30 Streamer vdr[2377]: stopping plugin: xine
Nov 20 16:40:30 Streamer vdr[2377]: stopping plugin: osdteletext
Nov 20 16:40:30 Streamer vdr[2377]: stopping plugin: autotimeredit
Nov 20 16:40:30 Streamer vdr[2377]: stopping plugin: epgsearch
Nov 20 16:40:32 Streamer vdr[2377]: EPGSearch: Leaving search timer thread
Nov 20 16:40:32 Streamer vdr[2377]: EPGSearch: searchtimer thread ended (pid=2377, tid=-1264583760)
Nov 20 16:40:32 Streamer vdr[2377]: recording thread ended (pid=2377, tid=-1373131856)
Nov 20 16:40:32 Streamer vdr[2377]: TS buffer on device 2 thread ended (pid=2377, tid=-1406690384)
Nov 20 16:40:32 Streamer vdr[2377]: buffer stats: 114116 (0%) used
Nov 20 16:40:32 Streamer vdr[2377]: receiver on device 2 thread ended (pid=2377, tid=-1381520464)
Nov 20 16:40:32 Streamer vdr[2377]: file writer thread ended (pid=2377, tid=-1359230032)
Nov 20 16:40:32 Streamer vdr[2377]: cTS2PES got 0 TS errors, 1 TS continuity errors
Nov 20 16:40:32 Streamer vdr[2377]: buffer stats: 220336 (4%) used
Nov 20 16:40:32 Streamer vdr[2377]: timer 3 (1005 1640-1725 '[2] Alle Spiele, alle Tore') stop
Nov 20 16:40:32 Streamer vdr[2377]: executing '/etc/vdr-1.3.34/rec_cmd after "/video/#5B2#5D_Alle_Spiele,_alle_Tore/2005-11-20.16
.40.95.99.rec"'
Nov 20 16:40:32 Streamer vdr[2377]: transfer thread ended (pid=2377, tid=-1308894288)
Nov 20 16:40:32 Streamer vdr[2377]: cTS2PES got 37 TS errors, 16 TS continuity errors
Nov 20 16:40:32 Streamer vdr[2377]: cTS2PES got 2 TS errors, 0 TS continuity errors
Nov 20 16:40:32 Streamer vdr[2377]: buffer stats: 237444 (11%) used
Nov 20 16:40:32 Streamer vdr[2377]: Leaving cXineRemote thread
Nov 20 16:40:32 Streamer vdr[2377]: XineRemote control thread ended (pid=2377, tid=-1256195152)
Nov 20 16:40:32 Streamer vdr[2377]: saved setup to /var/lib/vdr-1.3.34/setup.conf
Nov 20 16:40:32 Streamer vdr[2377]: tuner on device 1 thread ended (pid=2377, tid=-1221301328)
Nov 20 16:40:32 Streamer vdr[2377]: receiver on device 1 thread ended (pid=2377, tid=-1317282896)
Nov 20 16:40:32 Streamer vdr[2377]: section handler thread ended (pid=2377, tid=-1231029328)
Nov 20 16:40:32 Streamer vdr[2377]: tuner on device 2 thread ended (pid=2377, tid=-1239417936)
Nov 20 16:40:32 Streamer vdr[2377]: section handler thread ended (pid=2377, tid=-1247806544)
Nov 20 16:40:32 Streamer vdr[2377]: deleting plugin: recstatus
Nov 20 16:40:32 Streamer vdr[2377]: deleting plugin: radio
Nov 20 16:40:32 Streamer vdr[2377]: deleting plugin: femon
Nov 20 16:40:32 Streamer vdr[2377]: deleting plugin: skinelchi
Nov 20 16:40:32 Streamer vdr[2377]: deleting plugin: autosort
Nov 20 16:40:32 Streamer vdr[2377]: deleting plugin: aide
Nov 20 16:40:32 Streamer vdr[2377]: deleting plugin: undelete
Nov 20 16:40:32 Streamer vdr[2377]: undelete: cPluginUndelete::~cPluginUndelete
Nov 20 16:40:32 Streamer vdr[2377]: deleting plugin: director
Nov 20 16:40:32 Streamer vdr[2377]: deleting plugin: premiereepg
Nov 20 16:40:32 Streamer vdr[2377]: deleting plugin: streamdev-server
Nov 20 16:40:32 Streamer vdr[2377]: deleting plugin: xine
Nov 20 16:40:32 Streamer vdr[2377]: deleting plugin: osdteletext
Nov 20 16:40:32 Streamer vdr[2377]: buffer stats: 0 (0%) used
Nov 20 16:40:32 Streamer vdr[2377]: deleting plugin: autotimeredit
Nov 20 16:40:32 Streamer vdr[2377]: deleting plugin: epgsearch
...

Alles anzeigen

Das Ganze wiederholte sich dann bis ich 17:26 nach Hause kam und das CAM rausgenommen habe - danach lief die Kiste und hat ohne Meckern DSF aufgenommen.

Reinhard, kannst Du (oder kann irgendjemand hier) mit diesem log was anfangen?
Ich bin im Moment mit einer Erkältung etwas außer Gefecht, aber ich kann gerne weitere Tests machen!

Dirk, Danke für den Tip mit syslog-ng und Deinem Skript gings!

gerald, kannst Du bitte kurz schreiben für WAS Du den Patch benutzt hast? Welche Symptome hattest Du, was für eine Konfiguration verwendest Du und wasw hat sich dadurch geändert?

gerald · 21. November 2005

Hi,

Gründe für den Patch:
ich öffne ein ssh session zum vdr rechner und rufe den midnight commander auf, beim schneiden von Aufnahmen gab es merkliche verzögerungen beim Aufbau der der Verzeichnisse, mit dem Patch nicht mehr.

Dann habe ich getestet ob ich auf allen 3 Karten (1FF und 2Budget) Aufnahmen starten kann, (Pro7, Premiere 1oder2 und noch ZDF) hier habe habe ich sonst auch immer ..Repacker Probleme gehabt, mit dem Patch nicht mehr.

Bei Aufnahmen auf 2 Karten (nur Budget) hatte ich noch nie ..Repacker Meldungen egal welche Sender aufgenommen wurden.

vdr-1.3.36
DVB Treiber vom 20.11.2005
kernel 2.6.14.2

rnissl · 21. November 2005

Hi,

in den Logmeldungen ist nichts besonderes zu erkennen. Komisch ist nur, dass keine c*Repacker-Meldungen auftauchen. Dass müsste eigentlich bedeuten, dass sie keinerlei Daten erhalten haben.

Bye.

Trekkie2 · 22. November 2005

Danke gerald!
Nimmst Du über NFS auf, oder wie kamst Du darauf, den Patch zu verwenden?

Stimmt wohl mit den keinen Daten erhalten, Reinhard! Die Dateien hatten wohl immer Länge 0 (s. Zeil 59) und wurden dann durch die nächste Aufnahme gelöscht (Zeile 17):

Code

Nov 20 16:44:20 Streamer vdr[6502]: loading /var/lib/vdr-1.3.34/themes/sttng-default.theme
Nov 20 16:44:20 Streamer vdr[6502]: ERROR: remote control XineRemote not ready!
Nov 20 16:44:20 Streamer vdr[6502]: radiocheck thread started (pid=6502, tid=-1297605712)
Nov 20 16:44:20 Streamer vdr[6502]: switching to channel 5
Nov 20 16:44:20 Streamer vdr[6502]: creating directory /var/lib/vdr-1.3.34/vtx/S19.2E-1-1101-28106
Nov 20 16:44:20 Streamer vdr[6502]: setting watchdog timer to 60 seconds
Nov 20 16:44:20 Streamer vdr[6502]: transfer thread started (pid=6502, tid=-1308361808)
Nov 20 16:44:20 Streamer vdr[6502]: receiver on device 1 thread started (pid=6502, tid=-1316750416)
Nov 20 16:44:20 Streamer vdr[6502]: TS buffer on device 1 thread started (pid=6502, tid=-1350308944)
Nov 20 16:44:20 Streamer vdr[6502]: timer 1 (27 1725-1905 'SC_DSF') set to event Son 20.11.2005 17:30-19:00 'Hattrick'
Nov 20 16:44:20 Streamer vdr[6502]: timer 3 (1005 1640-1725 '[2] Alle Spiele, alle Tore') set to event Son 20.11.2005 16:50-17:15 '[2] Alle Spiele, alle Tore'
Nov 20 16:44:20 Streamer vdr[6502]: switching device 2 to channel 1005
Nov 20 16:44:20 Streamer vdr[6502]: timer 3 (1005 1640-1725 '[2] Alle Spiele, alle Tore') start
Nov 20 16:44:20 Streamer vdr[6502]: Title: '[2] Alle Spiele, alle Tore' Subtitle: '(null)'
Nov 20 16:44:20 Streamer vdr[6502]: executing '/etc/vdr-1.3.34/rec_cmd before "/video/#5B2#5D_Alle_Spiele,_alle_Tore/2005-11-20.16.40.95.99.rec"'
Nov 20 16:44:20 Streamer vdr[6502]: record /video/#5B2#5D_Alle_Spiele,_alle_Tore/2005-11-20.16.40.95.99.rec
Nov 20 16:44:20 Streamer vdr[6502]: cFileName::SetOffset: removing zero-sized file /video/#5B2#5D_Alle_Spiele,_alle_Tore/2005-11-20.16.40.95.99.rec/001.vdr
Nov 20 16:44:20 Streamer vdr[6502]: recording to '/video/#5B2#5D_Alle_Spiele,_alle_Tore/2005-11-20.16.40.95.99.rec/001.vdr'
Nov 20 16:44:20 Streamer vdr[6502]: file writer thread started (pid=6502, tid=-1364210768)
Nov 20 16:44:20 Streamer vdr[6502]: recording thread started (pid=6502, tid=-1372599376)
Nov 20 16:44:20 Streamer vdr[6502]: receiver on device 2 thread started (pid=6502, tid=-1380987984)
Nov 20 16:44:20 Streamer vdr[6502]: TS buffer on device 2 thread started (pid=6502, tid=-1406157904)
Nov 20 16:44:20 Streamer vdr[6502]: cAudioRepacker(0xC0): skipped 296 bytes to sync on next audio frame
Nov 20 16:44:20 Streamer vdr[6502]: cAudioRepacker(0xC0): skipped 280 bytes to sync on next audio frame
Nov 20 16:44:20 Streamer vdr[6502]: channel 5 (Das Erste) event 16:30 'Juan Carlos' status 4
Nov 20 16:44:20 Streamer vdr[6502]: channel 6 (Bayerisches FS) event 16:30 'Schuhbecks' status 4
Nov 20 16:44:20 Streamer vdr[6502]: channel 12 (SÜDWEST Ferns. BW) event 16:15 'Deutschlands beste Weine' status 4
Nov 20 16:44:20 Streamer vdr[6502]: channel 17 (arte) event 16:05 'Mord im Haus des Herrn' status 4
Nov 20 16:44:20 Streamer vdr[6502]: channel 11 (BR-alpha) event 16:05 'Zwischen Spessart und Karwendel' status 4
Nov 20 16:44:20 Streamer vdr[6502]: channel 13 (Phoenix) event 16:45 'Aschaffenburger Gespräche' status 4
Nov 20 16:44:20 Streamer vdr[6502]: channel 7 (hr-fernsehen) event 16:30 'Reisewege zur Kunst' status 4
Nov 20 16:44:20 Streamer vdr[6502]: channel 10 (WDR Köln) event 16:25 'Gott und die Welt - Das Magazin' status 4
Nov 20 16:44:20 Streamer vdr[6502]: setting audio track to 1 (0)
Nov 20 16:44:21 Streamer vdr[6502]: stopping recording due to modification of channel 1005
Nov 20 16:44:21 Streamer vdr[6502]: recording thread ended (pid=6502, tid=-1372599376)
Nov 20 16:44:21 Streamer vdr[6502]: TS buffer on device 2 thread ended (pid=6502, tid=-1406157904)
Nov 20 16:44:21 Streamer vdr[6502]: buffer stats: 113928 (0%) used
Nov 20 16:44:21 Streamer vdr[6502]: receiver on device 2 thread ended (pid=6502, tid=-1380987984)
Nov 20 16:44:21 Streamer vdr[6502]: file writer thread ended (pid=6502, tid=-1364210768)
Nov 20 16:44:21 Streamer vdr[6502]: buffer stats: 177096 (3%) used
Nov 20 16:44:21 Streamer vdr[6502]: timer 3 (1005 1640-1725 '[2] Alle Spiele, alle Tore') stop
Nov 20 16:44:21 Streamer vdr[6502]: executing '/etc/vdr-1.3.34/rec_cmd after "/video/#5B2#5D_Alle_Spiele,_alle_Tore/2005-11-20.16.40.95.99.rec"'
Nov 20 16:44:21 Streamer vdr[6502]: switching device 2 to channel 1005
Nov 20 16:44:21 Streamer vdr[6502]: timer 3 (1005 1640-1725 '[2] Alle Spiele, alle Tore') start
Nov 20 16:44:21 Streamer vdr[6502]: Title: '[2] Alle Spiele, alle Tore' Subtitle: '(null)'
Nov 20 16:44:21 Streamer vdr[6502]: executing '/etc/vdr-1.3.34/rec_cmd before "/video/#5B2#5D_Alle_Spiele,_alle_Tore/2005-11-20.16.40.95.99.rec"'
Nov 20 16:44:21 Streamer vdr[6502]: record /video/#5B2#5D_Alle_Spiele,_alle_Tore/2005-11-20.16.40.95.99.rec
Nov 20 16:44:21 Streamer vdr[6502]: cFileName::SetOffset: removing zero-sized file /video/#5B2#5D_Alle_Spiele,_alle_Tore/2005-11-20.16.40.95.99.rec/001.vdr
Nov 20 16:44:21 Streamer vdr[6502]: recording to '/video/#5B2#5D_Alle_Spiele,_alle_Tore/2005-11-20.16.40.95.99.rec/001.vdr'
Nov 20 16:44:21 Streamer vdr[6502]: file writer thread started (pid=6502, tid=-1364210768)
Nov 20 16:44:21 Streamer vdr[6502]: recording thread started (pid=6502, tid=-1380987984)
Nov 20 16:44:21 Streamer vdr[6502]: receiver on device 2 thread started (pid=6502, tid=-1406157904)
Nov 20 16:44:21 Streamer vdr[6502]: TS buffer on device 2 thread started (pid=6502, tid=-1372599376)
Nov 20 16:44:30 Streamer vdr[6502]: max. latency time 1 seconds
Nov 20 16:44:38 Streamer vdr[6502]: EPGSearch: search timer update started
Nov 20 16:44:38 Streamer vdr[6502]: EPGSearch: search timer update finished
Nov 20 16:44:38 Streamer vdr[6502]: EPGSearch: check for timer conflicts
Nov 20 16:44:38 Streamer vdr[6502]: EPGSearch: check for timer conflicts - done
Nov 20 16:44:38 Streamer vdr[6502]: ERROR: no useful data seen within 10542476 byte of video stream
Nov 20 16:44:38 Streamer vdr[6502]: initiating emergency exit

Alles anzeigen

Sieht so aus, als wäre was mit der Kanalnummer schief gelaufen (Zeile 34) und vdr hätte versucht, statt 2-Liga-Zusammenfassung was aufzunehmen, was die Karte (bzw. das CAM) nicht entschlüsseln konnte. Ich werd nochmal nen Versuch mit einem Film machen.

Ich hab mal einen Schnipsel angefügt, der Repacker-Meldungen enthält, davon gabs in den 42 Minuten 22 - ich weiß nicht, ob die was damit zu tun hatten, oder vom Umschalten auf der anderen Karte kamen. Falls die Log-Files sowieso uninteressant sind, kann ich sie auch wieder löschen, ich dachte nur: Vielleicht kann ja jemand was daraus ablesen...

Achso, uich verwende noch 1.3.34 - soweit ich das gesehen habe, hat sich nur die Unterstützung für mehrere CAMs geändert - oder könnte evtl ein Update helfen?

gerald · 22. November 2005

Hi

Trekkie2,
nehme direkt auf Platte auf.
genommen habe ich den Patch aus diesem Grund:

Zitat

[vdr] [PATCH] UnbufferedFile improvements v2
-> Autor: Artur Skawina
well, vdr w/ the recent cUnbufferedFile changes was flushing the data
buffers in huge burst; this was even worse than slowly filling up the
caches -- the large (IIRC ~10M) bursts caused latency problems (apps
visibly freezing etc).

Alles anzeigen

rnissl
habe mal 7 Aufnahme Gleichzeitig (Premiere1, Sat1 Pro7 Tele5, ZDF 3SAT ZDF Dokukanal) gemacht, und einen Film geschnitten, und eine Aufnahme angeschaut (mit DD Sound) keine Repacker Meldungen im Log, dann habe ich Aufnahme anschauen beendet, Livekanal war Premiere1 mit DD5.1 keine Meldungen, dann habe ich durch die Kanäle gezappt Bild angezeigt ein paar Sekunden geschaut und weiter gezappt (soweit dies möglich war) hier kamen dann folgende Meldungen (bei Wechsel auf einen Sender mit DD):

Code

[2005/11/22 09:06:55] vdr vdr[1500]: switching to channel 71
[2005/11/22 09:06:55] vdr vdr[1500]: transfer thread ended (pid=1500, tid=-1325442128)
[2005/11/22 09:06:55] vdr vdr[1500]: buffer stats: 34592 (1%) used
[2005/11/22 09:06:55] vdr vdr[1500]: transfer thread started (pid=1500, tid=-1325442128)
[2005/11/22 09:06:55] vdr vdr[1500]: TS continuity error (6)
[2005/11/22 09:06:55] vdr vdr[1500]: TS continuity error (5)
[2005/11/22 09:06:55] vdr vdr[1500]: TS continuity error (2)
[2005/11/22 09:06:55] vdr vdr[1500]: cDolbyRepacker: skipped 1608 bytes to sync on next AC3 frame
[2005/11/22 09:06:55] vdr vdr[1500]: cAudioRepacker(0xC1): skipped 392 bytes to sync on next audio frame
[2005/11/22 09:06:55] vdr vdr[1500]: cAudioRepacker(0xC1): skipped 14 bytes to sync on next audio frame
[2005/11/22 09:06:55] vdr vdr[1500]: cDolbyRepacker: skipped 14 bytes to sync on next AC3 frame
[2005/11/22 09:06:55] vdr vdr[1500]: cAudioRepacker(0xC1): skipped 170 bytes to sync on next audio frame
[2005/11/22 09:06:55] vdr vdr[1500]: cDolbyRepacker: skipped 170 bytes to sync on next AC3 frame
[2005/11/22 09:06:56] vdr vdr[1500]: setting audio track to 33 (0)

Alles anzeigen

danach lief alles wieder hervoragend.
Den Remux Patch hatte ich auch eingespielt, es wurden jedoch keine TS_.... Datei(en) erstellt.

Normalerweise mache ich nicht soviel Aufnahme und schneiden gleichzeitig. Bei 1-2 Aufnahmen gleichzeitg habe ich noch nie Repacker Meldungen gehabt.

gruss
gerald

rnissl · 24. November 2005

Hi,

diese Meldungen sind beim Zappen (bzw. beim Kanalwechsel) normal, da sich das Signal erst noch stabilisieren muss (vgl. auf Tuner-Lock warten in früheren VDR-Versionen). Es wird zwar versucht, diese Meldungen zu unterdrücken, aber mitunter wird die Synchronisationsphase zu früh beendet. Wollte man das noch besser machen, dann müsste man auch noch die Checksummen der Pakete berechnen und selbst dann wäre man von dem Problem beim Umschalten noch immer nicht gefeit.

Im Betrieb ist das aber nicht weiter schlimm, da eine Aufnahme ja typischerweise ein paar Minuten früher startet und man diese Phase dann wegschneidet. Im Transfer-Mode sind diese "Knackser" beim Umschalten so gut wie nicht zu vernehmen.

Das Problem von "mbc" ist vielmehr, dass im Film solche Störungen auftreten, weil Pro7 Austria bei den Wechseln von 2.0 => 5.1 bzw. 5.1 => 2.0 ein TS-Paket "vergisst". Ich werde am Wochenende nochmals analysieren, ob sich cDolbyRepacker hier richtig verhält.

Ich habe die Problematik auch mal an Pro7 Austria weitergeleitet, denke aber nicht, das es was genützt hat.

Bye.

rnissl · 27. November 2005

Hi,

ich habe den ganzen Nachmittag damit verbracht, Hexdumps des TS-Streams mit dem PES-Ergebnis von VDR zu vergleichen.

Letztendlich kam dabei folgendes raus, was die beobachteten cDolbyRepacker-Meldungen auf ein verlorenes TS-Paket auf ein Minimum reduzieren sollte. Auch ProjectX müsste nun bei einer damit erzeugten Aufnahme wesentlich weniger Fehler melden (typischerweise CRC2-Fehler, hängt aber davon ab, wo das TS-Paket verloren ging).

Diff

--- ../vdr-1.3.36-orig/remux.c  2005-09-11 15:26:50.000000000 +0200
+++ remux.c     2005-11-27 17:45:20.000000000 +0100
@@ -1650,7 +1650,7 @@ void cTS2PES::ts_to_pes(const uint8_t *B
      }


   if (Buf[1] & PAY_START) {
-     if (plength == MMAX_PLENGTH - 6 && found > 6) {
+     if (found > 6) {
         plength = found - 6;
         found = 0;
         send_ipack();

Alles anzeigen

Bye.

Trekkie2 · 28. November 2005

Hallo,

und Vielen Dank für die tolle Arbeit!

Kann ich den Patch auch bei meinem 1.3.34 anwenden, oder läuft der nur mit 1.3.36?
Wie siehts bei 1.3.37 aus? Ich kompiliere evtl. diese Woche alles nochmal neu und überlege daher auf die neueste Version umzustiegen...

Hm, dann noch eine peinliche Frage, aber das ist ja ein diff - lasse ich das mit patch auf die Original-Version los? Oder womit? Sorry für die Unwissenheit

rnissl · 28. November 2005

Hi,

der Patch dürfte auch mit anderen Versionen funktionieren. Evtl. weicht er von der Zeilennummer her ab, aber das ist nicht so schlimm.

Code

cd /path/to/VDR
patch -d. -p0 --dry-run -f /path/to/patch.txt

Wenn's passt, dann --dry-run wegnehmen.

Bye.

Trekkie2 · 29. November 2005

Danke für die Geduld!

Na dann werd ich mich mal auf ins Büro machen - damit heute Abend bischen Zeit zum Kompilieren bleibt

[edit]
Kurze Rückmeldung, Patchen ging mit folgendem Befehl auf vdr-1.3.37:
patch -d. -p0 -f -i ../Repacker-thread.patch
d.h. das -i hat gefehlt.

Zum Testen werde ich dann (hoffentlich) auch bald Zeit finden...

massenhaft Einträge Audio-/Videorepacker in syslog

Jetzt mitmachen!

Teilen