Topic: MCMonitor: Detect MC track change events, run commands (Read 3536 times)

zybex · « **on:** February 19, 2024, 11:19:43 am »

Hi all,

MCMonitor is a Windows-only mini-tool that listens to MC Events such as Track start/stop/pause and Volume change, and performs user-defined actions such as running custom commands, write the track data to a JSON file, or send the information to a WebSocket to be picked up by another tool.

This is a quick and dirty fix for the issue described here:
https://yabb.jriver.com/interact/index.php/topic,138174.0.html

Code and download: https://github.com/zybexXL/MCMonitor

Reading the config file comments is a good way to get an idea of what it can do.

Striker · « **Reply #1 on:** February 19, 2024, 12:46:02 pm »

Quote from: zybex on February 19, 2024, 11:19:43 am

Hi all,

MCMonitor is a Windows-only mini-tool that listens to MC Events such as Track start/stop/pause and Volume change, and performs user-defined actions such as running custom commands, write the track data to a JSON file, or send the information to a WebSocket to be picked up by another tool.

This is a quick and dirty fix for the issue described here:
https://yabb.jriver.com/interact/index.php/topic,138174.0.html

Code and download: https://github.com/zybexXL/MCMonitor

Thank You Sir. I'm playing with it now.

Striker · « **Reply #2 on:** February 19, 2024, 03:19:13 pm »

Amazing Work... very complete.

One thing that would help me out would be to include the prior PlaybackInfo, CurrentFile and NextFile populated even on a DISCONNECTED event in the json file. Those sections would still be valid on the next MediaCenter startup.

I know I can keep X number of events in the json file where I could get that prior info from if needed.

I have 12 screens around my home with House info from my HomeAutomation system along with MediaCenter info. Even when my audio system is off and/or MediaCenter is not running, I still show the current/next track info along with icons showing the state of my audio system power and if the MediaCenter process is active.

Thanks Again

Quote

{
"EventCounter": 7,
"Timestamp": "2024-02-19T14:00:22",
"Source": 1,
"Type": "MCMonitor",
"Arg1": "DISCONNECTED",
"Arg2": null,
"PlaybackInfo": {},
"CurrentFile": {},
"NextFile": {}
},

zybex · « **Reply #3 on:** February 19, 2024, 05:09:59 pm »

I can do that, but I can think of a few drawbacks:
- the info will be stale, potentially by many hours
- the displays are likely already up to date from the previous messages anyway
- MCMonitor will also issue a DISCONNECTED event at startup if MC is not running. In that case, it's not possible to get the info.
- When you close MC it currently doesn't send any event, so you may get a DISCONNECTED while PLAYING... this means the displays will say Playing even though it's not. I think that would need to be fixed on MC side.

In short, I think you shouldn't rely on the Disconnected event info.

Quote

I have 12 screens around my home with House info from my HomeAutomation system along with MediaCenter info. Even when my audio system is off and/or MediaCenter is not running, I still show the current/next track info along with icons showing the state of my audio system power and if the MediaCenter process is active.

Nice setup! I too, wish for a house that needs 12 screens.

Striker · « **Reply #4 on:** February 19, 2024, 05:40:27 pm »

Quote from: zybex on February 19, 2024, 05:09:59 pm

I can do that, but I can think of a few drawbacks:
- the info will be stale, potentially by many hours
- the displays are likely already up to date from the previous messages anyway
- MCMonitor will also issue a DISCONNECTED event at startup if MC is not running. In that case, it's not possible to get the info.
- When you close MC it currently doesn't send any event, so you may get a DISCONNECTED while PLAYING... this means the displays will say Playing even though it's not. I think that would need to be fixed on MC side.

In short, I think you shouldn't rely on the Disconnected event info.

Okay, I agree. I'll cache the old data for when not available from McMonitor.

eve · « **Reply #5 on:** February 19, 2024, 05:51:52 pm »

Quote from: Striker on February 19, 2024, 03:19:13 pm

Amazing Work... very complete.

One thing that would help me out would be to include the prior PlaybackInfo, CurrentFile and NextFile populated even on a DISCONNECTED event in the json file. Those sections would still be valid on the next MediaCenter startup.

I know I can keep X number of events in the json file where I could get that prior info from if needed.

I have 12 screens around my home with House info from my HomeAutomation system along with MediaCenter info. Even when my audio system is off and/or MediaCenter is not running, I still show the current/next track info along with icons showing the state of my audio system power and if the MediaCenter process is active.

Thanks Again

