In article <4d849b3a.6060...@tvdr.de> you write:
>On 17.03.2011 22:36, Juergen Lock wrote:
>> In article <4d7caea2.9050...@tvdr.de> you write:
>>> VDR developer version 1.7.17 is now available at
>>> A 'diff' against the previous version is available at
>>> This is a *developer* version. Even though *I* use it in my productive
>>> environment. I strongly recommend that you only use it under controlled
>>> conditions and for testing and debugging.
>>> - Fixed detecting frames on channels that broadcast with 50 or 60 fps.
>>> This avoids artifacts during fast forward/rewind when replaying recordings
>>> from such
>>> channels. To fix the index of existing recordings from such channels, just
>>> delete the
>>> 'index' file of the recording and VDR will generate a new one the next
>>> time you play it.
>>> You should also change the line "F 25" to "F 50" in the 'info' file of
>>> that recording.
>> I wonder if I'm chasing a ghost there... am I really the only one
>> seeing this? I can't get this index rebuilding to work regardless
>> if I try it with old or new recordings, if I mv away the original
>> index file that was created with a recording I always get totally
>> different index files rebuilt (checked with hexdump/cmp -l) that
>> cause playbacks (via xineliboutput) to look quite corrupted immediately
>> and make vdr-sxfe hang at eof too.
>> This is vdr 1.7.17, xineliboutput is a 1.0.90s20110308.2305 checkout,
>> FreeBSD 8.2/amd64, using these ports:
>> (originally noticed with recordings from arte hd on 19.2E, but also
>> reproduced with new short sd recordings, even from dvb-t.)
>I just made a recording from "arte HD" with VDR 1.7.17 and everything worked
>It played correctly (on a TT-S2 6400 prototype), the current and total
>times displayed by the progress display were correct and I was able to
>place and move an editing mark with the picture getting updated just
So it also works when you stop vdr, mv the recording's index
file away and then let vdr regenerate it? Could this be an
vdr mailing list