Artur Skawina a écrit : > 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 <art_k@xxxxx> 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). > > The playback is really improved, especially when doing timeshift recording. I will try to identify the reason why I am having (sporadic) freezes. >> 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. >> ----------------------------------------------------- >> >> 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? > > > 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.) > I am impatient to test the next release of your patch. Thank you for providing it. Cheers, Alex > Thanks, > > artur > > _______________________________________________ > vdr mailing list > vdr@xxxxxxxxxxx > http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr > _______________________________________________ vdr mailing list vdr@xxxxxxxxxxx http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
