More > JRiver Media Center 32 for Windows
MCWS Feature Request - Notifications on state change
eve:
Chiming in.
The right way to do this for JRiver is a Websocket. You could do MQTT or something but making this a websocket (that ideally spits out json not XML) is by far the most flexible approach and allows anyone / anything to integrate with it.
The only concern I have is websocket communication causing the problem described by Hendrik
"sending the messages caused hiccups in time-sensitive applications, like gaming while playing music, for unknown reasons, not going back to that."
I've had JRiver get a weird momentary 'stutter' when overwhelmed with MCWS requests (purely Playing Now type requests, nothing to change state or request other views). Would absolutely prefer this 'not' be a thing.
Striker:
--- Quote from: eve on February 19, 2024, 01:11:40 pm ---Chiming in.
The right way to do this for JRiver is a Websocket. You could do MQTT or something but making this a websocket (that ideally spits out json not XML) is by far the most flexible approach and allows anyone / anything to integrate with it.
The only concern I have is websocket communication causing the problem described by Hendrik
"sending the messages caused hiccups in time-sensitive applications, like gaming while playing music, for unknown reasons, not going back to that."
I've had JRiver get a weird momentary 'stutter' when overwhelmed with MCWS requests (purely Playing Now type requests, nothing to change state or request other views). Would absolutely prefer this 'not' be a thing.
--- End quote ---
I could see that with many concurrent MCWS requests or with a large number of clients subscribing to push notifications from MC.
That is one of the reasons I simply wanted MC to call a configured program (in the background) on state change, which could then do whatever it wanted outside of MC.
zybex:
@Hendrik, I thought MC would fire an Event for most of the notifications in this list, but I see only NOTIFY_TRACK_CHANGE, NOTIFY_PLAYERSTATE_CHANGE and NOTIFY_VOLUME_CHANGED, which aren't even on that list. Is that expected?
These are enough for most purposes, just asking.
One that might need fixing - there's no event fired when the user closes MC while music is playing.
Hendrik:
The commands that fire are filtered for relevance, the notify events include a lot that are for internal use only to update views etc.
eve:
--- Quote from: Striker on February 19, 2024, 01:21:25 pm ---I could see that with many concurrent MCWS requests or with a large number of clients subscribing to push notifications from MC.
--- End quote ---
Well like the way you'd handle that is a small server application that acts as the only websocket consumer for a JRiver instance and 'forwards' the information from each instance to as many clients however you see fit.
For example, you could push it all out into a redis stream or another websocket or whatever. A client should never directly connect to the media player, it should go through a thin 'interface' anyways. This way when JRiver changes something you can change just the server, not anything that depends on it.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version