[squeezebox] Implement like/unlike for remote streaming services

[mhilbush]

Some streaming services, such as Pandora and Slacker, support "liking" or "unliking" the currently playing song. Liking a song causes the streaming service to play more songs like the currently playing song. Unliking the song skips the currently playing song, and won't play it again. As each streaming service has a different way to accomplish this, the LMS jsonrpc service supplies the specific like/unlike commands based on the service that's streaming the song. It does this by overriding the functionality of the repeat and shuffle buttons

This change adds two new channels to the player thing - like and unlike. If a streaming service doesn't support the like/unlike functionality, sending a command to the like or unlike channel does nothing.

Unfortunately, the current implementation of the squeezebox binding does not use the Logitech Media Server (LMS) jsonrpc service; it uses the older command line interface (CLI). Therefore, I needed to extend the binding to support the jsonrpc service in order to obtain the like/unlike commands.

I considered changing the binding to use only the jsonrpc service; however, that would require very significant modifications to the binding, which I chose to not undertake at this time.

This PR also introduces a slight change to the process to retrieve favorites from the LMS. Currently, there's a slight race condition where it's possible for the bridge to send the favorites to the player handlers before the player handlers have completed initialization. This change simply adds a slight delay to the retrieval of the favorites from the LMS.

This PR also changes the binding to use constructor injection.

I considered adding null annotations, but decided to save that for another PR as the changes looked pretty significant.

Signed-off-by: Mark Hilbush mark@hilbush.com

[cpmeister]

It isn't really clear to me from the code, but do you update the like/unlike channels whenever a new song or track is played? Or are the like/unlike channels write-only?

[mhilbush]

It isn't really clear to me from the code, but do you update the like/unlike channels whenever a new song or track is played? Or are the like/unlike channels write-only?

Whenever a new song/track is played, the binding queries the LMS in order to update the like/unlike commands. These are the commands that need to be sent to the LMS in order to like/unlike a song. The commands depend on the streaming service being used (e.g. Pandora is "pandora rate 1" and slacker is "slacker rate F"), which is why they need to be updated on each new song. It does this in SqueezeBoxServerHandler::handlePlaylistMessage. The like/unlike channels are write-only.

[mhilbush]

@cpmeister Thanks for your review!

I've responded to all your comments, and pushed a commit with the changes. Just one question above for which I'm looking for guidance.

[cweitkamp]

The like/unlike channels are write-only.

In that case - when these channels do not have a state - you might want to use a DynamicCommandDescriptionProvider / BaseDynamicCommandDescriptionProvider to populate their command options.

[mhilbush]

I could do that. But, as there are a couple other existing Switch channels that also accept just ON (i.e. next, prev, and unsync, should I also do the same thing with those channels in order to maintain consistency? If so, would that be considered a breaking change for those existing channels? I've not used the dynamic command description provider before, so I'd benefit from your perspective.

Example of existing channel next.
https://github.com/openhab/openhab-addons/blob/2.5.x/bundles/org.openhab.binding.squeezebox/src/main/java/org/openhab/binding/squeezebox/internal/handler/SqueezeBoxPlayerHandler.java#L221

[TravisBuddy]

Travis tests were successful

Hey @mhilbush,
we found no major flaws with your code. Still you might want to look at this logfile, as we usually suggest some optional improvements.

[cweitkamp]

I would not touch existing channels. Only new ones. Additionally I am not convinced if it makes sense to use a dynamic command description for other item types than Number or String.

[mhilbush]

So, then I'm not sure what's to be gained by changing this. I'd need to change the channel type (breaking existing people using the new feature), and rework the code. I'm just not sure of the value in doing that in this case.

[cweitkamp]

I don't want to push you to use it. I want to promote the feature. It was a suggestion. Up to you.

But let me quote from the JavaDoc of CommandOption:

• Represents a command option for "write only" command channels. CommandOptions will be rendered as push-buttons in the
• UI and will not represent a state.

Isn't that exactly what you want to achieve in the end. Let me correct my previous statement: I am personally not convinced... You can use it with every item type. There're no restrictions inside the framework.

breaking existing people using the new feature

I don't think we have to discuss this right now. They're using it on their own risk as long as this PR remains unmerged. Don't get me wrong. I neither want to tease you nor them.

[mhilbush]

I want to promote the feature.

I understand completely. Just trying to sort out the value in this case.

Isn't that exactly what you want to achieve in the end.

Yes, it is exactly what I want to acheive.

You can use it with every item type.

That's interesting. So I might be able to leave the channel as a Switch. As an aside, the documentation says it only works with a String.

I don't think we have to discuss this right now. They're using it on their own risk as long as this PR remains unmerged. Don't get me wrong. I neither want to tease you nor them.

C'mon, man. Sure you do. 😉

I'll prototype it to get an idea how it works. Now that the PR missed the 2.5.5 release, I have plenty of time. 😃

[mhilbush]

@cweitkamp Here's what I've done so far.

I've created a new channel called rate. The rate channel can have no command options, a like command option, an unlike command option, or both like and unlike command options depending on how the music source supports (or doesn't support) rating.

