Bug #1495
Incorrect timecodes in .mkv files (approximately 30s)
0%
Description
I'm reporting this on the current release version, although I first noticed this in 2.99.37.1332f9f: http://forum.xbmc.org/showthread.php?tid=135531
In effect, everything I record in mkv appears to have a 30s time offset... the file starts at 00:00:30 (or thereabouts, it can be 28s-30s), and then goes from there.
VLC pre-2.0.2 kept this 30s offset all the way through, so you could click back and forth and it would be consistently 30s out - so I never noticed it. However, 2.0.2 onwards semi-corrects it, so it starts at 00:00:30 but corrects itself when you click forward (e.g. if you're looking for adverts or the start of a programme). I presume it's due to how the application works out time position from frame rate and frame number, although I've checked with VLC and it knows that it's on the first frame as the file starts (i.e. frames decoded = 0 at the start despite the timecode), even if it doesn't know where it is. VLC tested on XP and Win7.
XBMC shows it as well, certainly initially - so, start playback and hit pause immediately and it will show 00:29. mkvmerge sees it as well, so tell it to cut at, say, 5 minutes in and it'll slice after 04:30 or thereabouts. Interestingly, the error then only exists in the first file created by mkvmerge - any subsequent cuts are okay and start at 00:00 as you'd expect. XBMC tested on Openelec and Win7, mkvmerge on XP and Win7.
The Linux port of comskip is also picking up the issue, which kind of defeats the point of automatically looking for anything, if you then promptly end up in the wrong place. The developer has even added a mkv_time_offset flag to try to manually correct by 30 seconds.
History
Updated by 
Updated by
Updated by Adam Sutton almost 12 years ago
Updated by John just so you are aware as you'll probably be the one to fix this. My hunch is it relates to the 30s offset applied to the recording timer. I think Andreas did this to ensure we always wake up just before the event even if no pre buffer exists. My guess is this is what's causing the timebase issues. I've not had a chance to look though.
Adam
Updated by Adam Sutton almost 12 years ago
Had a quick look, but I'm on my phone, looks like the recording system creates the muxer when the timer fires (30s early) mkv muxer probably uses this time as time base start.
However no data is passed until the true start, 30s later .
Adam
Updated by Adam Sutton almost 12 years ago
I have a HACK to attempt to overcome this, but since I couldn't reproduce the issue on my own setup. Both VLC and XBMC did not show any time offset in MKV recording.
If you want to try it take a look at branch bug/1495 (commit:c759cfe).
Adam
Updated by Prof Yaffle almost 12 years ago
Thanks, Adam - I'll check it out when I get a chance (this is the normal master branch, from what I can see, so any later checkout will include it - but not timeshift, which is a parallel branch, yes?).
I can supply you with samples easily enough if you'd like, but probably not worthwhile until we see if your "hack" has the desired effect.
Updated by John Törnblom almost 12 years ago
- Status changed from Accepted to Fixed
This should be fixed in master now