[vlc-devel] Re: [Fwd: Re: VLM Bug (fixed)]

[oscar perez]

It is not actually just a bug related to my interface but a vlm specific 
bug. It is also fairly easy to reproduce. First off, it is needed to create 
one config file such as the attached. With this file in the vlc folder, just 
it is needed to run the command..: ./vlc -I telnet --vlm-conf multivlc.conf
After running the command several times, the results look like kind of 
random and I bet this is because of the "too eager" creation of the 
input_thread. Perhaps my solution is not perfect. I am aware of that but at 
least it works.
Greetings,
Óscar

On 16/08/05, Jean-Paul Saman <jean-paul.saman at planet.nl> wrote:
> 
> Patch from a user who encountered a problem when writing his own
> interface for using VLM. Can someone with intimate knowledge of VLM have
> a look at this? Maybe we suffer from the same problem he encountered
> without us knowing it.
> 
> Greetings,
> Jean-Paul Saman.
> 
> 
> 
> ---------- Forwarded message ----------
> From: oscar perez <oscarfernando.perez at gmail.com>
> To: Jean-Paul Saman <jean-paul.saman at planet.nl>
> Date: Tue, 16 Aug 2005 15:14:45 +0300
> Subject: Re: VLM Bug (fixed)
> Hi!
> Sorry for the delay but videolan.org <http://videolan.org> and developers 
> webpage have been down for me since 2 days ago and that is why I could not 
> send before the patch. The xcommon.c is just for debugging so it is not 
> even worth a look. The vlm.c now grabs all the options perfectly to me. It 
> was 2 issues. 1st is that for the option of reading a file they used 
> vlm_ExecuteCommand and afterwards reading a command in Load they use 
> ExecuteCommand which is the same but without mutex. It should be the other 
> way around, not creating a mutex per config file but per command. The other 
> issue is that at the beginning is created a new thread which runs the 
> function manage. This function is loaded as soon as one instance is created 
> (with the command play) but the problem is that a thread is also created and 
> we must leave a certain time before creating this thread in order to 
> guarantee that the options go along with the input. Doing a msleep works 
> just fine to me. It might not be the most correct solution but it works fine 
> for me. Maybe a mutex there is better? I don't know..
> Greetings,
> Óscar
> 
> 
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.videolan.org/pipermail/vlc-devel/attachments/20050818/3752f660/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: multivlc.conf
Type: application/octet-stream
Size: 1063 bytes
Desc: not available
URL: <http://mailman.videolan.org/pipermail/vlc-devel/attachments/20050818/3752f660/attachment.obj>