I defined the rate channel as a String.

	<channel-type id="rate">
		<item-type>String</item-type>
		<label>Rate Song</label>
		<description>Likes or unlikes the current song (if the service supports it)</description>
	</channel-type>

In the sitemap I put this.

	Frame label="Rate the Song" {
		Switch item=Source1_Rate label="Rate Song []"
	}

All good so far. But I've run into some issues.

• When the command options are changed the UI doesn't update. You need to do a page refresh to pick up the change.

• Some sources (such as local music, Internet radio, etc.) do not support rating. In that case, when there are no command options set (passing an empty list to setCommandOptions), the UI renders the switch widget. This is confusing. Ideally, if there are no command options set, it shouldn't render anything IMO.

• I haven't figured out how to do command options in HABpanel.

[cweitkamp]

Very much appreciated that you gave it a try.

When the command options are changed the UI doesn't update. You need to do a page refresh to pick up the change.

Hm, I have the slight feeling we have the same problem with dynamic state descriptions too. Time to open an issue in OHC. A possible solution could be a new event emitted via OH event bus. UIs have to refresh their elements on state description or command option changes. This will not make it into OH2.5.x anymore.

the UI renders the switch widget. This is confusing. Ideally, if there are no command options set,

For this there maybe several possibilities.

• Use Default element in your sitemap. I submitted a proposal for its handling ([ui] Switch widget as default widget for Number or String items with command options openhab-core#1422).
• Set null instead of an empty list. We might want to add an unsetCommandOption method to the BaseDynamicCommandDescriptionProvider.
• Fine tune the handling in the UI(s)

HABpanel

So not ask me something about HABpanel. I am not familiar with it 😉. Rather ping @ghys and find a solution for the new UI.

[mhilbush]

I really like the idea of a single channel with command options that can be adjusted as necessary. That model really does fit what I'm trying to do. However, given the issues I mention above (especially the HABpanel issue), I think I'd prefer to stick with the current implementation.

Hm, I have the slight feeling we have the same problem with dynamic state descriptions too.

I think you're right.

when there are no command options set (passing an empty list to setCommandOptions), the UI renders the switch widget

In Basic UI, it appears to use switch if there are no command options. I'm not sure I understand the rationale for doing this when we're talking about an item of type String.

https://github.com/openhab/openhab-webui/blob/937cf2456cc6a8b1dcb86af9a9d9ede7166d774b/bundles/org.openhab.ui.basic/src/main/java/org/openhab/ui/basic/internal/render/SwitchRenderer.java#L96

Use Default element in your sitemap.

Currently, Default results in a selection list, which is not nearly as desirable as buttons.

Set null instead of an empty list.

The command options list argument to setCommandOptions currently is defined as @NonNull.

We might want to add an unsetCommandOption method to the BaseDynamicCommandDescriptionProvider

I think that will result in the same behavior given the above implementation in Basic UI.

[mhilbush]

@openhab/add-ons-maintainers I'd like to get this PR back onto someone's radar screen. It seems to have fallen through the cracks. Thanks!

[cpmeister]

@mhilbush
I put the PR on the back-burner since I thought this wasn't going to get merged into 2.5.x. Is that not the case? I can review this again if you want it to be merged into 2.5.x.

[mhilbush]

Sorry if I left the impression this was for 3.0. I would like it included in 2.5.x

[cweitkamp]

I am afraid this confusion results due to my questioning. Sry.

FTR: I am already working on a scratch for a ChannelCommandDescriptionChangedEvent / ChannelStateDesciptionChangedEvent implementation for OH3.

[TravisBuddy]

Travis tests were successful

Hey @mhilbush,
we found no major flaws with your code. Still you might want to look at this logfile, as we usually suggest some optional improvements.

[mhilbush]

@cpmeister I've pushed an update the addresses your remaining comments. Please let me know if there's anything further that needs to be changed.

[TravisBuddy]

Travis tests were successful

Hey @mhilbush,
we found no major flaws with your code. Still you might want to look at this logfile, as we usually suggest some optional improvements.

[mhilbush]

I've resolved the merge conflicts. Is there anything else I need to do before this can be merged?

[mhilbush]

Ugh. Missed another release cycle. Some day, I suppose...

[mhilbush]

Anyone? Bueller? Bueller?

[mhilbush]

Must be Ferris's day off... 🙁 😉

@openhab/add-ons-maintainers Coming up on 2.5 months for this PR.

[Hilbrand]

LGTM

[mhilbush]

Thanks @Hilbrand

[mhilbush]

@cpmeister Thanks for the additional review. I've addressed your feedback. Let me know if ok.

[TravisBuddy]

Travis tests were successful

Hey @mhilbush,
we found no major flaws with your code. Still you might want to look at this logfile, as we usually suggest some optional improvements.

[mhilbush]

@cpmeister