This is essentially another reason I did the thing I did with a small server. The 'prior' state is important to have outside of MC, not dependant on an individual MC instance. So this is a good idea. I don't like the idea of a client device 'maintaining' its own state, if for example the device restarts, it should just go pull it's information from a server, even if that data is stale, it's assumedly the last state of the jriver instance and you'd want to display that. I do a lot of web ui's so ensuring that they're essentially only for displaying information, and sending commands (relying on an external 'source of truth' for the information they display and receive, as well as alot of state) is important. Clients can cache whatever they want but they should ALWAYS have an external source of truth they can reference on demand IMO.

zybex · « **Reply #6 on:** February 20, 2024, 08:46:43 am »

Published MCMonitor v1.0.2 with some small fixes and incorporating Striker's feedback:

- Always add PlaybackInfo to JSON event output (current or last available one)
- Add InfoTimestamp field to indicate stale data
- Add Status field with decoded enum value - Playing/Stopped/Paused/Waiting/Unknown
- Allow dragging the status Form
- Better hide the Form at startup, was still showing on ALT+Tab

The "InfoTimestamp" should always match the "Timestamp" field. If it doesn't it means the info is stale, from a previous request. This should happen only when MC is closed, on the DISCONNECTED event.

Note the possible breaking change to your code - the JSON now outputs null instead of { } when the data is not available or not enabled in the config:
"PlaybackInfo": null,
"CurrentFile": null,
"NextFile": null,

Source is now also a string instead of number ("MCMonitor"/"MCEvent").

bob · « **Reply #7 on:** February 20, 2024, 10:39:28 am »

Is this peeking messages on the windows message loop?
I bet the same thing could be done on linux (X message loop is global).
Probably not on Mac...

zybex · « **Reply #8 on:** February 20, 2024, 10:53:09 am »

No, Hendrik said those were disabled years ago (and I checked, there are no broadcasts from MC). This uses COM automation, there's an exposed Event callback there.

The consensus from that thread is that a websocket is a better solution for all platforms.

Striker · « **Reply #9 on:** February 20, 2024, 02:32:14 pm »

Zybex,

Today I learned that the execute= in the ini file must be

execute = cmd.exe /c McMonitorReader.exe

and not just

execute = McMonitorReader.exe

This is really no problem now that I know. Is this what you intended?

Quote

13:25:07.639 Application restarting
13:25:07.731 Application started
13:25:07.767 MediaCenter version 30.0.91, APILevel=2
13:25:07.767 MediaCenter library is 'MC30_Library', path=D:\My Documents\JRiver\MC30_Library\
13:25:07.771 MC is connected
13:25:10.384 EXCEPTION: Exception running command
System.IndexOutOfRangeException: Index was outside the bounds of the array.

at MCMonitor.ExecuteHandler.executeShellCommand(String command, Int32 timeout, String workingDirectory)

zybex · « **Reply #10 on:** February 20, 2024, 03:13:35 pm »

No, that's a bug. Fixed here:
https://github.com/zybexXL/MCMonitor/releases/tag/v1.0.3

Striker · « **Reply #11 on:** February 20, 2024, 03:33:15 pm »

Quote from: zybex on February 20, 2024, 03:13:35 pm

No, that's a bug. Fixed here:
https://github.com/zybexXL/MCMonitor/releases/tag/v1.0.3

Still doesn't work without the cmd and the version still shows as v1.02 on the screen.

zybex · « **Reply #12 on:** February 20, 2024, 03:51:01 pm »

Oops, I zipped the wrong file. Please re-download from the same link.

Striker · « **Reply #13 on:** February 20, 2024, 04:20:14 pm »

Quote from: zybex on February 20, 2024, 03:51:01 pm

Oops, I zipped the wrong file. Please re-download from the same link.

Thanks, much better now.

LOL... I've never done anything like that...

zybex · « **Reply #14 on:** February 20, 2024, 04:32:45 pm »

Just a note - you should probably be using the $json parameter instead of having your reader always read the default Json file.
This is because an action in MC usually triggers 3 or 4 events in quick succession. So MCMonitor will call your Reader to handle the first event, but it will not wait. So it may happen that while your Reader is trying to read the Json file, MCmonitor may be trying to overwrite it with the info for the next event and they may interfere with each other; or you may see only the second event data, losing the first.

The $Json parameter gives you a temporary Json file with the same event data that is guaranteed not to be overwritten.

Striker · « **Reply #15 on:** February 20, 2024, 05:57:47 pm »

Quote from: zybex on February 20, 2024, 04:32:45 pm

Just a note - you should probably be using the $json parameter instead of having your reader always read the default Json file.
This is because an action in MC usually triggers 3 or 4 events in quick succession. So MCMonitor will call your Reader to handle the first event, but it will not wait. So it may happen that while your Reader is trying to read the Json file MCmonitor may be trying to overwrite it with the info for the next event, and they may interfere with each other.

