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.
Meanwhile I've got a second report. Dumping it like that
od -Ax -w188 -v -t x1 ts_22252_2342936_0xC0_005_36676_100.log | less -S
shows a discontinuity at the end of the file
v 004218 47 00 88 14 d0 a3 e1 59 3a 12 74 0e 49 ca 80 c2 5d 57 58 50 74 ed 4d 2c 5a f5 46 b5 6d a3 16 b5 4a 52 88 46 b5 ad 84 08 4a da 91 9d a5 57 cd cf 9b 9b 2e e6 ed 67 1c 87 27 0042d4 47 00 88 18 b6 b3 63 c3 24 32 22 48 92 d8 b6 31 58 a4 24 20 13 11 eb 38 ae aa 6b 2a e7 3d ef 79 e0 c4 a5 2a 75 18 99 eb 10 e2 c6 d9 59 96 9a 79 a7 96 b5 fe 47 91 e3 51 a9 ^
In such a case, cAudioRepacker can do nothing else than synchronize to the next audio frame header and drop any data up to synchronization. This is the same as what the decoder did before VDR-1.3.31, except reporting that it has happened.
Missing TS packets are a matter of digital broadcasting and cannot be avoided completely, but optimizing the reception system my minimize them.
If you still find issues with cAudioRepacker that are not related to missing TS packets (use the above command and check the tail), feel free to report them further. Many thanks to all of you, who supported me by sending reports or by just running the modified cAudioRepacker with no unusual behaviour ;-)
BTW: attached you'll find the file remux.c of the upcoming VDR-1.3.32, which is almost identical to the version contained in last patch, but with all debug messages removed again.
Bye.