search

i8beef / node-red-contrib-castv2

MIT License
22 stars 14 forks source link

Allow next & prev for devices supporting all basic media commands #37

Closed barshociaj closed 3 years ago

barshociaj commented 3 years ago

I haven't found any documentation that confirms exactly what "mandatory commands" are but ALL_BASIC_MEDIA seems to include previous and next commands. My receivers publish supportedMediaCommands as 274447, which does not include 64, however the commands do work.

i8beef commented 3 years ago

Based on this: https://developers.google.com/cast/docs/reference/web_receiver/cast.framework.messages

I don't think this is right. If anything these should be added to PAUSE, SEEK, STREAM_VOLUME, STREAM_MUTE. EDIT_TRACKS, PLAYBACK_RATE as indicated by the Google docs...

Its interesting to note that the bitmask returned contains 16 and 32, which are SKIP_PREV and SKIP_NEXT, but from what I can tell those are deprecated? There's some interesting examples on on Google's docs (https://developers.google.com/cast/docs/web_receiver/customize_ui) about what controls should be available based on these command bitflags... when casting to this device do you get the prev / next buttons on your cast controls on your phone?

barshociaj commented 3 years ago

@i8beef, thank you, based on the second reference it indeed seems that ALL_BASIC_MEDIA is not supposed to include prev/next. The UI of the Nest Hub Max where I stream to (cast firmware 1.50.229764; sw version 30.21.47.332161281) also adheres to the spec and does not show the prev / next buttons. Yet, the commands do work.

The bug could then be in the cast version that internally supports the commands, but publishes wrong bitmask.

I still need this to work. An alternative can be either allowing to pass the commands through even if unsupported and catch a potential error - or - since you're doing the right thing - no problem for me to keep the change in my fork only and use that.

i8beef commented 3 years ago

So after consideration, I'm going to decline this PR... Google's docs on this are fairly straightforward unfortunately, and since their own cast controls do the same thing, I really think I should follow that.

The ALL_BASIC_MEDIA value is actually already the equivalent bitmask value of the contained commands, so no change is necessary to support that as a distinct value.

Out of curiosity which receiver are you trying this on? I mean a DefaultMediaReceiver cast with a single media file isn't going to have the queue semantics since it is playing a single item, and while it will SUPPORT queue loading through this node, Im not sure I've ever played with the queue management aspects. If its another app you're trying to control, I'm just curious which app that is.

barshociaj commented 3 years ago

No problem, makes sense.

I'm using DefaultMediaReceiver with payload containing an array of media - casting audio from my server to Google Home. Any other suggestions, pls. let me know.

i8beef commented 3 years ago

Hm, yeah, the DefaultMediaReceiver doesn't change its supportedMediaCommands setting even though it has a queue loaded up ok. From some of the open items in the Google bug tracker, it looks like it might be a known issue in the DefaultMediaReceiver that Google has had little interest in fixing in two years. https://issuetracker.google.com/issues/72220745

I wouldn't hold your breath unfortunately. Once Google looses interest its usually a bad sign anything will ever be done about it.