BubbleUPnP and Pause/Next track

[simoncn]

(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?