How to make the VLC client quit at end of multicast stream?

[SoftwareDave]

VLC 0.7.2, Windows 2k pro.

I need to have the client application quit automatically at the end of the UDP stream. I'm aware of the vlc:quit option, but while that works at the server end (it streams then quits, as expected), it has no effect at the client end, which just sits there with the last frame of the video visible.

Reason I ask: the client is running on stand-alone computers - there is no user.

Any way of doing this from the command-line options?

If not, can anyone give me any hints as to where to look in the source to detect the end of the stream - I am successfully building this under Cygwin.

Thanks.

[The DJ]

well udp: is a never ending stream. This is because it is based on "listening" to a certain address instead of negotiating a receive. What can be done, is to create a udp-timeout option in modules/access/udp.c which would stop the access if nothing has been received for a certain amount of time. Be aware that this will lower the ability of this streaming method to operate in situations with bad connections etc, if this option would be enabled.

[SoftwareDave]

Thanks DJ, I had this feeling someone was going to say that
I think I may have a shot at sending an "end of stream" packet from the server when it detects the end of the input. I suppose the problem there though is what if the client doesn't receive it. Maybe I need a timeout as well.... hmmm.

[markfm]

An internal timeout based on the stream stopping for some user-selectable period of time might not be bad, effectively warns you that there is either a real stop (whether end of film or the server has gone belly-up) or a network problem.

Alternately, if you are working with pre-canned items, deterministic length, you could batch things from the client end, use the AT (scheduler) ability of Windows (if Windows is your environment -- 'nix uses cron, I believe), plus a process killer app like pskill or process to shut down VLC after a pre-determined time.

[SoftwareDave]

Yes, I think that might be the answer. I do know the duration of the video stream, so I could do a forced termination. In fact, I can detect at the server when the server vlc terminates (because I'm using vlc:quit) and then issue a terminate command from the server. That's going to be simpler than digging into the source.
Of course that doesn't handle server failures. Still looks like it needs a timeout.

[SoftwareDave]

Fishing for another clue here...

I'm looking at this timeout option. Within the Read function in modules/access/udp.c, a call is issued to net_Read. This is a blocking call, and so if there is nothing coming over the network stream, net_Read does not return. Hence it's not straightforward to implement a timeout there.
So, one option is that each time the Read function is called, I start off another thread which simply times out or looks for a signal of some sort from the main thread which I can set when I receive data. If it times out, it would terminate the app.
However, how would you force a termination of the main app from within the udp plug-in?
I experimented with setting the b_die flag, using the VLC_OBJECT() definition to create a vlc_object_t from p_input but that doesn't seem to kill the app, just seems to tell something somewhere that there's nothing coming over the stream, and to restart looking for the start of a stream.
TIA

[The DJ]

i think there is also a 'non blocking' read function available. (maybe only in the development version?).

[SoftwareDave]

Yeah, there is, I could try it, but my main problem is terminating the app.
I'm really on a big hack here. I don't actually understand how this software works, particularly when it comes to accessing data between the main app and the various plug-ins, so, for instance could I get the window handle from somewhere and send a WM_CLOSE?.

[The DJ]

do a
p_vlc->b_die = VLC_TRUE

and vlc will quit

[SoftwareDave]

Yes, that worked. I did try something similar before - see earlier post - but I was obviously on slightly the wrong track. After your post I sniffed around a bit more, I found p_input->p_vlc->b_die and yes, that does the trick, thanks.

However, in the meantime I'd written a separate monitor app, which I send messages to from VLC, eg created main window, got network packet etc. From that I can implement a timeout and kill VLC. The main advantage at the moment is that it takes 5 seconds to build as opposed to the hour it takes to build VLC!

[markfm]

If you are doing work within a given section of code, the make should go quickly. You just delete the .o/.dll/.exe files from that part of the trunk, run make at the top level. Make will go through all of the unchanged sections, leave the pre-existing DLLs alone with a "Nothing to do" message. Very painless, quite quick.

[SoftwareDave]

Yeah, I found I could do that with plugins. It's when you have to do something like change a header file. I can't figure out the dependencies, so I have to do a make on the whole thing.

Also if I change the vlc.c file, then try make within the src directory it doesn't do anything, I have to make from the vlc root directory, which takes all day to figure out that nothing really needs doing. Any idea what I'm doing wrong?

Basically I really am just hacking here! I don't pretend to understand this stuff at all... afraid I'm a through and through Windoze guy for my sins.

Thanks for the help from you guys, I really appreciate it.

[Sigmund]

"make vlc" will make only the core, and not traverse the modules

[SoftwareDave]

Thanks Sigmund, but:

Code: Select all

SoftwareDave@development ~/vlc-0.7.2 $ cd src SoftwareDave@development ~/vlc-0.7.2/src $ touch vlc.c SoftwareDave@development ~/vlc-0.7.2/src $ make vlc make: *** No rule to make target `vlc'. Stop. SoftwareDave@development ~/vlc-0.7.2/src $ cd .. SoftwareDave@development ~/vlc-0.7.2 $ make vlc make: Nothing to be done for `vlc'.

Am I doing something wrong?