Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Striker]

MCWS Feature Request – expand Playback/Info?Field for the Next Track

http://127.0.0.1:52199/MCWS/v1/Playback/Info?Fields=Artist,Album,Name,Genre

to allow the retrieval of the fields for the next track.

http://127.0.0.1:52199/MCWS/v1/Playback/Info?Fields=Artist,Album,Name,Genre,next.Artist, next.Album …

I am currently using the deprecated “PlayingNow” plugin to write out the current/next track info to a file and to call a program I wrote on track change.  I'd need to be able to request user fields too (not sure if that is currently allowed).

I’d like to give up my use of the “PlayingNow” plugin so I can use the 64 bit version of MediaCenter.

I know I can get the NextFileKey and then call:

http://localhost:52199/MCWS/v1/File/GetInfo?File=99999&Action=json

to get info about the next track.

That’s two calls to MCWS and it would be great to only have one call since I’ll be polling MC every second to keep my MC info updated. 

I currently can’t use the Playback/Info?Fields= or any update you make for this request since I’m still running v30.  Of course if JRiver makes this change, I will of course have to purchase the v32 update.

[Hendrik]

This doesn't really seem to fit the design of such a call. A request should fit the scope of the information you are requesting, it really gets muddled if it can return mixed information about different files.
I don't think making one more MCWS call is a huge burden on the system here - afterall you effectively only need to do it once for every file, or at least only one call, and skip the second if the next file didnt change.

[Striker]

This doesn't really seem to fit the design of such a call. A request should fit the scope of the information you are requesting, it really gets muddled if it can return mixed information about different files.
I don't think making one more MCWS call is a huge burden on the system here - afterall you effectively only need to do it once for every file, or at least only one call, and skip the second if the next file didnt change.

Thank you for reading my request.

I will still have to do the first MCWS Playback/Info?Fields call every second to know if the info has changed and to check if the playback status changed.  Yes if the next key did not change I wouldn't have to do the 2nd call.

Still I'm struggling with giving up the "PlayingNow" plugin and would like to minimize MCWS calls (using curl).

My code would first check if the MediaCenter process is active and if active then do the MCWS calls.

(calling Playback/Info?Fields with MediaCenter not running has a long [computer-time] delay before returning an error)

I hope as you think about this more that you may change your mind.  Thanks for reading.

This is an example of what I have the "PlayingNow" plugin write out on track change.

[PLAYING_NOW]
DURATION="6:30"
TRACK="8"
ARTIST="Blues Company"
ALBUM="1991 Damn Let's Jam"
SONG="Comin' Home, Baby"
PLAYCOUNT="35"
GENRE="Blues"
GENRE_ALL=" Blues "
YEAR="1991"
NEXT_ARTIST=" Blues Company "
NEXT_ALBUM=" 1991 Damn Let's Jam "
NEXT_SONG=" Move On Down The Line "
NEXT_RATING=" 3 "
RATING="3"
QUALITY=3
LASTPLAYED="2023-09-14 13:11"
DATEIMPORTED=" 2008-11-16 17:10 "
SOURCE="flac"
FILETYPE=" flac "
[END]

[Striker]

Or maybe a MediaCenter option to call a user program on track or state change?

That would eliminate any need for polling using MCWS.

I'd only need to call MCWS when MediaCenter triggered my program on a track or state change.

[Striker]

Feature Request - MC option to call a user program on track or state change

This would work great for me... I currently gather information about the current/next track using the deprecated "PlayingNow" plugin.  I've configured the PlayingNow plugin to write info about any track change to a file and to call a program on track change to read that file and update my HomeAutomation screens around my house.

I suspect many MC users would find a use for an MC option to call a user program on track/state change.

If MediaCenter itself would call a user program on track/state change, that would eliminate my need for the "PlayingNow" plugin.  When MC runs my program it would do the MCWS calls to get the current/next track info and state, eliminating any need for 1 second polling using MCWS.

I'm really working hard to find an alternative to using the 32 bit deprecated "PlayingNow" plugin.

[Hendrik]

I will still have to do the first MCWS Playback/Info?Fields call every second to know if the info has changed and to check if the playback status changed.  Yes if the next key did not change I wouldn't have to do the 2nd call.

Indeed, however the request in question in this thread would not actually impact this at all. You will still need to continue to do so. But caching and checking NextFileKey should alleviate any concerns about additional calls, as you need to do one per track change, which is one in several minutes in normal operation.

