i8beef / node-red-contrib-castv2

MIT License
22 stars 14 forks source link

GET_STATUS not working? #95

Closed FrankX0 closed 10 months ago

FrankX0 commented 10 months ago

When I execute GET_STATUS, I get only following response: {"type":"GET_STATUS","app":"DefaultMediaReceiver"} BTW: GET_CAST_STATUS returns the same. I would expect an object with the information like received when e.g. connecting, pausing, etc.: {"mediaSessionId":1,"playbackRate":1,"playerState":"PLAYING","currentTime":387.218629,"supportedMediaCommands":12303,...

In addition, the level key in the volume key is always 1, and the muted key is always false. Note: in node-red-contrib-cast volume and muted are returned correctly, with volume being a value between 0 and 1. Hope this helps.

i8beef commented 10 months ago

So this is a little confusing, and there is a bug here that needs fixed for consistency which makes it harder to grasp too...

There are TWO status's in play here: the DEVICE and the APP.

  1. When the APP status changes / is solicited by a GET_STATUS, it will send a msg with the payload published on msg.payload... or at least it does when status changes are sent, but solicited GET_STATUS is currently returning this on msg.platform. That's a bug, this should be outputting on msg.payload here, and I'll make this a bug to take care of here.
  2. When the DEVICE status changes / is solicited by a GET_CAST_STATUS, it will send a msg with the payload published on msg.platform. This should be consistent.

The payload you are seeing when you send a msg in is just the original one you are sending in with "defaults" like "app" laid over it. Also of note, GET_STATUS, if no app is actually running currently, will return null explicitly, while GET_CAST_STATUS should always return something.

The volume issue is a little more interesting... The "app" status is technically PER APP. Volume on this isn't guarantied to represent device volume, and that's what I THINK is happening... its showing you APP volume/mute (always 100% and umuted), not DEVICE volume/mute. Im assuming this is to support other apps like Spotify, etc. that might have their own "app volumes", even though DefaultMediaReceiver doesn't have such a thing? I don't know thats just an odd part of the cast spec for it.

Long story short, msg.platform.volume is probably the only one that actually is meaningful.

One additional added concern regarding msg.platform, on a status update from the cast device, the "last known value" of platform status isn't plugged into msg.platform, you JUST get msg.payload there... but theoretically I have the cached info for platform status to always shove that on there... I might do that for consistency too.

i8beef commented 10 months ago

4.3.0 (just pushed) should make this a little more consistent. msg.platform should ALWAYS output now instead of only on certain events, and thus you should be able to rely on that across use cases.

FrankX0 commented 10 months ago

Perfect! Thank you so much for your effort!