Hi, Reinhard Nissl wrote: > as some people seem to get messages like the following several seconds > (> 60) after switching to a certain channel (or after a recording has > switched a device) > > Sep 2 11:12:49 video vdr[14940]: cAudioRepacker: skipped 911 bytes to > sync on next audio frame > Sep 2 11:12:49 video vdr[14940]: cAudioRepacker: skipped 785 bytes to > sync on next audio frame > Sep 2 11:12:50 video vdr[14940]: cAudioRepacker: skipped 221 bytes to > sync on next audio frame > > it may be likely that there is a bug in cAudioRepacker. Therefore I've > added some debug output to possibly identify a bug. > > The attached patch is against vanilla VDR-1.3.31 and contains all my > previously released patches since VDR-1.3.31 plus the new debug messages. I've updated the patch. It stores now up to 100 TS packets, that led to a wrong audio header respectively to synchronisation. The files are written to /video, as I assume some space at this location ;-) If you want to use a different location, just have a look into cTSLogger::Dump(). While adding the dumper to cAudioRepacker, I've discovered a little bug which could lead to recognizing an audio frame header too early: after a frame is done, at least 4 bytes (which are counted by variable skippedBytes) need to be read before scanner can be tested for a valid audio header. > As I experience such messages only rarely it takes quite some time to > wait for the next log message and there are only about 30 hours left > before VDR-1.3.32 is likely to be released. > > So I really invite you to help debugging this issue. Please send any > such messages to the list or maybe to me privately. But be aware: I'm > not interested in the messages that happen immediately after tuning the > device! Especially VDR-1.3.31 reports sometimes a lot of them, as > waiting for the tuner getting locked was removed. There is nothing > special about these messages. > > To make it clear once more: just send such messages that happen for > example 60 seconds after the last tuning activity (log message: > "switching to channel X" or "switching device X to channel Y"). > > The sent log messages should also include the lines which allow to > identy the thread that drives cAudioRepacker. Typically these log > messages (like "transfer thread started" or "recording thread started") > follow the switching messages. Please include the dumped TS logfiles (/video/ts_*.log) too. > NPTL users: please turn off NPTL for this test (by defining an > environment variable: export LD_ASSUME_KERNEL=2.4.1) as it is not > possible to indentify the reporting thread otherwise. Bye. -- Dipl.-Inform. (FH) Reinhard Nissl mailto:rnissl@xxxxxx -------------- next part -------------- A non-text attachment was scrubbed... Name: vdr-1.3.31-remux_debugging2.patch Type: text/x-patch Size: 13190 bytes Desc: not available Url : http://www.linuxtv.org/pipermail/vdr/attachments/20050903/f75cabe1/vdr-1.3.31-remux_debugging2-0001.bin