Polling Playback/Info or similar calls is how any remote controls or remote displays work, and while not "perfect", it has shown to work just fine for several use-cases. Media Center is not currently setup to really "push" information in a generic manner, or run an external program. These things would have to be done very carefully as to not impact playback. And running a local program also doesn't really solve the issue for anyone wanting to receive such events remotely.

[Striker]

Indeed, however the request in question in this thread would not actually impact this at all. You will still need to continue to do so. But caching and checking NextFileKey should alleviate any concerns about additional calls, as you need to do one per track change, which is one in several minutes in normal operation.

Polling Playback/Info or similar calls is how any remote controls or remote displays work, and while not "perfect", it has shown to work just fine for several use-cases. Media Center is not currently setup to really "push" information in a generic manner, or run an external program. These things would have to be done very carefully as to not impact playback. And running a local program also doesn't really solve the issue for anyone wanting to receive such events remotely.

Thank you for the reply.

While I know it's done, and I've done it more often than I like, I always try to find an event driven solution rather than polling.

If MC were to run a user program... I would think MC would run it as a totally disconnected background process.  Any issues with that program running or causing problems with MediaCenter would of course be the user problem.

I bought the "PlayingNow" plugin in 2007 and it, running within MediaCenter has successfully been calling my user configured program on track change since 2007 without issue.

[zybex]

Feature Request - MC option to call a user program on track or state change

+1

Either that or some kind of event broadcast system that could be picked up by an external app.

[mattkhan]

a full featured push api (websocket would sit alongside mcws neatly) would be great

a minimal version could provide the equivalent of MCWS/v1/Playback/Info in ws form

e.g.

client sends subscribe message containing optional list of fields
server replies with current state (i.e. equivalent to calling Playback/Info)
server sends an update whenever the value in any of those fields changes (coalescing multiple changes into a single message + throttled to some reasonable interval like 250ms)

[JimH]

While I know it's done, and I've done it more often than I like, I always try to find an event driven solution rather than polling.

Is there a reason for this?  While polling may be more "expensive", I can't imagine that it has a significant impact on performance.  Modern computers are capable of lots of simultaneous computing tasks without breaking a sweat.

Any evidence to the contrary?

[lepa]

this would be great

[mattkhan]

It's wasteful and inefficient in every way (Inc power consumption), requires you to poll frequently for a responsible user interface and fills the MC logs with irrelevant cruft. Certainly it works but it's never ideal.

[zybex]

Simplest would be to broadcast a system message with the MCC notification codes when those events occur:
https://wiki.jriver.com/index.php/Media_Center_Core_Commands#Notifications

The code for this is a single line on Windows:
SendNotifyMessage(0xFFFF, WMsg, MCCCode, MCCParam);

Where WMsg can be any value, but it's best to register one at startup with:
MyWMsgCode = RegisterWindowMessage("JRiver");

Then any app that wants to receive those messages can find out the code by calling the same function and handle the notifications any way it needs. Any additional needed info would come from MCWS calls. A simple app could then listen for these and execute commands or write the current playback info to a file, according to user configuration.

These APIs are Windows-specific. For Mac/Linux, a different solution would be needed, but I think that using those Notification events makes sense. Alternative multi-platform solution is to provide a socket that client-apps can connect to receive those event codes.

[zybex]

These threads should be combined:
https://yabb.jriver.com/interact/index.php/topic,138176.0.html

Polling is awful and misses events.

[mattkhan]

Probably pointless to discuss unless any interest is shown but I will say that a windows specific thing sounds very bad to me, making you make an mcws to get info also, to my mind, largely defeats the point.

[Hendrik]

A websocket kind of solution would be the most likely, as it's both cross-platform and supports remote use, as well as having a cleanly defined interface at least for the low-level part of it.

The points against any other options have been made, but to summarize:
- Executing a program is local only and very limited in usability
- Windows messages are local and OS-specific, also limited in information conveyance

We actually had a system-wide broadcast message system on Windows years ago, similar to what zybex mentioned, but it was unused and undocumented (and actually broken accidentally without being noticed for a few years, before we removed it), and sending the messages caused hiccups in time-sensitive applications, like gaming while playing music, for unknown reasons, not going back to that.

