Re: Occasional crazy problem with vls

Andrew de Quincey wrote:
> Has anyone else seen something like this:
> 
> VLS is playing a looped MPEG2 program stream file, multicasting it as a UDP 
> MPEG2 transport stream.
> 
> This works fine.. normally.
> 
> However, sometimes _BUT NOT ALWAYS_, when the load on the server is high (e.g. 
> copying a large mpeg file onto it), VLS goes crazy. It starts sending the 
> stream out really fast... say 20x the speed it should. This continues until 
> it hits the end of the file, at which point it starts playing normally again.
> 
> Note that the problems doesn't always occur... usually videolan behaves 
> correctly with high loads, but as I said, occasionally this problem occurs. 
> I'm guessing this is some timestamping problem caused by the high load, as 
> the file plays perfectly in videolan at all other times.
> 
> I'm asking this because (for various reasons) I'm not using the most recent 
> version of videolan, although I'm not that far behind. Has anyone fixed 
> anything like this recently (before I start looking)?
> 
I don't think it is a problem as such of VideoLAN. What happens in this 
scenario is that the copy of the new mpeg file is messing up the 
harddisk cache. In fact all VLS request for data from the same disk 
start starving and this will result in sending out *late* packets like a 
mad man ;-).

What I am interested in is knowing if your video clients expierence a 
temporarly lack in video (like a big hole)? This would support my theory 
above.

If you run one of the newer kernels 2.4.23 (2.4.24) or 2.6.x then you 
should mount your drive with the anticipatory scheduler. The effect you 
have should then be gone. (As long as you don't try to push more data 
then the HD or PCI bus can swallow down its throat ;-)).

-- 
Kind greetings,

Jean-Paul Saman


-- 
This is the vls-devel mailing-list, see http://www.videolan.org/streaming/
To unsubscribe, please read http://developers.videolan.org/lists.html
If you are in trouble, please contact <[email protected]>