The $Json parameter gives you a temporary Json file with the same event data that is guaranteed not to be overwritten.

Okay that explains the purpose of those temporary files. I'll have to take that $Json parm as an argument to my program.

Striker · « **Reply #16 on:** February 20, 2024, 08:33:00 pm »

Quote from: zybex on February 20, 2024, 04:32:45 pm

Just a note - you should probably be using the $json parameter instead of having your reader always read the default Json file.
This is because an action in MC usually triggers 3 or 4 events in quick succession. So MCMonitor will call your Reader to handle the first event, but it will not wait. So it may happen that while your Reader is trying to read the Json file MCmonitor may be trying to overwrite it with the info for the next event, and they may interfere with each other.

The $Json parameter gives you a temporary Json file with the same event data that is guaranteed not to be overwritten.

I can pass the $Json parm to my program, I see the file name in my logs.

I can stat the file okay.

stat good [/c/Users/gkerber/AppData/Local/Temp/MCMonitor.20.json]

However, the contents are incomplete.

This is what I see in my logs when I read the $Json file and log the contents.

Using the default Json file works fine and I get all the data.

Is there something I am misunderstanding or doing wrong?

Quote

XX:20240220-192705 Size 12
XX:20240220-192705 LINE [{]
XX:20240220-192705 LINE [ "EventCounter": 10,]
XX:20240220-192705 LINE [ "Timestamp": "2024-02-20T19:27:00",]
XX:20240220-192705 LINE [ "Source": "MCEvent",]
XX:20240220-192705 LINE [ "Type": "MCCommand",]
XX:20240220-192705 LINE [ "Arg1": "NOTIFY_PLAYERSTATE_CHANGE",]
XX:20240220-192705 LINE [ "Arg2": "0",]
XX:20240220-192705 LINE [ "State": "UNKNOWN",]
XX:20240220-192705 LINE [ "PlaybackInfo": null,]
XX:20240220-192705 LINE [ "CurrentFile": null,]
XX:20240220-192705 LINE [ "NextFile": null]
XX:20240220-192705 LINE [}]

zybex · « **Reply #17 on:** February 21, 2024, 03:31:29 am »

Thanks Striker, fixed here:
https://github.com/zybexXL/MCMonitor/releases/tag/v1.0.4

I've always tested with other variables in the command line together with $json, so it was always populated. When using only $json it was missing the info.

Striker · « **Reply #18 on:** February 21, 2024, 05:35:04 pm »

Quote from: zybex on February 21, 2024, 03:31:29 am

Thanks Striker, fixed here:
https://github.com/zybexXL/MCMonitor/releases/tag/v1.0.4

I've always tested with other variables in the command line together with $json, so it was always populated. When using only $json it was missing the info.

LOL... the zip file still has v1.0.3 ...

zybex · « **Reply #19 on:** February 21, 2024, 05:47:10 pm »

What the...
OK, re-uploaded and triple checked.

I think I get it now. It's some bug in Github caused by reusing the same publishing tag/release. I'm sure I uploaded the correct zip because I deleted all others before creating the new one, but I reused the 1.0.3 tag and then changed it (after upload) to 1.0.4. Apparently it kept the previous 1.0.3 zip. Lesson learned.

Striker · « **Reply #20 on:** February 21, 2024, 06:48:16 pm »

Another Question:

Quote

17:40:46.224 MC is connected
17:40:56.456 Running command: McMonitorReader.exe -j C:\Users\gkerber\AppData\Local\Temp\MCMonitor.2.json
17:40:56.456 Process did not exit in the given timeout ({timeout} ms)

What does it mean "the process did not exit in the given timeout" ?

I tried these settings:

execute.maxwait = 30
execute.minwait = 0.25

But notice that the command started at the same time as the "process did not exit..." at the exact time.

17:40:56.456

Maybe those settings are for multiple configured "execute=". Still then... what does the "process did not exit..." log message mean?

zybex · « **Reply #21 on:** February 22, 2024, 02:56:58 am »

Uploaded v1.05 (checked!)
https://github.com/zybexXL/MCMonitor/releases/tag/v1.0.5

This was a copy/paste bug, it was parsing minWait twice and ignoring maxWait. So in effect it was waiting just 0.25 seconds before logging the warning. Also fixed the log line {timeout} indication.
Not sure though why your log shows the same timestamp though, there should be .25 seconds interval:

10:34:45.637 MC is connected
10:34:45.835 Running command: cmd.exe /c sleep 2
10:34:46.103 Process did not exit in the given timeout (250 ms)
10:34:46.105 Running command: cmd.exe /c sleep 2
10:34:46.370 Process did not exit in the given timeout (250 ms)

