Serviio

Hi,
I've already seen an answer to this in another post, but it was a workaround rather than a solution.

When BubbleUPnP has its renderer enabled and appears on Serviio's list of renderers, it can't be used as a controller for any device that requires media to be transcoded. This appears to be because Serviio treats any requests from BubbleUPnP as being for its renderer and not the target device, e.g. a Bravia TV.
A previous answer to this was to change bubble upnp to have the bravia profile in Serviio, but this seems like a workaround where you'd have to keep changing the profile each time you wanted to control a different device.
I've asked on the bubble upnp thread and they're saying it's a serviio issue.
Does serviio attempt to read the full request from bubble or does it just look and say it came from device x therefore use that profile without considering that it might just be a controller command?
Thanks

it doesn't distinguish between controller and renderer ATM

Thanks. Hope it gets implemented one day given that smart phones make perfect controllers.

AKAIK the controller sends the same commands as the TV would, but from it's own IP address. Profile matching is dependent on the IP address of incomming request, so unless the controller sends some information about the target device it won't work dynamically. Will try later.

Hi,

Finally got a bit of time and compared the logs of a direct request from my Bravia and a controller request from Bubble UPnP.
Compare these two extracts:

Request from Bravia after browsing Serviio on Bravia:


Request from Bravia after browsing Serviio from BubbleUPnp:


Then a few lines down the BubbleUPnP version errors with:


Where the direct Bravia goes:


I'm guessing that Bubble is telling the Bravia what to request, Bravia goes off and requests it and then Serviio says the Bravia can't support that so throws an error, i.e. the initial browsing of the library tells a renderer what it can ask for so the need for transcoding is determined before an actual request to play something is made.

Can anything be done about this as it seems to be the key thing that stops Serviio supporting a generic DLNA controller?

Is this where you tell me it's been changed in version 1.0?

Thanks

Gary

you have to look further up in the logs where it invokes Browse() method. It will also say what profile it used... it looks like the Bravia uses correctly Bravia profile (and responds with the right URL transcoding to LPCM), which is consequently requested as per your logs.

Bubble is probably using a different profile, one that transcodes the audio to flv (?) or gets ute (FLV) Url from it's cache somewhere

The bubble profile doesn't transcode (it doesn't need to). What I'm getting at is that by having the browse determine whether to transcode, Serviio can't work with a pure controller. Bubble doesn't (and probably shouldn't) have any knowledge of what the renderer is capable of playing and Serviio ought to transcode to a supported format when a request comes through for an unsupported format.
That's my opinion anyway

This is how it works:

1) Renderer/controller call Browse method which responds with a URL for the video resource.
2) Renderer makes a GET request to the URL - it has no extensive knowledge of what it is, the only thing it can do is call this URL, which includes a hint used by Serviio of what format it is (as determined by the Browse method)

DLNA itself doesn't have a concept of profiles, it doesn't REALLY deal with transcoded files and if everything was mpeg2 it'd just work. Serviio could also offer multiple resources and let the renderer pick one, but that hardly ever works.

So you can see that deciding whether to transcode based on the incoming GET request is impossible (partly because the Browse method requires already target codec/container/resolution etc).