Changed 7 years ago by David Moore <dmoo1790@…>

I tried analysing the log file and found some weird things with timecodes. See attached file log_analysis.txt. This file has extracts from filtering with
egrep 'audio timecode|video timecode|DoPlayerSeek?|behind|error' mythfrontend.20120604155806.2992.log

It seems to me there is a genuine bug rather than a config problem on my system. Three reasons: (1) the odd sequence of video/audio timecodes in the log, (2) no problem before upgrading to 0.25 and (3) others in NZ have reported the same behaviour when trying to seek back to the start of a recording.

So the log below definitely shows a timestamp issue right after the audio decoding errors. The audio timestamp jumps way back in time after the decoding error. These errors and timestamps are provided by the ffmpeg demuxer. So it appears that the regression is probably due to the ffmpeg sync done for 0.25. I'm not sure how this should be handled because it's really an ffmpeg bug. The first step is to create a small sample that triggers the issue and then see if the ffmpeg devs might be interested in looking at it.

Setting the audio buffers to 256 does not solve the problem on my system (they were already set to 256). Even setting them to the maximum of 32768 didn't make any difference.
Disabling the setting 'Separate video modes for GUI and TV playback' does seem to fix it but I think there are several variables involved which makes tracking down the cause difficult.
See ​http://www.gossamer-threads.com/lists/mythtv/users/522376#522376