Tvheadend

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.

http://forum.xbmc.org/showthread.php?tid=150084