Adding a new protocol handler

[Paul Webster]

I am now looking at adding a protocol handler for one of my plugins - so that I can have something like
radiogroup://station%20name
to play one

I have been reading
https://wiki.slimdevices.com/index.p...tocol_Handlers
and looked at some code in other plugins.

I can see that I need to call Slim::Player::ProtocolHandlers->registerHandler with the protocol name (radiogroup in this fake example) and the Perl package name as parameters.

Some have done this by having a file
ProtocolHandler.pm and then having something like this in the code of that module
Slim::Player::ProtocolHandlers->registerHandler('radiogroup', __PACKAGE__);

I am trying something similar but not seeing my code get called.

So ... does LMS automatically look for
ProtocolHandler.pm
to load in on plugin startup or is there something else that I have to do to get my ProtocolHandler.pm to be invoked?

[mherger]

> Some have done this by having a file
> ProtocolHandler.pm and then having something like this in the code of
> that module
> Slim::Player::ProtocolHandlers->registerHandler('radiogroup',
> __PACKAGE__);
>
> I am trying something similar but not seeing my code get called.
>
> So ... does LMS automatically look for
> ProtocolHandler.pm
> to load in on plugin startup or is there something else that I have to
> do to get my ProtocolHandler.pm to be invoked?

No, you'll have to do it in your Plugin.pm. I'd register there, and LMS
will then load the protocol handler if needed.

[bpa]

Some of this is a case of doing what other plugins have done.
Depending on functionality & how it is used, you may need to add an importer either by addImporter or in install.xml file.

[mherger]

> Some of this is a case of doing what other plugins have done.
> Depending on functionality & how it is used, you may need to add an
> importer either by addImporter or in install.xml file.

This is about the protocol handler, not the importer.

[Paul Webster]

Thanks ... that made me look harder at other plugins.

They do their own call to get it loaded by putting a Use in Plugin.pm - like this

use Plugins::myPluginName::ProtocolHandler;

I'll experiment with this way as well.

[Paul Webster]

As expected, that worked (calling it from Plugin.pm).
I quite like __PACKAGE__ as it makes it one less thing to remember when sharing code between plugins.
However, since I now have to remember to call the ProtocolHandler.pm from Plugin.pm then that is cancelled out

[AF1]

> Some have done this by having a file
> ProtocolHandler.pm and then having something like this in the code of
> that module
> Slim::Player::ProtocolHandlers->registerHandler('radiogroup',
> __PACKAGE__);
>
> I am trying something similar but not seeing my code get called.
>
> So ... does LMS automatically look for
> ProtocolHandler.pm
> to load in on plugin startup or is there something else that I have to
> do to get my ProtocolHandler.pm to be invoked?

No, you'll have to do it in your Plugin.pm. I'd register there, and LMS
will then load the protocol handler if needed.

So you can register it in ProtocolHandler.pm and put use Plugins::myPluginName::ProtocolHandler; in Plugin.pm - or register it right there in Plugin.pm.

Does it make a difference (ressources, etc.) or is the 'proper' way to do it more like a convention?

[mherger]

>> No, you'll have to do it in your Plugin.pm. I'd register there, and LMS
>> will then load the protocol handler if needed.
>
> So you can register it in ProtocolHandler.pm and put -use
> Plugins::myPluginName::ProtocolHandler;- in Plugin.pm - or register it
> right there in Plugin.pm.
>
> Does it make a difference (ressources, etc.) or is the 'proper' way to
> do it more like a convention?

The difference is in the last part of my previous posting: by
registering it in Plugin.pm, the ProtocolHandler.pm would only be loaded
when needed. This probably doesn't make much difference for a plugin
which you'd only install to use that protocol, though.

[AF1]

> $client->modeParam

I'm not even sure about this one, but IMHO it's legacy and shouldn't be
used.

According to some comment in the LMS server code (Client.pm) it seems that modeParam was actually meant to replace param. I'll keep the (inherited :-) modeParam parts that work (Erland's plugins use it a lot, esp. with older devices like Boom or Transporter) and will use pluginData and Slim-Cache the way you've outlined.
Thank you very much for taking the time to explain all the details.

[mherger]

> It seems Michael answered this post here.
>
> https://forums.slimdevices.com/showt...=1#post1038722

Sorry about that. The forum <-> email list sometimes seems to mess with
thread IDs...