Re: [vdr] silly question
Le vendredi 28 mars 2008 à 19:28 +, Andy Carter a écrit : > Check > > Setup->DVB->Update channels > > and select your preferred option Thanks! It has been a long time since I went in there... =:-D Tony -- ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Problems playing ongoing recordings?
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. > > > > artur > > > > ___ > > vdr mailing list > > vdr@linuxtv.org > > http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr > > Hi, > > 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. > > Rgds, > > Alex > > ___ > vdr mailing list > vdr@linuxtv.org > http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr Using the patch provided by Artur, playing a finished/ongoing recording is smoother than before. 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' <<>> 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) - 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:
[vdr] Upgrading to VDR-1.6.0 and CAM : does not decrypt anymore
Hi, I'm a VDR user for a few years now. I was using vdr-1.4.7 until today and wanted to upgrade to the 1.6.0 version. I just compiled and installed the 1.6.0 version over the previous running one. I noticed that VDR was modifying the channels.conf by tagging encrypted channels. I also remarked a random detection of tha cam module. It gives sometimes the correct model of the cam, sometimes not. The result of course is VDR is not decoding encrypted channels anymore. Is there a so huge difference on CAM handling between those two version that i missed a special parameter ? Any help really really appriciated. Thanks & regards Pierre PS : my setup : vdr-1.6.0 - dvb-s drivers from 2.6.20 kernel with dvb-ttpci-01.fw-2622 under a Hauppauge WINTV NEXUS S - ASTON CAM with valid subscription card from CanalSat (France ASTRA 19.2) ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] Deinterlace / Motion Compensation
Hi! I have a quesion to LCD TV owners. Most of the new LCD TVs have a "motion compensation" feature. Is it deinterlacing the picture? I'm going to buy Sony40", to connect to PC via DVI/HDMI with 720p or 1080p and run VDR with vdr-xine. Now Im using nvidia xxmc and the deinterlace is ugly. With LCD TV it'll be visible much more, so I need better deinterlacing - so I'm wondering if TV hw motion compensation will do it... Boguslaw Juza ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Problems playing ongoing recordings?
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' > > <<>> > > 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: 12582
Re: [vdr] HELP, no text in OSD anymore
C.Scheeder wrote: > i have a BIG Problem since this morning. > ithought before i install vdr-1.6 it would be wise to update my debian-sid to > the aktual packages. > But thta was a BAD Idea, after it all texts in VDR's OSD vanished. Please check, if you have installed any fonts in /usr/share/fonts/truetype. The package ttf-bitstream-vera and/or ttf-freefont should be installed. If they are, try updating your font-cache: dpkg-reconfigure fontconfig fc-cache -f -vv Please also check VDR's font configuration: cat /var/lib/vdr/setup.conf | grep ^Font Tobias ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Problems playing ongoing recordings?
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 <[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). > > 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' >> >> <<>> >> >> 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 SI
Re: [vdr] Deinterlace / Motion Compensation
Boguslaw Juza wrote: > Hi! > >I have a quesion to LCD TV owners. Most of the new LCD TVs have > a "motion compensation" feature. Is it deinterlacing the picture? > I'm going to buy Sony40", to connect to PC via DVI/HDMI with 720p > or 1080p and run VDR with vdr-xine. Now Im using nvidia xxmc and > the deinterlace is ugly. With LCD TV it'll be visible much more, > so I need better deinterlacing - so I'm wondering if TV hw motion > compensation will do it... > TVs de-interlace would matter with interlaced output but I suppose field/frame accurate scaled and original way interlaced e.g. 1080i output is not possible with Nvidia and X.org. I'm using progressive 1080p50 output for 576i50 DVB-T/S video. Libxine handles de-interlacing, and Xv driver in Xorg the scaling with graphics hardware. The magic spell from xinelibout config is xineliboutput.Video.DeinterlaceOptions = method=Greedy,cheap_mode=0,pulldown=none,framerate_mode=full,judder_correction=0, use_progressive_frame_flag=1,chroma_filter=1,enabled=1 The result is IMHO pretty good with a 50 Hz X.org mode where syncronization to vertical refresh is usually close to perfect. De-interlacing consumes more CPU than 576i MPEG-2 video decoding. Advertised techniques for frame rate interpolation to 100/120 Hz perhaps matter more for typical Blu-Ray low rate 24p videos than 50/60p progressive video from PC. I haven't seen those in action so I'm only guessing. BR, Seppo ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] DXR3 and subtitles in 1.5.x
En/na Rolf Ahrenberg ha escrit: >> Also, skinsoppalusikka doesn't update the palette of channel logos, if > > Well, IMO the skin isn't responsible of palette updates, but the real > problem might be in the osd implemantation of DXR3 plugin. channel logo *must* be disabled for the dxr3. Bye -- Luca ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] DXR3 and subtitles in 1.5.x
En/na Rolf Ahrenberg ha escrit: >> Also, skinsoppalusikka doesn't update the palette of channel logos, if > > Well, IMO the skin isn't responsible of palette updates, but the real > problem might be in the osd implemantation of DXR3 plugin. channel logo *must* be disabled for the dxr3. Bye -- Luca ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Problems playing ongoing recordings?
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'
<<>>
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
diff --git a/cutter.c b/cutter.c
index 5170ae4..7e2e506 100644
--- a/cutter.c
+++ b/cutter.c
@@ -66,7 +66,8 @@ void cCuttingThread::Action(void)
toFile = toFileName->Open();
if (!fromFile || !toFile)
return;
- fromFile->SetReadAhead(MEGABYTE(20));
+ fromFile->CuttingSrc();
+ toFile->CuttingDst();
int Index = Mark->position;
Mark = fromMarks.Next(Mark);
int FileSize = 0;
@@ -91,7 +92,7 @@ void cCuttingThread::Action(void)
if (fromIndex->Get(Index++, &FileNumber, &FileOffset, &PictureType,
&Length))
