Re: [vdr] vdr-xine 0.7.10 buffering
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 ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] vdr-xine 0.7.10 buffering
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 1 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. -- Dipl.-Inform. (FH) Reinhard Nissl mailto:[EMAIL PROTECTED] ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
