about stop gmrender problem about gmrender-resurrect HOT 6 OPEN

So you mean if there is a song playing, and potentially one more enqueued via gapless, gmrender does not stop playing immediately on catching a signal ?

I'll have a look - I explicitly tell the main loop to exit when I receive a SIGINT or SIGTERM signal (via g_main_loop_quit()) but maybe that does not try to stop as soon as possible.

Can you tell me, which version of gstreamer you linked against ? 0.10 or 1.0.x ?

from gmrender-resurrect.

Hi,hzeler
Sorry,Maybe I don't speak clearly.when gmrender process receive a signal from other process, I want to stop playing immediately but the gmrender process don't exit if gmrender process is playing some songs.
Now, I call stop function in upnp_transport.c when gmrender process receive a signal, the output_stop function will stop gstreamer playing, It is right, But gmrender will continue to play the next song from the BubbleUPnp client that if BubbleUPnp client's playlist have many songs.
My mean isn't exit gmrender process when receive a signal from another process, because I want that the gmrender can continue to play song when I manipulate BubbleUPnp client after deal with the signal.

from gmrender-resurrect.

So for me to understand: you added an additional signal handler, in which you call the stop function upnp_transport.c ? Note that this is dangerous, as you usually can't really do that kind of work from a signal handler.

What you should do instead, is to implement a simple UPnP controller, that just sends the 'Stop' signal via UPnP. Similar as running a separate BubbleUPnP that just sends 'stop'.

But even if it does, what you observe is that BubbleUPnP doesn't apparently really deal with this - it continues to send things in its playlist. You can try simulating this by having a second BubbleUPnP on another phone and see how they behave: one plays, and then you press the stop-button on the other one. Ideally, the first BubbleUPnP would detect that the player suddenly is in 'stop' mode and assumes this is for a reason and stops sending music unless someone explicitly presses 'play' again.

Essentially you now have two different controllers competing for the same renderer, and BubbleUPnP doesn't seem to be good in sensing what is going on.

from gmrender-resurrect.

Thanks,Hzeller,You are very nice.
The above question maybe have been solved by myself.
But I meet another problem, when I play songs with gmrender throught BubbleUPnP, the gmrender maybe cann't response(will stop playing and cann't device discovery) under pressure test that I click continualy the playlist in BubbleUPnP client, the gmrnder process is still alive, the network is ok that can be ping, But why the device cann't discovery, How can it be affect upnp device discovery,I don't understand why is it that.

from gmrender-resurrect.

Are you using gstreamer 1.0.x ? The 0.10 version has a problem that leaks threads.

from gmrender-resurrect.

@hzeller:

I have added an option in BubbleUPnP to detect Stop commands comming from other Control Points or a renderer's UI or remote, etc, and not consider it is a track change.
See this post if you want to try the beta: http://forum.xda-developers.com/showpost.php?p=44046137&postcount=3637

The option is in Settings > UpnP Tweaks > Detect remote Stop.

It is in fact quite problematic to detect a remote Stop and make sure it is not due to end of track, that's why it is not enabled by default and was reluctant to handle this (yet another option!). That, and if a renderer stops playback mid-track on its own for whatever reason (network failure) and sends a Stop event, this has the side effect to stop track advance.

from gmrender-resurrect.