Some implementation notes:

minWait: this is the minimum interval between commands. If you have 2 commands per event in the config, they will be executed with *at least* this interval. But also, if you have just one command and MCMonitor receives 2 or 3 events, the commands for those will also be spaced by at least minWait seconds. Set to zero to run as fast as possible, but then your McMonitorReader might actually execute the commands out of order as the process timeslot allocation depends on the OS and is not guaranteed to be fair or maintain order.

maxWait: this is the maximum interval between commands. After executing a command MCMonitor will wait up to maxWait seconds for it to exit; if it doesn't, it will log the timeout notice but the command will be left running, not killed. Then the next command will execute. This means that if your command is slow to execute you may get multiple commands with overlapped execution. Set to zero to run as fast as possible (while still honoring minWait above).

Striker · « **Reply #22 on:** February 22, 2024, 02:37:54 pm »

I seem to be getting some inconsistent data...
* I ignore all WAITING events

I have two sets of log events below - both for a track change while playing.

For the first track change I get a NOTIFY_TRACK_CHANGE / PLAYING and then a NOTIFY_PLAYERSTATE_CHANGE /
PLAYING

For the 2nd track change I get the same events, but in opposite order.

The first looks good to me and how I would expect the messages to be and note
that the FileKey is the same on both events.

But the second track change, is "wrong" and note the FileKey is different between the
events along with other values.

Quote

XX:20240222-131109 START McMonitorReader pid 12120

