MinimServer Forum

Full Version: BubbleUPnP and Pause/Next track
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
Pages: 1 2 3
(27-09-2013 10:49)bubbleguuum Wrote: [ -> ]You mean media server proxies ? Yes it can be added and I probably will add these 2 DLNA fields (if they are not already set by the media server), as it should not have any side effect (ignored by non DLNA renderers). At best it will add seek/pause ability to some renderers where it would have previously failed and at worse it may still fail because the underlying media server may not support it (range requests for seeking).

No, I meant media renderer proxies. Adding it on the server side pollutes the standard protocols that are sent across the network and adds further to the existing confusion about what metadata for UPnP media types and DLNA media types should be sent by servers and expected by control points and renderers.

Adding these DLNA fields in a media renderer proxy would confine the nonstandard protocol to the local interactions between the noncompliant renderer and its proxy. The nonstandard protocols wouldn't leak out onto the network, and no other devices would see them.

I think an approach like this is the only way to promote standards compliance. At the moment, we seem to be engaged in a "race to the bottom" where a noncompliant renderer "forces" servers to be noncompliant as well, which in turn encourages control points and other renderers to also adopt the noncompliant conventions, etc.

Quote:For the same reason I think you could add them to minimserver for all items whether DLNA media types or not (do not set DLNA.ORG_OP=01 for media types not supporting seeking, if any)

For the reasons described above, I will do my best to find other solutions that don't require the server to send this nonstandard metadata for non-DLNA media types.

Quote:And it is super likely, that I will add these flags too in Android BubbleUPnP, at SetAVTransportURI() time.

This would be somewhat similar to doing it in a renderer proxy. Would you do it for all renderers, or just for renderers that are known to have this issue?
(27-09-2013 11:15)simoncn Wrote: [ -> ]
(27-09-2013 10:49)bubbleguuum Wrote: [ -> ]You mean media server proxies ? Yes it can be added and I probably will add these 2 DLNA fields (if they are not already set by the media server), as it should not have any side effect (ignored by non DLNA renderers). At best it will add seek/pause ability to some renderers where it would have previously failed and at worse it may still fail because the underlying media server may not support it (range requests for seeking).

No, I meant media renderer proxies. Adding it on the server side pollutes the standard protocols that are sent across the network and adds further to the existing confusion about what metadata for UPnP media types and DLNA media types should be sent by servers and expected by control points and renderers.

Adding these DLNA fields in a media renderer proxy would confine the nonstandard protocol to the local interactions between the noncompliant renderer and its proxy. The nonstandard protocols wouldn't leak out onto the network, and no other devices would see them.

I think an approach like this is the only way to promote standards compliance. At the moment, we seem to be engaged in a "race to the bottom" where a noncompliant renderer "forces" servers to be noncompliant as well, which in turn encourages control points and other renderers to also adopt the noncompliant conventions, etc.

Quote:For the same reason I think you could add them to minimserver for all items whether DLNA media types or not (do not set DLNA.ORG_OP=01 for media types not supporting seeking, if any)

For the reasons described above, I will do my best to find other solutions that don't require the server to send this nonstandard metadata for non-DLNA media types.

Quote:And it is super likely, that I will add these flags too in Android BubbleUPnP, at SetAVTransportURI() time.

This would be somewhat similar to doing it in a renderer proxy. Would you do it for all renderers, or just for renderers that are known to have this issue?


There are no UPnP AV renderer proxies in BubbleUPnP Server. Just media server proxies and OpenHome renderers.

