alexw wrote: > On Friday 28 March 2008 14:52:38 alexw wrote: >> On Thursday 27 March 2008 18:22:35 Artur Skawina wrote: >>> VDR User wrote: >>>> On Thu, Mar 27, 2008 at 9:19 AM, Artur Skawina <[EMAIL PROTECTED]> wrote: >>>>> I have a similar setup, just with 100M ethernet instead of wifi and >>>>> NFS instead of samba. wifi could be a problem, but if you're able to >>>>> watch the same channel live you should also be able to view a >>>>> recording. >>>> Takes a lot more bandwidth to record & playback then just to record so >>>> the fact that live tv is fine doesn't amount to much I don't think. >>> I was referring to playing a finished recording and playing a file that >>> is currently being extended by the "server" vdr -- alexw said that >>> doesn't work well for him. It should, unless the disk and/or fs can't >>> handle the two data streams concurrently, while keeping the latency low >>> enough. I'm assuming the vdr server in powerful enough to handle the >>> load, yes.
>> My setup is a little bit more complicated as it is using a share drive on >> both machine. The two local disks are only CF. The file server is compose >> of 4x SATA II 500GB in raid 5 (total ~1.5 TB available) piloted by a >> promise controller and a fully idle 3 GHz P4 CPU. The throughput or the >> sustained write/read access is not a bottleneck. Here is a quick ASCII art >> drawing: >> >> >> /-- 100M --[AP]~ WIFI 54Mb ~[vdr client/FF]-[TV] >> >> [switch]--- 100M ---[CIFS/fileserver] >> >> \-- 100M -- [vdr server/B2C2]-DVB-S+DVB-T >> >> >> This evening I will test the provided patch. > Using the patch provided by Artur, playing a finished/ongoing recording is > smoother than before. Thank you for testing (and for enabling the extra logging). Does "smoother than before" mean that there is some improvement, but the playback still isn't perfect? The fact that the recorder hangs on to the last 4M of the stream and the data is appended in large chunks can cause problems when timeshifting by just a few seconds -- the player could try to access the not yet written data. This should only happen at the very end of an ongoing recording, within 4M of EOF (depending on the bitrate usually a couple of seconds after the live program arrived). > 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. > ----------------------------------------------------- > > vdr: [5627] READ: fd: 25 1188203807 .. 1188214024 SIZE: 10217 jump: > 0 ra: 12582912 > vdr: [5627] READ: fd: 25 1188214024 .. 1188226152 SIZE: 12128 jump: > 0 ra: 12582912 > vdr: [5627] READ: fd: 25 1188226152 .. 1188267411 SIZE: 41259 jump: > 0 ra: 12582912 > vdr: [5627] WANT: fd: 25 1188267411 .. 1188503927 SIZE: 236516 > vdr: [5627] READ: fd: 25 1188267411 .. 1188278781 SIZE: 11370 jump: > 0 ra: 12582912 > vdr: [5627] READ: fd: 25 1188278781 .. 1188292400 SIZE: 13619 jump: > 0 ra: 12582912 > vdr: [5627] READ: fd: 25 1188292400 .. 1188335024 SIZE: 42624 jump: > 0 ra: 12582912 > vdr: [5627] WANT: fd: 25 1188335024 .. 1188589175 SIZE: 254151 > vdr: [5627] READ: fd: 25 1188335024 .. 1188344461 SIZE: 9437 jump: > 0 ra: 12582912 > vdr: [5627] READ: fd: 25 1188344461 .. 1188365793 SIZE: 21332 jump: > 0 ra: 12582912 > vdr: [5627] READ: fd: 25 1188365793 .. 1188459990 SIZE: 94197 jump: > 0 ra: 12582912 > vdr: [5627] WANT: fd: 25 1188459990 .. 1188777569 SIZE: 317579 > vdr: [5627] READ: fd: 25 1188459990 .. 1188473626 SIZE: 13636 jump: > 0 ra: 12582912 > vdr: [5627] READ: fd: 25 1188473626 .. 1188489407 SIZE: 15781 jump: > 0 ra: 12582912 > vdr: [5627] READ: fd: 25 1188489407 .. 1188531493 SIZE: 42086 jump: > 0 ra: 12582912 > vdr: [5627] WANT: fd: 25 1188531493 .. 1188861741 SIZE: 330248 > vdr: [5627] READ: fd: 25 1188531493 .. 1188543845 SIZE: 12352 jump: > 0 ra: 12582912 > vdr: [5627] READ: fd: 25 1188543845 .. 1188554106 SIZE: 10261 jump: > 0 ra: 12582912 > vdr: [5627] READ: fd: 25 1188554106 .. 1188594505 SIZE: 40399 jump: > 0 ra: 12582912 > vdr: [5627] READ: fd: 25 1188594505 .. 1188605731 SIZE: 11226 jump: > 0 ra: 12582912 > vdr: [5627] READ: fd: 25 1188605731 .. 1188616808 SIZE: 11077 jump: > 0 ra: 12582912 > vdr: [5627] READ: fd: 25 1188616808 .. 1189141096 SIZE: 524288 jump: > 0 ra: 12582912 > vdr: [5627] WANT: fd: 25 1189141096 .. 1190189672 SIZE: 1048576 > vdr: [5627] READ: fd: 25 1189141096 .. 1189141096 SIZE: 0 jump: > 0 ra: 12582912 > vdr: [5627] non blocking file reader thread ended (pid=5563, tid=5627) > > 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? 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.) Thanks, artur _______________________________________________ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