We use our own networking primitives, so setting up a websocket would be a good chunk of effort to get going, since we haven't done that before, but its still the most reasonable thing to do, but it likely won't be showing up in the very near-term.
Luckily the basic WebSocket protocol doesn't seem overly complicated. If we define it in typical MCWS XML, or perhaps JSON because thats easier for remotes, it might not end up too bad.

[zybex]

Probably pointless to discuss unless any interest is shown but I will say that a windows specific thing sounds very bad to me, making you make an mcws to get info also, to my mind, largely defeats the point.

Agree on the windows-specific issue, but completely disagree on the other. Calling MCWS on a local network takes milliseconds. Having some hardwired data structure on the notification event is a recipe for constant change-requests for more info or other changes. All an external app needs is to know *something* happened, then it can get more info about the event to display or execute whatever it needs.

[Hendrik]

I don't think eliminating MCWS calls entirely would be a goal for us, but the ability to send any data at all beyond a single number parameter would add a lot of value.

[JimH]

I can't imagine that the power consumption is significantly different.  And logs _are_ cruft.  Write a reader with custom filters.

[mattkhan]

Agree on the windows-specific issue, but completely disagree on the other. Calling MCWS on a local network takes milliseconds. Having some hardwired data structure on the notification event is a recipe for constant change-requests for more info or other changes. All an external app needs is to know *something* happened, then it can get more info about the event to display or execute whatever it needs.

I didn't suggest a hard wired data structure, I suggested subscribing for changes to certain data so, by definition, that gives you changes to data you are interested in. "Something happened" notification is not completely useless but really not even half a job.

[mattkhan]

Adopting JSON would be nice also

[mattkhan]

I can't imagine that the power consumption is significantly different.  And logs _are_ cruft.

Unfortunately MC logs are prone to that problem, it certainly doesn't have to be that way though

[JimH]

We're not building the Sistine Chapel here.

[bob]

A websocket kind of solution would be the most likely, as it's both cross-platform and supports remote use, as well as having a cleanly defined interface at least for the low-level part of it.

The points against any other options have been made, but to summarize:
- Executing a program is local only and very limited in usability
- Windows messages are local and OS-specific, also limited in information conveyance

We actually had a system-wide broadcast message system on Windows years ago, similar to what zybex mentioned, but it was unused and undocumented (and actually broken accidentally without being noticed for a few years, before we removed it), and sending the messages caused hiccups in time-sensitive applications, like gaming while playing music, for unknown reasons, not going back to that.

We use our own networking primitives, so setting up a websocket would be a good chunk of effort to get going, since we haven't done that before, but its still the most reasonable thing to do, but it likely won't be showing up in the very near-term.
Luckily the basic WebSocket protocol doesn't seem overly complicated. If we define it in typical MCWS XML, or perhaps JSON because thats easier for remotes, it might not end up too bad.

Websockets are included in libcurl making that usable on linux, I'm not aware of there being websocket support in MacOS however we could likely change MacOS to use libcurl instead of the built in MacOS networking API.

[Hendrik]

Websockets are included in libcurl making that usable on linux, I'm not aware of there being websocket support in MacOS however we could likely change MacOS to use libcurl instead of the built in MacOS networking API.

libcurl is for clients, not servers. But the websocket protocol is pretty simple. It starts as a HTTP request and then upgrades into a simple binary protocol.
Handling it on top of the current HTTP server functionality would probably not be so bad, and just forward some meaningful notification events.

[Striker]

libcurl is for clients, not servers. But the websocket protocol is pretty simple. It starts as a HTTP request and then upgrades into a simple binary protocol.
Handling it on top of the current HTTP server functionality would probably not be so bad, and just forward some meaningful notification events.

Thank you for the consideration the discussion.

As of now, I know nothing of websockets.  I use the Cygwin gcc C++ compiler for my programs.

