hi,
as the kernel finally supports standby or spin down or whatever mode for my SATA disks, I have set up an aggressive scheme trying to spin down disks whenever possible. The results: 2 degrees drop in case temperature and a significantly lower noise. And a playout "problem"...
It takes about 5 secs to start stopped disks. It is not a problem when starting a recording, but when recordings span over several disks there will be an annoying pause when it is time to start reading from another disk.
The live-TV buffering works like a charm, though.
Is there a possibility to configure (for example) a 10s buffering for playback while keeping the live-TV buffering as it is now?
yours, Jouni
Hi,
Jouni Karvo wrote:
It takes about 5 secs to start stopped disks. It is not a problem when starting a recording, but when recordings span over several disks there will be an annoying pause when it is time to start reading from another disk.
Is there a possibility to configure (for example) a 10s buffering for playback while keeping the live-TV buffering as it is now?
I don't think that this is a matter of vdr-xine but at least it looks like there is a simple solution in xine regarding the annoying pause: try to increase
engine.buffers.audio_num_buffers
and
engine.buffers.video_num_buffers in xine's config file ~/.xine/config so that these input buffers are able to hold 10 seconds of the stream.
Depending on the sampling rate of the audio stream, a single buffer may hold for example 24 ms of audio data. So a 10 seconds buffer will need 10000 ms / 24 ms = 416 buffers.
A formula for video isn't that easy, so let's assume 60 seconds of the stream make 30 MB on disk => 10 seconds yield 5 MB. A single buffer holds 2048 Byte so for 10 seconds you'll need 5 * 1024 * 1024 / 2048 = 2560 buffers.
As xine tries to keep it's input buffers filled, VDR will read ahead 10 seconds in regard to the position of the image you currently see on screen. This should allow the other disk to spin up without an input buffer underrun.
A drawback of such large buffers is that VDR is way ahead the picture you currently see on screen. So if you jump forward 60 seconds, you'll actually jump 70 seconds and if you jump backward 60 seconds you'll only jump 50 seconds. That's why I suggested in my MANUAL to set audio_num_buffers to the smallest value possible which is 4.
In my opinion, a more proper solution should patch VDR to do some nonblocking dummy reads on the next recording file when replaying the current recording file enters the "disk spinup" margin.
Bye.
hi,
Reinhard Nissl writes:
I don't think that this is a matter of vdr-xine but at least it looks like there is a simple solution in xine regarding the annoying pause: try to increase
engine.buffers.audio_num_buffers
and
engine.buffers.video_num_buffers
Ah, thanks for the hint! I changed these to the values you recommend - let's see how it works out...
A drawback of such large buffers is that VDR is way ahead the picture you currently see on screen. So if you jump forward 60 seconds, you'll actually jump 70 seconds and if you jump backward 60 seconds you'll only jump 50 seconds. That's why I suggested in my MANUAL to set audio_num_buffers to the smallest value possible which is 4.
This might not be a very bad problem - I wonder how jumping to cutting marks then works out. I would guess based on your description that probably OK (unless the next cutting mark is on a different disk, but that is again not such a bad problem).
In my opinion, a more proper solution should patch VDR to do some nonblocking dummy reads on the next recording file when replaying the current recording file enters the "disk spinup" margin.
Yes, this could be the next step if this "quick hack" should not work as expected.
Thanks for the info - I'll let you know how this turns out.
yours, Jouni
Hi,
Jouni Karvo wrote:
A drawback of such large buffers is that VDR is way ahead the picture you currently see on screen. So if you jump forward 60 seconds, you'll actually jump 70 seconds and if you jump backward 60 seconds you'll only jump 50 seconds. That's why I suggested in my MANUAL to set audio_num_buffers to the smallest value possible which is 4.
This might not be a very bad problem - I wonder how jumping to cutting marks then works out. I would guess based on your description that probably OK (unless the next cutting mark is on a different disk, but that is again not such a bad problem).
If you set a cutting mark while watching a recording, you'll set it 10 seconds in the future compared to the image on screen. When you jump to a cutting mark, you'll see the image at the actual position, because VDR first clears all buffers and then just sends a single I-frame so there isn't much which xine could buffer in that case.
If you show the recording's progress menu and switch to play (after a jump to a cutting mark), you'll see that the progress bar advances very quickly by 10 seconds, as VDR sends the recording data as fast as possible (i. e. as fast as your harddisk can supply the data) to xine.
Bye.
hi,
Reinhard Nissl writes:
If you show the recording's progress menu and switch to play (after a jump to a cutting mark), you'll see that the progress bar advances very quickly by 10 seconds, as VDR sends the recording data as fast as possible (i. e. as fast as your harddisk can supply the data) to xine.
Yes, I saw this. As I do not "cut" recordings, the 10s delay does not matter. Yesterday we watched one recording and did not notice any hickups when the recording jumped to another disk drive, so it does seem to work as expected. Of course there is always the possibility that the disks just happened to be running when the time to change arrived...
I think this hint could be found in the vdr-xine manual, as it certainly is useful.
yours, Jouni
-
Jouni Karvo -
Reinhard Nissl