VLC has 100% CPU-Load

[Dominik]

Hello again,

I'm using VLM from a VB.NET (VS2005 with .NET Framework 2.0) application and wonder about a strange behavior. Here's a code example where you can see the problem.

Code: Select all

'/ variables Dim _host As String = "192.168.1.1" Dim _port As String = "4212" Dim _TcpClient As System.Net.Sockets.TcpClient Dim _NetStream As System.Net.Sockets.NetworkStream Dim _StreamWriter As System.IO.StreamWriter Dim _StreamReader As System.IO.StreamReader '/ open connection to server _TcpClient = New System.Net.Sockets.TcpClient() _TcpClient.Connect(_host, _port) '/ using stream of socket connection _NetStream = _TcpClient.GetStream() _StreamReader = New System.IO.StreamReader(_NetStream, System.Text.Encoding.ASCII) _StreamWriter = New System.IO.StreamWriter(_NetStream, System.Text.Encoding.ASCII) _StreamWriter.AutoFlush = True '/ setting timeout value _NetStream.ReadTimeout = 2000 '/ sending the correct password _StreamWriter.WriteLine("admin") '/ read away the first line (it is the one with the password) _StreamReader.ReadLine() '/ test if I get the correct welcome-message back If Not _StreamReader.ReadLine().StartsWith("Welcome, Master") Then Throw New Exception("RZSTREAM is answering but with wrong welcomemessage.") End If '/ creating a VLM-stream _StreamWriter.WriteLine("new mainstream broadcast") _StreamWriter.WriteLine("setup mainstream input dshow://") _StreamWriter.WriteLine("setup mainstream option dshow-vdev=Capture1") _StreamWriter.WriteLine("setup mainstream option dshow-adev=none") _StreamWriter.WriteLine("setup mainstream option dshow-size=") _StreamWriter.WriteLine("setup mainstream output #transcode{vcodec=WMV2,vb=512,scale=1}:duplicate{dst=std{access=mmsh,mux=asfh,url=:1234}}") _StreamWriter.WriteLine("setup mainstream enabled") _StreamWriter.WriteLine("control mainstream play") '/ workaround for VLC-Bug?! Threading.Thread.Sleep(3000) _StreamReader.ReadLine() '/ close connection _StreamReader.Close() _StreamWriter.Close() _NetStream.Close() _TcpClient.Close()

So what this programm does is just to connect to the Telnet-interface, transmitting the correct password and then creating a working stream.

The critical part are the two rows from, what I called, "workaround for VLC-Bug?!"
If I don't have them both, the stream will start correctly, but the CPU of vlc.exe raises to 99% and never goes down again! The stream I started works well, but you can'T use the system and especially VLC in a normal way anymore. You can't for example start another job over VLM which saves this stream to a file. This file will be crippled

I've tested three versions:
0.8.4a, a nightly build from 15th february and one from 7th march.
The first two show the same behavior. If I wait three seconds and then do a ReadLine again, everything works. The programm finishes and the stream is running correctly.
With todays nightly build, the behavior of VLC is a little bit different. My program thrwos an execption, because it can't do the readline of the "workaround" part anymore, because there doesn't seem to be any data now. And just after confirming the error message box, I can see the cpu-load of VLC going up to 99% again!


When using the Telnet-Interface by hand, everything works as planned, so I guess my programm is doing something wrong. Something wrong, that leads to a hang of VLC!
I don't think this kind of behavior is wanted!


Greetings,
Dominik

[Dominik]

A short update:
Even with the two lines I called "workaround" VLC.exe sometimes crashes or hangs with 99% CPU-Load.
I tested my program over night and it stoped and started a recording to a file from my stream over VLM every hour. For 3 or 4 hours it worked very well, but then VLC.exe suddenly got into that 99% CPU-usage bug, and recordings startet after that point of time are crippled.
One recording which was running till tomorrow morning was totally ok, I think because it was started BEFORE vlc.exe had that 99% CPU-usage!
This is the "strange" thing. The stream is still working correctly, and even the recordings, which were started before that high usage are totally ok.
I don't really know what is going wrong, I only know that something is going wrong!
I think the Telnet-Interface from VLC is some kind of sensitive, because the 99% CPU-usage bug is reproduceable.
I would really like to know whats wrong with VLC and of course what i can do, to net let VLC run into this bug!

[Dominik]

The problem should be reproduceable by everyone, because you don't need to have that Direct-Show-Capture-Device. You can easily replay these 4 rows in my program with, for example:

Code: Select all

_StreamWriter.WriteLine("setup mainstream input c:\testvideo.wmv")

One interessting thing I recognised with this bug(?!).
As I don't want VLC to get into this high CPU-usage, I have to use these two lines:

Code: Select all

'/ workaround for VLC-Bug?! Threading.Thread.Sleep(3000) _StreamReader.ReadLine()

The 3 second Wait is needed, because if I don't do this, VLC doesn't do anything at all, when I want to use my program above. I get no message on the vlc-message-windows, so I suppose VLC is doing nothing! When I connect to the Telnet-Interface by hand, I can see that the broadcast is not created completly, like that:

Code: Select all

> show mainstream show mainstream type : broadcast enabled : no loop : no inputs dshow:// output : options dshow-vdev=Capture1 dshow-adev=none instances

But vlc.exe immediatelly runs into that 99% cpu-usage mode!



On the other hand, if I only do the 3 second wait, and don't do that ReadLine afterwards, VLC gets into that high CPU-usage after waiting these 3s seconds. But the stream is started correctly! But when VLC is in this high CPU-usage mode, no other new stream will work. You can create new streams or recordings, and they look like they are working, but the are not! Recordings are crippled (files with about only 33KB) and new streams can't be displayed/accessed.

[Dominik]

Maybe I found a solution:

I added the "exit" command to all of my different listings, so the programm really quits the connection to VLM.
But I still have to do that wait (3 seconds seem to be enough) afterwards.

If I don't do the wait, VLC still gets into that high CPU-usage mode, which very likely is not wanted by the developers!

The StreamWriter.ReadLine() which followed the 3 second wait seems to be obsolete in any case, not matter if using 0.8.4a or todays nighlty built!

In any case this could be a security issue, too, because everybody could possibly make a VLC-server unworkable in a certain way.