In article <201103191519.p2JFJKZw037553@xxxxxxxxxxxxxxxxxxxx> you write: >In article <4D849B3A.6060308@xxxxxxx> you write: >>On 17.03.2011 22:36, Juergen Lock wrote: >>> In article <4D7CAEA2.9050109@xxxxxxx> 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? Found the problem: The FreeBSD patches disable USE_FADVISE in tools.c, and there was an #else clause missing when its not defined: --- tools.c.orig +++ tools.c @@ -1669,6 +1669,9 @@ ssize_t cUnbufferedFile::Read(void *Data } } lastpos = curpos; +#else + if (bytesRead > 0) + curpos += bytesRead; #endif return 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 affected. Thanx, :) Juergen _______________________________________________ vdr mailing list vdr@xxxxxxxxxxx http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