I'm not going to argue over this. I'll do my own thing (workarounding stuff if necessary, so it just appear to work from the user's POV) and you'll do your own.
(27-09-2013 11:31)bubbleguuum Wrote: [ -> ]There are no UPnP AV renderer proxies in BubbleUPnP Server. Just media server proxies and OpenHome renderers.

I'm not going to argue over this. I'll do my own thing (workarounding stuff if necessary, so it just appear to work from the user's POV) and you'll do your own.

bubleguuum - Thanks for this - it would be great to know when this capability has been added - either to BubbleUPnP Android or Server. I guess you could make it an additional option (or options for different capabilities - pause, fast forward &c).
I've been studying what the DLNA spec says about this. A DLNA-compliant renderer that uses the connection stalling method of pausing is required to check that the Connection Stalling flag is set in DLNA.ORG_FLAGS in the fourth field of protocolInfo. This applies to non-DLNA media profiles (such as FLAC) as well as to DLNA media profiles.

This implies that a server that wants to allow a DLNA-compliant renderer to do pausing by connection stalling must set the Connection Stalling flag in DLNA.ORG_FLAGS in the fourth field of protocolInfo. The next release of MinimServer will set this flag for streams that support pausing by connection stalling.

Some streams can't support pausing by connection stalling. An example of this is a live radio stream that is being relayed by the server. For such streams, MinimServer will not set the Connection Stalling flag. If the server were to set this flag for such a stream, the renderer might attempt to use connection stalling to pause the stream, which would fail.

Similarly, if a control point sets the Connection Stalling flag without knowing whether or not the server can support connection stalling for that stream, this could problems if the renderer attempts to use connection stalling to pause the stream.
I too am seeing the "Action Failed 501" error from BubbleUPnP. But not related to internet radio, or pause/next track. I have MinimServer 2 installed on a Synology NAS with about 100 tracks copied from CDs. I installed "Audiophile UPnP Renderer" on my PC as a music player. Using BubbleUPnP on my android phone I can browse the library on the NAS with MinimServer and I can see the Audiophile UPnP Renderer as a player. When I select a track to play the track name appears in the Audiophile UPnP Renderer window on my PC, but the "Action Failed 501" in BubbleUPnP is all that happens. I noticed that my TV's chromecast was showing up in BubbleUPnP as a renderer, when I selected that the track played through my TV. At first I suspected the Action Failed 501 message was coming from Audiophile UPnP Renderer, but evidently it shows up in BUbbleUPnP with other renderers as well, so I don't know where the error originates, or what causes it. Any suggestions would be appreciated.
I found this thread on "Audiophile UPnP Renderer". In the thread, two different users have had the "Action Failed 501" error but there are no replies about what causes this or how to solve it.

There might be a setting in BubbleUPnP that you can change to solve this. I suggest you ask about this on the BubbleUPnP forum thread if you haven't already done so.
(16-07-2020 10:37)simoncn Wrote: [ -> ]I found this thread on "Audiophile UPnP Renderer". In the thread, two different users have had the "Action Failed 501" error but there are no replies about what causes this or how to solve it.

There might be a setting in BubbleUPnP that you can change to solve this. I suggest you ask about this on the BubbleUPnP forum thread if you haven't already done so.

I stumbled across a very old post of yours on the OpenHome forum.

http://forum.openhome.org/showthread.php?pid=1613

It refers to

The UPnP Device Architecture specification defines the following error codes on page 53:

501 Action Failed May be returned in current state of service prevents invoking that action.
This is what the 501 code means but there is no reason in the OP's scenario to think that this code is being returned by ohNet (not sure if that's what you were suggesting).
(16-07-2020 13:13)simoncn Wrote: [ -> ]This is what the 501 code means but there is no reason in the OP's scenario to think that this code is being returned by ohNet (not sure if that's what you were suggesting).

No, no, certainly not suggesting an ohNet involvement. Smile

It was that the message source and description contained more detail than that reported in previous posts.
Thanks to everyone for the information. I saw Bubbleguum here on this thread and thought I might to be able to reach both developers with the problem. I will follow up on the BubbleUPnP forum. I think there may be a glimmer of information in the fact that having selected my Chromecast as the renderer the track played through the TV. So, MinimServer 2 seems to be doing its job in that case, as does BubbleUpnP. Unless I run across something specific my next move will probably be to download and install TuneBrowser as a renderer and then see what happens. Before I make the change I will activate 'debug' level logging for MinimServer 2 and MinimWatch in the chance it may reveal something useful, and try it one last time.
Pages: 1 2 3
Reference URL's