[vdr] [ANNOUNCE] VDR developer version 1.7.17
vdr-l at jelal.kn-bremen.de
Sat Mar 19 18:40:01 CET 2011
In article <201103191519.p2JFJKZw037553 at triton8.kn-bremen.de> you write:
>In article <4D849B3A.6060308 at tvdr.de> you write:
>>On 17.03.2011 22:36, Juergen Lock wrote:
>>> In article <4D7CAEA2.9050109 at 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 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
>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
Found the problem: The FreeBSD patches disable USE_FADVISE in tools.c,
and there was an #else clause missing when its not defined:
@@ -1669,6 +1669,9 @@ ssize_t cUnbufferedFile::Read(void *Data
lastpos = curpos;
+ if (bytesRead > 0)
+ curpos += bytesRead;
There is one remaining bug tho: After playback of a short recording
(sd in this case, 20s or so), vdr seems to kind of hang and I have
to kill it... Can you reproduce that? Longer recordings are not
More information about the vdr