Need help with coding a ProtocolHandler

[AndrewFG]

I wrote a ProtocolHandler (for handling meta data related to my Whitebear application). And it works fine when playing tracks to a single Squeezeplayer, but it does not work when trying to play to a sync group of players.

I think the issue could be related to the canDirectStream, canIndirectStream, and/or canDirectStreamSong methods; all of these are currently implemented as stubs in my ProtocolHandler.

Can anyone please help me on possible changes to my code in order to support remote streaming to sync groups?

[erland]

Would you be willing to share the code ?
Just asking because I think it's a bit easier for someone to help if we get to see the code so we can see exactly what you are doing.

Is the scenario that the synced Squeezeboxes are playing a streaming provided by a Whitebear UPnP server ?

[bpa]

Have a look at the BBCiPlayer code handling of Flash. The plugin takes Flash/AAC, strips Flash and passes it to players.

[AndrewFG]

Would you be willing to share the code ?
Is the scenario that the synced Squeezeboxes are playing a streaming provided by a Whitebear UPnP server ?

Yes (here they are Plugin.pm, and ProtocolHandler.pm), and yes.

[Triode]

Yes (here they are Plugin.pm, and ProtocolHandler.pm), and yes.

What is the intended streaming path - does the audio go through the server or is the player expected to connect directly to the url? At present you have it connecting directly for the non synced case and going via the server if synced. Its also not clear if the stream has an http url type? [If it is whitebear then do you need to change the url type before using it?]

[AndrewFG]

What is the intended streaming path - does the audio go through the server or is the player expected to connect directly to the url? At present you have it connecting directly for the non synced case and going via the server if synced. Its also not clear if the stream has an http url type? [If it is whitebear then do you need to change the url type before using it?]

The context is related to the UPnP / DLNA "Play To" command (called SetAvTransportUri). When a remote Control Point issues this command, it passes an http URL together with track meta data and cover art url, to the player (in this case my Whitebear application); and in the next step, my Whitebear application would normally pass that url to LMS via the [player_id] playlist add {http://url} command.

The problem is that [player_id] playlist add {http://url} has no way to pass in the metadata or cover art url. So I wrote an LMS ProtocolHandler plugin for the "whitebear://url" protocol (almost 100% analog to the http://url protocol), so in this case Whitebear now calls LMS with [player_id] playlist add {whitebear://url}. My plugin also extends the cli with a new command so that Whitebear can store the metadata and the cover art in the LMS cache via the following command: whitebear setinfo {whitebear://url} album:Fred artist:Harry title:Music genre:Rock coverart:anArturl etc. This ProtocolHandler informs LMS that the streamURL associated with the given "whitebear://url" is "http://url" -- so the stream is actually downloaded via the normal HTTP ProtocolHandler. The ProtocolHandler also supports the getMetaDataFor() method which retrieves the metadata associated with the given "whitebear://url" from the LMS cache (as has just been provided to LMS by the "whitebear setinfo" cli command).

[Triode]

The context is related to the UPnP / DLNA "Play To" command (called SetAvTransportUri). When a remote Control Point issues this command, it passes an http URL together with track meta data and cover art url, to the player (in this case my Whitebear application); and in the next step, my Whitebear application would normally pass that url to LMS via the [player_id] playlist add {http://url} command.

The problem is that [player_id] playlist add {http://url} has no way to pass in the metadata or cover art url. So I wrote an LMS ProtocolHandler plugin for the "whitebear://url" protocol (almost 100% analog to the http://url protocol), so in this case Whitebear now calls LMS with [player_id] playlist add {whitebear://url}. My plugin also extends the cli with a new command so that Whitebear can store the metadata and the cover art in the LMS cache via the following command: whitebear setinfo {whitebear://url} album:Fred artist:Harry title:Music genre:Rock coverart:anArturl etc. This ProtocolHandler informs LMS that the streamURL associated with the given "whitebear://url" is "http://url" -- so the stream is actually downloaded via the normal HTTP ProtocolHandler. The ProtocolHandler also supports the getMetaDataFor() method which retrieves the metadata associated with the given "whitebear://url" from the LMS cache (as has just been provided to LMS by the "whitebear setinfo" cli command).

Not sure I see where you convert the whitebear:// url to an http:// url ?? - I suspect if the stream is processed by the server it may need to be an http url.

[AndrewFG]

Not sure I see where you convert the whitebear:// url to an http:// url ?? - I suspect if the stream is processed by the server it may need to be an http url.

As far as I understand it, the base HTTP ProtocolHandler class recognises two urls namely, 1) the "scheme url" which LMS uses to determine which of the available ProtocolHandler classes to instantiate, and 2) the "stream url" which LMS uses to actually to do the download. In the base class HTTP ProtocolHandler both of these are http:// ...

The Whitebear ProtocolHandler class is descended from the LMS built-in HTTP protocol handler and overrides "whitebear://" as its scheme url, (so if LMS encounters a url beginning with whitebear:// it knows it must instantiate the class in my handler), however the stream url remains "http://" as this was inherited from the base HTTP class.

[Triode]

As far as I understand it, the base HTTP ProtocolHandler class recognises two urls namely, 1) the "scheme url" which LMS uses to determine which of the available ProtocolHandler classes to instantiate, and 2) the "stream url" which LMS uses to actually to do the download. In the base class HTTP ProtocolHandler both of these are http:// ...

The Whitebear ProtocolHandler class is descended from the LMS built-in HTTP protocol handler and overrides "whitebear://" as its scheme url, (so if LMS encounters a url beginning with whitebear:// it knows it must instantiate the class in my handler), however the stream url remains "http://" as this was inherited from the base HTTP class.

I've always manually changed the protocol handler's scheme to http if necessary... What does debug player.streaming.remote and player.streaming.direct show?

Do you get the same problem with the "MP3 Streaming Method" set to "Proxied Streaming" in the non sync case (i.e. forcing the stream to always avoid direct streaming)

[AndrewFG]

I've always manually changed the protocol handler's scheme to http if necessary...

How do you do that? Can you kindly give me a code snippet?

What does debug player.streaming.remote and player.streaming.direct show?
Do you get the same problem with the "MP3 Streaming Method" set to "Proxied Streaming" in the non sync case (i.e. forcing the stream to always avoid direct streaming)

Many thanks for the leading questions. I will check these tomorrow and get back to you.

Can you in the meantime help me understand "direct" and "indirect" streaming? I suppose that direct streaming means that the player GETs the track directly from the server (resp. each player in the sync group GETs it). Whereas indirect means that LMS does one GET and then pushes the same stream to each synced player. Is that correct? If so, then probably in my case I would prefer to have single players doing direct streaming, and multiple synced players doing indirect. So ultimately my question is which methods do I need to provide in my ProtocolHandler, and what results they should deliver?