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<br>
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.<br>
Greetings,<br>
Óscar<br><br><div><span class="gmail_quote">On 16/08/05, <b class="gmail_sendername">Jean-Paul Saman</b> <<a href="mailto:jean-paul.saman@planet.nl">jean-paul.saman@planet.nl</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Patch from a user who encountered a problem when writing his own<br>interface for using VLM. Can someone with intimate knowledge of VLM have<br>a look at this? Maybe we suffer from the same problem he encountered<br>without us knowing it.
<br><br>Greetings,<br><span class="sg">Jean-Paul Saman.<br><br></span><br><br>---------- Forwarded message ----------<br>From: oscar perez <<a href="mailto:oscarfernando.perez@gmail.com">oscarfernando.perez@gmail.com</a>
><br>To: Jean-Paul Saman <<a href="mailto:jean-paul.saman@planet.nl">jean-paul.saman@planet.nl</a>><br>Date: Tue, 16 Aug 2005 15:14:45 +0300<br>Subject: Re: VLM Bug (fixed)<br>Hi!<br>
Sorry for the delay but <a href="http://videolan.org" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">videolan.org</a> 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..<br>
Greetings,<br>
Óscar<br>

<br><br clear="all"></blockquote></div><br>