[vdr] [INVITATION] help debugging cAudioRepacker

[Reinhard Nissl]

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 at gmx.de
-------------- 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