[vdr] [ANNOUNCE] VDR developer version 1.7.17
Juergen Lock
vdr-l at jelal.kn-bremen.de
Thu Mar 17 22:36:01 CET 2011
In article <4D7CAEA2.9050109 at 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.)
..and before I forget, Thanx for vdr! :)
Juergen
More information about the vdr
mailing list