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
>>>
>>> ftp://ftp.tvdr.de/vdr/Developer/vdr-1.7.17.tar.bz2
>>>
>>> A 'diff' against the previous version is available at
>>>
>>> ftp://ftp.tvdr.de/vdr/Developer/vdr-1.7.16-1.7.17.diff
>>>
>>>
>>>
>>> WARNING:
>>> ========
>>>
>>> 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:
>>
>> http://people.freebsd.org/~nox/dvb/vdr-20110317a.shar
>>
>> (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
>fine.
>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
>fine.
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
amd64/x86_64 issue?
Thanx,
Juergen
_______________________________________________
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
