Hi,
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.
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.
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.