XX:20240222-131109 JSON READ COMPLETE 73
XX:20240222-131109 JSON file size 73
XX:20240222-131109 Size 73
XX:20240222-131109 !!! ARG1 [NOTIFY_TRACK_CHANGE]
XX:20240222-131109 !!! STATE [PLAYING]
XX:20240222-131110 !!! STATUS [Playing]
XX:20240222-131110 LINE [{]
XX:20240222-131110 LINE ["EventCounter": 173,]
XX:20240222-131110 LINE ["Timestamp": "2024-02-22T13:11:09",]
XX:20240222-131110 LINE ["Source": "MCEvent",]
XX:20240222-131110 LINE ["Type": "MCCommand",]
XX:20240222-131110 LINE ["Arg1": "NOTIFY_TRACK_CHANGE",]
XX:20240222-131110 LINE ["Arg2": "0",]
XX:20240222-131110 LINE ["State": "PLAYING",]
XX:20240222-131110 LINE ["InfoTimestamp": "2024-02-22T13:11:09",]
XX:20240222-131110 LINE ["PlaybackInfo": {]
XX:20240222-131110 LINE ["ZoneID": "0",]
XX:20240222-131110 LINE ["State": "2",]
XX:20240222-131110 LINE ["FileKey": "35922195",]
XX:20240222-131110 LINE ["NextFileKey": "35922201",]
XX:20240222-131110 LINE ["PositionMS": "0",]
XX:20240222-131110 LINE ["DurationMS": "354853",]
XX:20240222-131110 LINE ["ElapsedTimeDisplay": "0:00",]
XX:20240222-131110 LINE ["RemainingTimeDisplay": "-5:54",]
XX:20240222-131110 LINE ["TotalTimeDisplay": "5:54",]
XX:20240222-131110 LINE ["PositionDisplay": "0:00 / 5:54",]
XX:20240222-131110 LINE ["PlayingNowPosition": "4",]
XX:20240222-131110 LINE ["PlayingNowTracks": "1634",]
XX:20240222-131110 LINE ["PlayingNowPositionDisplay": "5 of 1634",]
XX:20240222-131110 LINE ["PlayingNowChangeCounter": "13",]
XX:20240222-131110 LINE ["Bitrate": "0",]
XX:20240222-131110 LINE ["Bitdepth": "16",]
XX:20240222-131110 LINE ["SampleRate": "44100",]
XX:20240222-131110 LINE ["Channels": "2",]
XX:20240222-131110 LINE ["Chapter": "0",]
XX:20240222-131110 LINE ["Volume": "-1",]
XX:20240222-131110 LINE ["VolumeDisplay": "N/A",]
XX:20240222-131110 LINE ["ImageURL": "MCWS/v1/File/GetImage?File=35922195",]
XX:20240222-131110 LINE ["Artist": "Jewell, Eilen",]
XX:20240222-131110 LINE ["Album": "2006 Boundary County",]
XX:20240222-131110 LINE ["Name": "Blow It All Away",]
XX:20240222-131110 LINE ["Rating": "2",]
XX:20240222-131110 LINE ["Status": "Playing"]
XX:20240222-131110 LINE [},]

XX:20240222-131110 STOP McMonitorReader pid 12120

-------------------------------------

XX:20240222-131110 START McMonitorReader pid 16668

XX:20240222-131110 JSON READ COMPLETE 73
XX:20240222-131110 JSON file size 73
XX:20240222-131110 Size 73
XX:20240222-131110 !!! ARG1 [NOTIFY_PLAYERSTATE_CHANGE]
XX:20240222-131110 !!! STATE [PLAYING]
XX:20240222-131110 !!! STATUS [Playing]
XX:20240222-131110 LINE [{]
XX:20240222-131110 LINE ["EventCounter": 174,]
XX:20240222-131110 LINE ["Timestamp": "2024-02-22T13:11:09",]
XX:20240222-131110 LINE ["Source": "MCEvent",]
XX:20240222-131110 LINE ["Type": "MCCommand",]
XX:20240222-131110 LINE ["Arg1": "NOTIFY_PLAYERSTATE_CHANGE",]
XX:20240222-131110 LINE ["Arg2": "0",]
XX:20240222-131110 LINE ["State": "PLAYING",]
XX:20240222-131110 LINE ["InfoTimestamp": "2024-02-22T13:11:09",]
XX:20240222-131110 LINE ["PlaybackInfo": {]
XX:20240222-131110 LINE ["ZoneID": "0",]
XX:20240222-131110 LINE ["State": "2",]
XX:20240222-131110 LINE ["FileKey": "35922195",]
XX:20240222-131110 LINE ["NextFileKey": "35922201",]
XX:20240222-131110 LINE ["PositionMS": "0",]
XX:20240222-131110 LINE ["DurationMS": "354853",]
XX:20240222-131110 LINE ["ElapsedTimeDisplay": "0:00",]
XX:20240222-131110 LINE ["RemainingTimeDisplay": "-5:54",]
XX:20240222-131110 LINE ["TotalTimeDisplay": "5:54",]
XX:20240222-131110 LINE ["PositionDisplay": "0:00 / 5:54",]
XX:20240222-131110 LINE ["PlayingNowPosition": "4",]
XX:20240222-131110 LINE ["PlayingNowTracks": "1634",]
XX:20240222-131110 LINE ["PlayingNowPositionDisplay": "5 of 1634",]
XX:20240222-131110 LINE ["PlayingNowChangeCounter": "13",]
XX:20240222-131110 LINE ["Bitrate": "0",]
XX:20240222-131110 LINE ["Bitdepth": "16",]
XX:20240222-131110 LINE ["SampleRate": "44100",]
XX:20240222-131110 LINE ["Channels": "2",]
XX:20240222-131110 LINE ["Chapter": "0",]
XX:20240222-131110 LINE ["Volume": "-1",]
XX:20240222-131110 LINE ["VolumeDisplay": "N/A",]
XX:20240222-131110 LINE ["ImageURL": "MCWS/v1/File/GetImage?File=35922195",]
XX:20240222-131110 LINE ["Artist": "Jewell, Eilen",]
XX:20240222-131110 LINE ["Album": "2006 Boundary County",]
XX:20240222-131110 LINE ["Name": "Blow It All Away",]
XX:20240222-131110 LINE ["Rating": "2",]
XX:20240222-131110 LINE ["Status": "Playing"]
XX:20240222-131110 LINE [},]

XX:20240222-131111 STOP McMonitorReader pid 16668

This is another track change but notice the FileKey and other values are different between the events.

Quote

XX:20240222-131212 START McMonitorReader pid 7644

XX:20240222-131212 JSON READ COMPLETE 73
XX:20240222-131212 JSON file size 73
XX:20240222-131212 Size 73
XX:20240222-131212 !!! ARG1 [NOTIFY_PLAYERSTATE_CHANGE]
XX:20240222-131212 !!! STATE [PLAYING]
XX:20240222-131212 !!! STATUS [Playing]
XX:20240222-131212 LINE [{]
XX:20240222-131212 LINE ["EventCounter": 177,]
XX:20240222-131212 LINE ["Timestamp": "2024-02-22T13:12:12",]
XX:20240222-131212 LINE ["Source": "MCEvent",]
XX:20240222-131212 LINE ["Type": "MCCommand",]
XX:20240222-131212 LINE ["Arg1": "NOTIFY_PLAYERSTATE_CHANGE",]
XX:20240222-131212 LINE ["Arg2": "0",]
XX:20240222-131212 LINE ["State": "PLAYING",]
XX:20240222-131212 LINE ["InfoTimestamp": "2024-02-22T13:12:12",]
XX:20240222-131212 LINE ["PlaybackInfo": {]
XX:20240222-131212 LINE ["ZoneID": "0",]
XX:20240222-131212 LINE ["State": "2",]
XX:20240222-131212 LINE ["FileKey": "35922195",]
XX:20240222-131212 LINE ["NextFileKey": "35922201",]
XX:20240222-131213 LINE ["PositionMS": "349031",]
XX:20240222-131213 LINE ["DurationMS": "354853",]
XX:20240222-131213 LINE ["ElapsedTimeDisplay": "5:49",]
XX:20240222-131213 LINE ["RemainingTimeDisplay": "-0:05",]
XX:20240222-131213 LINE ["TotalTimeDisplay": "5:54",]
XX:20240222-131213 LINE ["PositionDisplay": "5:49 / 5:54",]
XX:20240222-131213 LINE ["PlayingNowPosition": "3",]
XX:20240222-131213 LINE ["PlayingNowTracks": "1633",]
XX:20240222-131213 LINE ["PlayingNowPositionDisplay": "4 of 1633",]
XX:20240222-131213 LINE ["PlayingNowChangeCounter": "14",]
XX:20240222-131213 LINE ["Bitrate": "342",]
XX:20240222-131213 LINE ["Bitdepth": "16",]
XX:20240222-131213 LINE ["SampleRate": "44100",]
XX:20240222-131213 LINE ["Channels": "2",]
XX:20240222-131213 LINE ["Chapter": "0",]
XX:20240222-131213 LINE ["Volume": "-1",]
XX:20240222-131213 LINE ["VolumeDisplay": "N/A",]
XX:20240222-131213 LINE ["ImageURL": "MCWS/v1/File/GetImage?File=35922195",]
XX:20240222-131213 LINE ["Artist": "Jewell, Eilen",]
XX:20240222-131213 LINE ["Album": "2006 Boundary County",]
XX:20240222-131213 LINE ["Name": "Blow It All Away",]
XX:20240222-131213 LINE ["Rating": "2",]
XX:20240222-131213 LINE ["Status": "Playing"]
XX:20240222-131213 LINE [},]
XX:20240222-131213 STOP McMonitorReader pid 7644

-------------------------------------

XX:20240222-131218 START McMonitorReader pid 17980

XX:20240222-131218 JSON READ COMPLETE 73
XX:20240222-131218 JSON file size 73
XX:20240222-131218 Size 73
XX:20240222-131218 !!! ARG1 [NOTIFY_TRACK_CHANGE]
XX:20240222-131218 !!! STATE [PLAYING]
XX:20240222-131218 !!! STATUS [Playing]
XX:20240222-131218 LINE [{]
XX:20240222-131218 LINE ["EventCounter": 178,]
XX:20240222-131218 LINE ["Timestamp": "2024-02-22T13:12:18",]
XX:20240222-131218 LINE ["Source": "MCEvent",]
XX:20240222-131218 LINE ["Type": "MCCommand",]
XX:20240222-131218 LINE ["Arg1": "NOTIFY_TRACK_CHANGE",]
XX:20240222-131218 LINE ["Arg2": "0",]
XX:20240222-131218 LINE ["State": "PLAYING",]
XX:20240222-131218 LINE ["InfoTimestamp": "2024-02-22T13:12:18",]
XX:20240222-131218 LINE ["PlaybackInfo": {]
XX:20240222-131218 LINE ["ZoneID": "0",]
XX:20240222-131218 LINE ["State": "2",]
XX:20240222-131218 LINE ["FileKey": "35922201",]
XX:20240222-131218 LINE ["NextFileKey": "35922198",]
XX:20240222-131218 LINE ["PositionMS": "606",]
XX:20240222-131218 LINE ["DurationMS": "175266",]
XX:20240222-131218 LINE ["ElapsedTimeDisplay": "0:00",]
XX:20240222-131218 LINE ["RemainingTimeDisplay": "-2:55",]
XX:20240222-131218 LINE ["TotalTimeDisplay": "2:55",]
XX:20240222-131218 LINE ["PositionDisplay": "0:00 / 2:55",]
XX:20240222-131218 LINE ["PlayingNowPosition": "4",]
XX:20240222-131218 LINE ["PlayingNowTracks": "1633",]
XX:20240222-131218 LINE ["PlayingNowPositionDisplay": "5 of 1633",]
XX:20240222-131218 LINE ["PlayingNowChangeCounter": "14",]
XX:20240222-131218 LINE ["Bitrate": "1100",]
XX:20240222-131218 LINE ["Bitdepth": "16",]
XX:20240222-131218 LINE ["SampleRate": "44100",]
XX:20240222-131218 LINE ["Channels": "2",]
XX:20240222-131218 LINE ["Chapter": "0",]
XX:20240222-131218 LINE ["Volume": "-1",]
XX:20240222-131218 LINE ["VolumeDisplay": "N/A",]
XX:20240222-131218 LINE ["ImageURL": "MCWS/v1/File/GetImage?File=35922201",]
XX:20240222-131218 LINE ["Artist": "Jewell, Eilen",]
XX:20240222-131218 LINE ["Album": "2007 Letters from Sinners and Strangers",]
XX:20240222-131218 LINE ["Name": "Rich Man\u0027s World",]
XX:20240222-131218 LINE ["Rating": "3",]
XX:20240222-131219 LINE ["Status": "Playing"]
XX:20240222-131219 LINE [},]
XX:20240222-131219 STOP McMonitorReader pid 17980

zybex · « **Reply #23 on:** February 22, 2024, 03:20:26 pm »

I think that's the difference between changing a track manually or letting it go on to the next track after the current one finishes.
- When you switch manually, you get a NOTIFY_TRACK_CHANGE and NOTIFY_PLAYERSTATE_CHANGE referencing the new file immediately (same timestamp)
- 6 or 7 seconds before a track finishes, MC preloads the next one. Here you get a NOTIFY_PLAYERSTATE_CHANGE=PLAYING which still mentions the current track. Then when it actually ends and MC switches to the next one you only get the NOTIFY_TRACK_CHANGE which now points to the next one. Note the timestamp differences between the 2 events, while on the first case they have the same timestamp.

The WAITING events are usually due to loading/buffering, so they'll point to the next file too in this scenario, or to the current one if it's a large file loaded in chunks.

-- start track
2024-02-22T22:05:21 seq=2 type=MCCommand arg1=NOTIFY_PLAYERSTATE_CHANGE arg2=0 state=WAITING current=23 next=20
2024-02-22T22:05:21 seq=3 type=MCCommand arg1=NOTIFY_VOLUME_CHANGED arg2=0 state=WAITING current=23 next=20
2024-02-22T22:05:21 seq=4 type=MCCommand arg1=NOTIFY_TRACK_CHANGE arg2=0 state=PLAYING current=23 next=20
2024-02-22T22:05:21 seq=5 type=MCCommand arg1=NOTIFY_PLAYERSTATE_CHANGE arg2=0 state=PLAYING current=23 next=20
-- manually change
2024-02-22T22:05:52 seq=6 type=MCCommand arg1=NOTIFY_PLAYERSTATE_CHANGE arg2=0 state=WAITING current=19 next=22
2024-02-22T22:05:52 seq=7 type=MCCommand arg1=NOTIFY_VOLUME_CHANGED arg2=0 state=WAITING current=19 next=22
2024-02-22T22:05:52 seq=8 type=MCCommand arg1=NOTIFY_TRACK_CHANGE arg2=0 state=PLAYING current=19 next=22
2024-02-22T22:05:52 seq=9 type=MCCommand arg1=NOTIFY_PLAYERSTATE_CHANGE arg2=0 state=PLAYING current=19 next=22
-- manually change
2024-02-22T22:07:55 seq=24 type=MCCommand arg1=NOTIFY_PLAYERSTATE_CHANGE arg2=0 state=WAITING current=13 next=10
2024-02-22T22:07:55 seq=25 type=MCCommand arg1=NOTIFY_VOLUME_CHANGED arg2=0 state=WAITING current=13 next=10
2024-02-22T22:07:55 seq=26 type=MCCommand arg1=NOTIFY_TRACK_CHANGE arg2=0 state=PLAYING current=13 next=10
2024-02-22T22:07:55 seq=27 type=MCCommand arg1=NOTIFY_PLAYERSTATE_CHANGE arg2=0 state=PLAYING current=13 next=10
-- preloading next track
2024-02-22T22:08:12 seq=28 type=MCCommand arg1=NOTIFY_PLAYERSTATE_CHANGE arg2=0 state=WAITING current=13 next=10
2024-02-22T22:08:12 seq=29 type=MCCommand arg1=NOTIFY_VOLUME_CHANGED arg2=0 state=WAITING current=13 next=10
2024-02-22T22:08:12 seq=30 type=MCCommand arg1=NOTIFY_PLAYERSTATE_CHANGE arg2=0 state=PLAYING current=13 next=10
-- prev track ended,
-- next track started
2024-02-22T22:08:19 seq=31 type=MCCommand arg1=NOTIFY_TRACK_CHANGE arg2=0 state=PLAYING current=10 next=7
-- manual stop
2024-02-22T22:08:33 seq=32 type=MCCommand arg1=NOTIFY_PLAYERSTATE_CHANGE arg2=0 state=STOPPED current=10 next=7
2024-02-22T22:08:33 seq=33 type=MCCommand arg1=NOTIFY_PLAYERSTATE_CHANGE arg2=0 state=STOPPED current=10 next=7
2024-02-22T22:08:33 seq=34 type=MCCommand arg1=NOTIFY_VOLUME_CHANGED arg2=0 state=STOPPED current=10 next=7
2024-02-22T22:08:33 seq=35 type=MCCommand arg1=NOTIFY_TRACK_CHANGE arg2=0 state=STOPPED current=10 next=7

Striker · « **Reply #24 on:** February 22, 2024, 03:26:51 pm »

Sigh, what you explain kinda makes sense, but I'm not sure how to deal with it. I'll have to think about this.

zybex · « **Reply #25 on:** February 22, 2024, 03:34:18 pm »

Perhaps you can just ignore NOTIFY_PLAYERSTATE_CHANGE ? The TRACK_CHANGE event seems to track pretty well with what's happening. The PLAYERSTATE_CHANGE just alternates between WAITING (buffering) and PLAYING.

zybex · « **Reply #26 on:** February 22, 2024, 03:41:55 pm »

Well there's one exception - Pausing/Resuming a track is reported as a NOTIFY_PLAYERSTATE_CHANGE apparently:

pause
2024-02-22T22:39:49 seq=40 type=MCCommand arg1=NOTIFY_PLAYERSTATE_CHANGE arg2=0 state=PAUSED current=3 next=5
resume
2024-02-22T22:40:03 seq=41 type=MCCommand arg1=NOTIFY_PLAYERSTATE_CHANGE arg2=0 state=PLAYING current=3 next=5

Looking at the log, it looks like the State/Current/Next values are always correct on all events.

Striker · « **Reply #27 on:** February 22, 2024, 06:37:10 pm »

Quote from: zybex on February 22, 2024, 03:41:55 pm

Well there's one exception - Pausing/Resuming a track is reported as a NOTIFY_PLAYERSTATE_CHANGE apparently:

pause
2024-02-22T22:39:49 seq=40 type=MCCommand arg1=NOTIFY_PLAYERSTATE_CHANGE arg2=0 state=PAUSED current=3 next=5
resume
2024-02-22T22:40:03 seq=41 type=MCCommand arg1=NOTIFY_PLAYERSTATE_CHANGE arg2=0 state=PLAYING current=3 next=5

Looking at the log, it looks like the State/Current/Next values are always correct on all events.

Yes that seems to be true. I still have to somehow know which events where I can't use the current and next info on a manual track change.

I ran into another challenge... when I change the rating on the current track, I want to update the screens around my home. A rating change is not an "event" so McMonitor can't notify me.

zybex · « **Reply #28 on:** February 23, 2024, 02:25:07 am »

MC would need to expose the 34012 MCC_NOTIFY_FILE_CHANGED internal notification as an Automation event for that to work. Even so it doesn't tell exactly which field changed.

This could fire thousands of times for some operations though, unless they fire it only once per file once all tags are applied. Still, MCMonitor could filter/aggregate the events so they they would be reported only once per changed file regardless of the number of changes.

Striker · « **Reply #29 on:** February 23, 2024, 09:48:28 am »

Quote from: zybex on February 23, 2024, 02:25:07 am

MC would need to expose the 34012 MCC_NOTIFY_FILE_CHANGED internal notification as an Automation event for that to work. Even so it doesn't tell exactly which field changed.

This could fire thousands of times for some operations though, unless they fire it only once per file once all tags are applied. Still, MCMonitor could filter/aggregate the events so they they would be reported only once per changed file regardless of the number of changes.

No need for that... If I go with McMonitor I'll continue to use my old method. 99% of the time I change ratings using external MCxx command either from buttons on my toolbar or from my remote controls... and I then update my screens.

I'm still struggling with the old data being returned on a NOTIFY_PLAYERSTATE_CHANGE depending on if the track change was initiated by a manual track change for naturally as the old track ends.

zybex · « **Reply #30 on:** February 23, 2024, 09:52:26 am »

2024-02-22T22:08:12 seq=30 type=MCCommand arg1=NOTIFY_PLAYERSTATE_CHANGE arg2=0 state=PLAYING current=13 next=10

The track hasn't ended yet - the Current and Next track keys are valid and point to what is [still] playing, and what the next will be. It seems to me you can always rely on them in all events. An actual track change is *always* signaled by a NOTIFY_TRACK_CHANGE event.

INTERACT FORUM

Author Topic: MCMonitor: Detect MC track change events, run commands (Read 3536 times)