Node-red-contrib-castv2 3.0 release

[i8beef]

Note: This node has no relation to node-red-contrib-cast

I released a 3.x version of the node-red-contrib-castv2 node this week, and figured I'd post this here for anyone with questions when they upgrade it and find their nodes broken.

Connection management has been completely reworked. The node now exposes a configuration node for connections.

THIS WILL BREAK YOUR CURRENT NODES. To fix, just edit the node, and setup the connection again. host and port are no longer settable on the incoming message, since its now a long lived, configured connection instead.

This allows for the following

1. Connections are now shared between node instances instead of each node opening and closing connections on every request.
2. Connections are now long lived, which allows the node to subscribe to and publish live updates from the cast device, i.e., it's now viable to actually respond to unsolicited state changes on the cast device.
3. Nodes will automatically join active sessions launched from other nodes, phones, etc. to start subscribing to events, etc., you shouldn't have to do anything
4. You can now send in a message, sans-app name (see docs) for any supported app's active session, to control media commands without it causing the cast app to close, restart, etc. That is, if YouTube is currently playing on the cast device, and you send in a media "STOP" command, the node will attempt to send that to the active YouTube session.

The entire node has basically been overhauled architecturally to allow for controlling more than just the DefaultMediaReceiver on the cast devices. The node can still only control platform and media events for applications it actually SUPPORTS, but now people asking for it to be able to control app X can submit PR's to ADD such support!

Out of the box, it now supports DefaultMediaReceiver (default), YouTube, and has a (basically currently useless) Spotify implementation that I'd love someone with an actual Spotify account to expand (see ticket on the Github).

Any issues, please feel free to ask on the github issues.

Note: The cast API is rather chatty on published updates, e.g., when playing media it actually spits out a message or two every second to reflect media state (i.e., current timestamp on the current media). Near as I can tell this is expected behavior, but keep it in mind that if you start using the output of this node you might get more messages than you're expecting.

[i8beef]

One other caveat: You might notice a warning about EventEmitter memory leaks pop up in your log. I HAVE looked at this, and all of the events in my code are NOT oversubscribed, and I traced this back to pieces inside the castv2 / castv2-client library itself. Thus far, I have not been able to prove a LEAK in their implementation, but I'm still looking into it. For now, it shouldn't cause any issues, but I do have an open item on the Github page to continue investigation.

If you run into any issues caused by this, please do add to that ticket.

[i8beef]

Release 3.0.7. Several important bug fixes.

1. There WERE some EventEmitter leaks in the base library client. Luckily in areas I could just copy and fix as I think the upstream devs are MIA.
2. I actually did have some issues in my lifetime management and a race condition that was instantiating more receivers than it needed, and promptly orphaning one on every command. Corrects this lifetime management.
3. An EventEmitter deep in the call stack acts as a message bus for a lot of areas of the client. Its easy for this to surpass the default limit of 10 event subscriptions with multiple nodes subscribed to the same connection. (3 for the underlying connection + 2 per node, means using 4 nodes on the same connection would immediately hit this). I've upped this to 50 for that emitter.

Recommend updating to at least this version.