It feels like my request is turning into something for programming experts rather than intermediate users.  (I've been retired from my software job for 12 years now... I have forgot so much).

I'm not against any other MC additions like websockets.

But... for me the simplest solution would be to emulate the "PlayingNow" plugin feature where I can configure it to call a program on state/track change.  That would totally eliminate my need to stay on the 32bit version of MC and the "PlayingNow" plugin would no longer be needed.

Having MC call a user defined program would give unlimited flexibility for users to easily do what they want on track change with an easy to use method.  The program to be run could be a C++, Java, bat, shell, Python, etc, etc program and would work on all platforms.

That configured program could also do it's own notifications to any other systems that need to know about a track/state change.

Then I could purchase the update to v32 from v30 (to get the new feature) and get the 64bit version of MC.

[Striker]

All an external app needs is to know *something* happened, then it can get more info about the event to display or execute whatever it needs.

Exactly +1

[Hendrik]

A Python script to connect to the WebSocket and do whatever you like would probably be less then 20 lines, and we could even host an example on the wiki. That's the advantage of using standard technology - there is a library for that

It's just the far more versatile option, and avoids all concerns of running applications in MCs context.

[Striker]

A Python script to connect to the WebSocket and do whatever you like would probably be less then 20 lines, and we could even host an example on the wiki. That's the advantage of using standard technology - there is a library for that

It's just the far more versatile option, and avoids all concerns of running applications in MCs context.

If I understand this correctly, I'd need to write a python client that makes a websocket connection to MediaCenter listening for messages from MediaCenter.

For my simple needs, that is extra coding and running the listener client, and monitoring to make sure the client is running 24/7 and stopping restarting it every time I stop/restart MediaCenter.

The data processing of the new track/state change info is currently written in C++ and I wouldn't want to rewrite all of it in Python, so I'm likely end up calling my C++ program from the Python client.... not ideal.

Running a user configured program from MC is the simplest option for me and would require minimal programming change for me.

Currenty "PlayingNow" writes out the current/next tracking info I need to a file and then tells me a track changed by calling my configured program.  I'd need to just get the current/next track data using WSMC and then all of the rest of my code would work as written.

Running a configured program on track state/change would give many of us an unlimited easy method to get notified that "something" happened" and then we would handle that info using the knowledge we currently have.

The "PlayingNow" plugin I bought in 2007,. which is run by MediaCenter has been successfully calling my configured *program* on every track change since 2007.

** a bat file which calls the my exe program with the options it needs

While others may have other needs... I believe running a configured program on MC track/state change would be useful to many.

Please implement it, even if websockets are implemented too.

I'm really working hard to find a workable alternative to the "PlayingNow" plugin without major changes to my code.

[mattkhan]

If I understand this correctly, I'd need to write a python client that makes a websocket connection to MediaCenter listening for messages from MediaCenter.

you don't, you can use whatever language you want.

[Hendrik]

I can only offer you one solution to your request,  and that's one we could also use for a far wider set of use-cases, giving full control to anyone that wants it.

A WebSocket offers exactly the information you desire, does not require polling, is widely supported by networking libraries in every language, and has none of the short comings of the other proposals (because they are in fact not "unlimited")

I'm afraid multiple different approaches is not realistic. Even the one is not going to materialize over night.

[Striker]

Thank you for your time and consideration of my request.

I won't be using your proposed alternative, so please don't implement it for me, unless others want it.

[zybex]

I'm afraid multiple different approaches is not realistic. Even the one is not going to materialize over night.

Indeed, I needed the weekend 
https://yabb.jriver.com/interact/index.php/topic,138222.0.html

This is a windows-only solution, so it's not a solution. I think the websocket idea for all platforms is still the way forward.
This one does have a websocket, but I did minimal testing only.

[Hendrik]

Of course the old Windows COM Automation still exists, as well.

[Striker]

Indeed, I needed the weekend 
https://yabb.jriver.com/interact/index.php/topic,138222.0.html

This is a windows-only solution, so it's not a solution. I think the websocket idea for all platforms is still the way forward.
This one does have a websocket, but I did minimal testing only.

Thank You Sir !!!   I've got it and am playing with it now.

[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]

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.

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]

I could see that with many concurrent MCWS requests or with a large number of clients subscribing to push notifications from MC.

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.

[zybex]

That's exactly how MCMonitor does it.
However I think Hendrik was talking about an issue caused by broadcasting Windows Messages (WndProc messages)- those are quite 'stupid' and get sent to each and every window and control across the entire system, and any one of those can delay the call/queue enough to cause problems to other apps.

A websocket should not have the same problems as it's just sending packets over TCP.

[Hendrik]

Yeah, I was talking about window messages.

A websocket on its own thread with a message queue if needed should not impact the operation of MC itself. If you do extensive MCWS requests in response, maybe that can do something, but the notifications would be pretty standalone.