The VideoLAN Forums

Hi,
I am using libvlc to stream video over wifi. When wifi suddenly disconnects, if the VLC control still indicates that the video is still playing, I call "libvlc_media_player_stop".

Unfortunately, in this scenario calling "libvlc_media_player_is_playing" shows that the video still plays (although I can visually see that it's stuck) and the subsequent call to "libvlc_media_player_stop" hangs for ~30 seconds.

What exactly am I doing wrong?

Nothing. is_playing indicates whether the media pipeline is playing, not whether there is any data.

As for the timeout, that depends on the protocol used. At least RTSP can be extremely slow in case of timeout.

Ok, I understand, thanks, but don't you think that in any case the "stop" command should return immediately and not lock the application for so long?

Do I really need to call "stop" in such cases? Is there any function I can use to quickly identify scenarios where the pipe no longer transfers data (and then maybe call "stop" in a sub-thread and not lock the application)?

Yes it should, but as Rémi told you it depends on the protocol.
Is it RTSP ? if yes vlc 1.2 should fix this blocking timeout on stop.

Yes it's RTSP

try latest git version if you can, or a nightly build.

And the result of the story?

I have the same problem, in some machines VLC (or my application using libvlc) hang when I click STOP (or I send the stop command).

I'm using VLC 2.0.1

live555 can get stuck when there is a network problem. I don't think that can be fixed in VLC, other than by ripping out live555 entirely in favor of a would-be native RTSP stack. And that is humonguous work.

jcsanchez, is it with rtsp streams ?

I fixed the problem installing Windows7 SP1.

Thanks for your help.

To clarify this rtsp hang issue :
With vlc before 2.0 rtsp streams could hang for a long time when sending a teardown message.
This issue is fixed in vlc 2, but it stil can hang on rtsp connect.