Youtube QUEUE_PREV and QUEUE_NEXT not workin

[soloam]

Hello, it looks like QUEUE_PREV and QUEUE_NEXT are not working on youtube, QUEUE_NEXT returns invalid command, and QUEUE_PREV does nothing! I tried with loading a movie and a playlist.

Also, the node status keeps showing "error" if a error couros, and does not return to green even after a good command!

Thank You

[i8beef]

So "supported" is a little bit of a misnomer here. DefaultMediaReceiver is the only fully implemented receiver. The others are there to enable standard media controls, like the ones that would show up in your notification drawer on a phone when something starts casting one of those apps (play, pause, stop, etc.). Technically, I think any of these apps can implement one of those differently, it just looks like YouTube probably does that differently so the standard media commands for those two commands aren't actually supported correctly.

That doesn't mean it can't be added of course, but I have no documentation or anything to start from with that. There are examples of YouTube cast control that I referenced to write the "load" functionality, but none of them appear to support the QUEUE_NEXT and QUEUE_PREV commands. If you find an implementation that actually figured out out to support those, I can take a look though.

As for the error reset, that's something I could probably do something with.

[i8beef]

Try 3.2.1 for the error reset. It should hold the error message status until you send a new command through, and then the node should reset itself to the correct status display now.

[soloam]

Try 3.2.1 for the error reset. It should hold the error message status until you send a new command through, and then the node should reset itself to the correct status display now.

That Worked! Tks

Also noticed that "{"type":"GET_CAST_STATUS"}" does not returns any error, but also does not returns any message!

Thank You for your help

[i8beef]

Conceptually, those two commands kind of got the axe with the redesign. It used to return the response from any given command, but it hasn't done that since the redesign in favor of the announced status changes from the cast connection... I'll look into returning those status responses still instead, but I gotta check if that's going to look like multiple messages being published or not.

[i8beef]

I just pushed another version that should support outputting on GET_STATUS and GET_CAST_STATUS again. As a side effect, any status returned from OTHER commands should also be output now, which I might look at limiting down to JUST these commands in the future. Try it out and see what you think.

[i8beef]

I pushed another version. Soliciting status information by GET_STATUS, GET_CAST_STATUS, and GET_VOLUME are the only commands that will cause the node to output the appropriate status message now. It got a little weird when it was spitting out status responses from ANY command, so I limited it to those as they are the only real "request/response" type commands.

Also, I fixed an issue where a GET_STATUS when a RECEIVER app is RUNNING, but not PLAYING anything wouldn't return anything. It will now return an explicit msg with NULL payload now in this case... just a note it will ALSO return a msg with a NULL payload if NO receiver is currently running... I'm not sure if that edge case will bite at some point, but for now, it should be ok, you just can't tell the difference between "receiver running but idle" and "no receiver app running" from this... but it also let me fix an issue where it would LAUNCH a receiver app, but basically do nothing since no media was loaded first, and I thought returning a NULL here was better than throwing an error about "no receiver app running" for GET_STATUS specifically.

[soloam]

Thank you for all your hard work on this! At the time I'm out on vacations! But as soon as I get back home I'll test it out!

Thank you

[ChillXXL]

I noticed with the new 3.2.3 release when I send a message like play/pause to a not active chromecast it no longer bumps a 'DUNG' error-sound on the specific device while opening the launcher with no input and then stops. It now only outputs a msg error back ("Error: No active receiver application") to Node Red and the device stays in the same state (like spotify-app open), which is a great improvement :-)

I can now send commands (play/pause/next track/etc.) to all chromecasts and only the active one will pick it up (rest outputs the error which is obvious) without any Node Red switching outputs to different chromecast nodes etc. Thanks!

Btw: GET_VOLUME outputs the same output as GET_CAST_STATUS which probably is not correct.

[i8beef]

Yes, correct. I had a piece in there that would always assume a receiver app was running, and if it wasn't, would first attempt to launch it which. Unfortunately, media control commands require an active playing media item to work, so in those cases it was launching just to immediately throw an error about not being able to run the command. I've limited this to just the "app" commands now like MEDIA and TTS, and media control commands will now just throw an error instead if there's no active RECEIVER.

GET_VOLUME outputting the same as GET_CAST_STATUS was a choice. GET_VOLUME would just output the same thing anyway basically, and I wanted to cut down how many different shapes of messages could be sent out from the node, so I decided it would just return the more complete, and more useful, GET_CAST_STATUS output.

[i8beef]

Closing as fixed, reopen if I missed something here...