| Message ID | 201103191740.p2JHe1CX042314@triton8.kn-bremen.de |
|---|---|
| State | New |
| Headers |
Received: from mail.tu-berlin.de ([130.149.7.33]) by www.linuxtv.org with esmtp (Exim 4.69) (envelope-from <vdr-l@jelal.kn-bremen.de>) id 1Q1099-00066I-MQ for vdr@linuxtv.org; Sat, 19 Mar 2011 18:41:04 +0100 X-tubIT-Incoming-IP: 78.46.108.116 Received: from gelbbaer.kn-bremen.de ([78.46.108.116] helo=smtp.kn-bremen.de) by mail.tu-berlin.de (exim-4.74/mailfrontend-d) with esmtp for <vdr@linuxtv.org> id 1Q1099-0003On-0T; Sat, 19 Mar 2011 18:41:03 +0100 Received: by smtp.kn-bremen.de (Postfix, from userid 10) id E795F1E0024E; Sat, 19 Mar 2011 18:41:02 +0100 (CET) Received: from triton8.kn-bremen.de (noident@localhost [127.0.0.1]) by triton8.kn-bremen.de (8.14.4/8.14.3) with ESMTP id p2JHe2gl042315; Sat, 19 Mar 2011 18:40:02 +0100 (CET) (envelope-from vdr-l@triton8.kn-bremen.de) Received: (from vdr-l@localhost) by triton8.kn-bremen.de (8.14.4/8.14.3/Submit) id p2JHe1CX042314; Sat, 19 Mar 2011 18:40:01 +0100 (CET) (envelope-from vdr-l) Date: Sat, 19 Mar 2011 18:40:01 +0100 (CET) From: Juergen Lock <vdr-l@jelal.kn-bremen.de> Message-Id: <201103191740.p2JHe1CX042314@triton8.kn-bremen.de> To: vdr-l@jelal.kn-bremen.de X-Newsgroups: local.list.vdr In-Reply-To: <201103191519.p2JFJKZw037553@triton8.kn-bremen.de> References: <201103172136.p2HLa1HR002505@triton8.kn-bremen.de> Organization: X-PMX-Version: 5.5.5.374460, Antispam-Engine: 2.7.1.369594, Antispam-Data: 2011.3.19.172417 X-PMX-Spam: Gauge=IIIIIIII, Probability=8%, Report=' BODY_SIZE_3000_3999 0, BODY_SIZE_5000_LESS 0, BODY_SIZE_7000_LESS 0, __BOUNCE_CHALLENGE_SUBJ 0, __BOUNCE_NDR_SUBJ_EXEMPT 0, __CP_URI_IN_BODY 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __SANE_MSGID 0, __TO_MALFORMED_2 0, __TO_NO_NAME 0, __URI_NO_WWW 0' X-LSpam-Score: -3.4 (---) X-LSpam-Report: No, score=-3.4 required=5.0 tests=AWL=0.201, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1 autolearn=ham Cc: VDR Mailing List <vdr@linuxtv.org> Subject: Re: [vdr] [ANNOUNCE] VDR developer version 1.7.17 X-BeenThere: vdr@linuxtv.org X-Mailman-Version: 2.1.11 Precedence: list Reply-To: VDR Mailing List <vdr@linuxtv.org> List-Id: VDR Mailing List <vdr.linuxtv.org> List-Unsubscribe: <http://www.linuxtv.org/cgi-bin/mailman/options/vdr>, <mailto:vdr-request@linuxtv.org?subject=unsubscribe> List-Archive: <http://www.linuxtv.org/pipermail/vdr> List-Post: <mailto:vdr@linuxtv.org> List-Help: <mailto:vdr-request@linuxtv.org?subject=help> List-Subscribe: <http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr>, <mailto:vdr-request@linuxtv.org?subject=subscribe> X-List-Received-Date: Sat, 19 Mar 2011 17:41:04 -0000 Status: O X-Status: X-Keywords: X-UID: 24531 |
Commit Message
Juergen Lock
March 19, 2011, 5:40 p.m. UTC
In article <201103191519.p2JFJKZw037553@triton8.kn-bremen.de> you write: >In article <4D849B3A.6060308@tvdr.de> you write: >>On 17.03.2011 22:36, Juergen Lock wrote: >>> In article <4D7CAEA2.9050109@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? Found the problem: The FreeBSD patches disable USE_FADVISE in tools.c, and there was an #else clause missing when its not defined: 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
Comments
Am 19.03.2011 18:40, schrieb Juergen Lock: > 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. This is probably an old bug: For me, VDR has always been hanging at the end of a recording, if that recording is shorter than one minute. Takes 10 or 20 seconds, then brings you back to live view again. Its not that annoying, as recordings are usually longer, so I've never been going on bug hunt for this. Cheers, Udo
In article <4D84EE1D.8090503@gmx.de> you write: >Am 19.03.2011 18:40, schrieb Juergen Lock: >> 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. > >This is probably an old bug: For me, VDR has always been hanging at the >end of a recording, if that recording is shorter than one minute. Takes >10 or 20 seconds, then brings you back to live view again. Its not that >annoying, as recordings are usually longer, so I've never been going on >bug hunt for this. Ah yeah, that could well be it. I also found that sometimes playback of a short recording that was played before(?) doesn't start until you hit green... (black screen or `no signal', don't remember.) Anyway, you are right, short recordings are kinda rare in real life. :) Thanx, Juergen
--- 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; }