[vdr] Problems playing ongoing recordings?

Artur Skawina art_k at o2.pl
Tue Apr 1 01:05:37 CEST 2008


Alexw wrote:
>>> Sometimes the player stops in the middle of a recording due to a zero size request. Here is the log:
>>>
>>> vdr: [3836] dvbplayer thread started (pid=3643, tid=3836)
>>> vdr: [3836] resuming replay at index 1950 (0:01:18.01)
>>> vdr: [3837] non blocking file reader thread started (pid=3643, tid=3837)
>>> vdr: [3836] SetBrokenLink: no GOP header found in video packet
>>> vdr: [3836] setting audio track to 1 (0)
>>> vdr: [3836] playing '/var/vdr/video/SERVER/recording/2008-03-28.18.58.50.50.rec/001.vdr'
>>>
>>> <<<unexpect stop of replay>>>
>>>
>>> vdr: [3837] non blocking file reader thread ended (pid=3643, tid=3837)
>>> vdr: [3836] dvbplayer thread ended (pid=3643, tid=3836)

>>> vdr: [5618] WANT: fd: 25 1068536495 .. 1068722913 SIZE: 186418
>>> vdr: [5618] READ: fd: 25 1068536495 .. 1068666704 SIZE: 130209 jump:         0 ra: 12582912
>>> vdr: [5618] WANT: fd: 25 1068666704 .. 1068983331 SIZE: 316627
>>> vdr: [5618] READ: fd: 25 1068666704 .. 1068680058 SIZE:  13354 jump:         0 ra: 12582912
>>> vdr: [5618] READ: fd: 25 1068680058 .. 1068690344 SIZE:  10286 jump:         0 ra: 12582912
>>> vdr: [5618] READ: fd: 25 1068690344 .. 1068721839 SIZE:  31495 jump:         0 ra: 12582912
>>> vdr: [5618] READ: fd: 25 1068721839 .. 1069246127 SIZE: 524288 jump:         0 ra: 12582912
>>> vdr: [5618] WANT: fd: 25 1069246127 .. 1070294703 SIZE: 1048576
>>> vdr: [5618] READ: fd: 25 1069246127 .. 1069246127 SIZE:      0 jump:         0 ra: 12582912
>>> vdr: [5618] non blocking file reader thread ended (pid=5563, tid=5618)
>>> vdr: [5617] dvbplayer thread ended (pid=5563, tid=5617)
>>>     
>> Weird, cUnbufferedFile::Read(Size=0). I'll try to reproduce this.
>>   
> Sometimes it take a long time to occur, sometimes not.

Did this start after applying my patch, or did it happen in the past too?
Does it always happen at a certain position? Specific stream or bitrate?
I don't recall ever having a similar problem, the number 524288 looks a bit
suspicious...


>>> As you can see the requested size is increasing until it reaches the max buf. This is also a period with freezes in the video (late delivery).
>>>     
>> Do these problems (0-sized reads) occur only near the end of a program being recorded?
>>   
> No, you can experience a stop in the middle of a recording.
> 
>> Also, I see from the above that the readahead code needs to be more aggressive:
>>
>>> vdr: [5627] WANT: fd: 25 1188531493 .. 1188861741 SIZE: 330248
>> [... small reads...]
>>> vdr: [5627] READ: fd: 25 1188616808 .. 1189141096 SIZE: 524288 jump:         0 ra: 12582912
>>>     
>> the readahead window does not cover the area which is being read later -- this certainly
>> is likely to stall playback. I'll fix this (i did not expect such a large difference in
>> read request sizes.)

The attached patch makes the readahead window grow much faster, this will cause more
I/O at the start of playback, but should handle cases like the one above better.
If it works correctly all the ranges mentioned in "READ:" lines should be inside
the preceding "WANT:" range and the playback shouldn't stall.
Here the readahead window grows to ~5Mbytes just after starting playback,
i still need to check that this is not too fast, doesn't saturate the disk and/or
link and cause delays when jumping etc. Tested by playing a few files from an
NFS mount, didn't notice any problems so far.

An incremental patch would look like this (the attached one (vs 1.4.7) already includes it):

diff --git a/tools.c b/tools.c
index a14f799..e22614f 100644
--- a/tools.c
+++ b/tools.c
@@ -1186,13 +1186,13 @@ ssize_t cUnbufferedFile::Read(void *Data, size_t Size)
            // Trigger the readahead IO, but only if we've used at least some of the previously
            // requested area. This avoids calling fadvise() after every read() call.
            size_t cachedsize = cachedend - curpos;
-           size_t ra = cachedsize + Size*2 + (size_t)jumped*1;
+           size_t ra = cachedsize + Size*8 + (size_t)jumped*1;
            if (cutting)
               ra += KILOBYTE(64);
            ra = min(readahead, ra);
            // Start I/O if we A) used some of the data or B) can read sufficiently large new chunk.
            // (A) is important when starting w/ a small readahead.
-           if (cachedsize < (ra-ra/4) || cachedsize+KILOBYTE(256) <= ra)
+           if (cachedsize < (ra-ra/16) || cachedsize+KILOBYTE(256) <= ra)
               FadviseRead(curpos, ra);
            }
         else if (jumped >= 0) {    // either large forward jump, or FF (jumps by ~4xSize)

artur
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: patch.txt
Url: http://www.linuxtv.org/pipermail/vdr/attachments/20080401/b6ab61df/attachment-0001.txt 


More information about the vdr mailing list