That didn't help though I am now seeing it happen intermittently as well.
Not sure what to suggest unfortunately, but it may be related to what I discuss below (you may be able to improve the situation by turning off the DLNA renderer functionality to further sandbox MC instances)
there is some other odd behaviour as well on one linux client in that it refuses to let go of what is in playing now. For example, I can choose to start an album and then go to stop playback and it refuses to stop, you can see tracks from the album keeping getting added back into playing now after I clear it. It feels like it is related to jremote tbh (which I find annoyingly flaky at controlling a client and my wife just refuses to use)
I've seen what you're describing, and for me it has always been a side effect of DLNA control of JRiver. If you start playback on an MC renderer via DLNA, attempts to stop playback on the MC instance that's actually playing won't work correctly, playback has to be stopped on the control point that initiated playback. This is complicated because MC sometimes uses DLNA to communicate to other MC instances, which isn't obvious, and can be a source of confusion. What I'm describing below is a distillation of some old threads where I got some direct answers from Bob and some experiments I've done about when MC uses DLNA.
The key to understanding it is that if you're controlling an MC instance from it's own UI, it's own webgizmo, or through gizmo/jremote logged into that instance of MC specifically, you're using MC itself or MCWS and everything will work normally.
If you're controlling an MC instance from another MC instance or from gizmo/jremote logged into a different instance of MC, MC will use DLNA to handle the remote control, which is suboptimal because of the control weirdness. The only exception is the specific case when a library client controls zones on the library server (but not the reverse), which uses something other than DLNA (Tremote?) as a control mechanism (I don't know very much about Tremote as my server is not used for playback, so I just disable all client control of the zones on the server).
So, a concrete example: if your server is 192.168.0.4 and your client is 192.168.0.5, if you connect to 192.168.0.5 directly with JRemote, because 192.168.0.5 is a library client of 192.168.0.4, you'll see all the media and views from 192.168.0.4, but you'll get local (MCWS) control of the 192.168.0.5 instance because JRemote is talking directly to it. If you instead connect to 192.168.0.4 with JRemote and use it to control 192.168.0.5 as a zone, you get DLNA control with its attendant weirdness (slow to start or stop, local control is non-intuitive, may transcode based on your settings, etc.)
So the key to getting intuitive results, is to maximize the number of situations where you're using direct MCWS control. The way I've dealt with it, for example, is to turn off the DLNA renderer option on all my systems (which removes them from the zone listing on other JRiver instances, further confirming that that kind of zone control uses DLNA) and then setup every client instance as a separate "server" in JRemote or Gizmo (even though they're all just clients of one actual server and show the same content). I then switch "servers" in Gizmo or JRemote when I want to control different clients via gizmo/jremote. This is much more intuitive in gizmo than in JRemote as gizmo lists all servers and zones in the same menu (and doesn't even really appear to distinguish between them), so you click in the same space to change one as the other; it's tougher in JRemote as you have to retrain yourself to switch servers instead of just switching zones. It's one of several reasons that my wife prefers Gizmo even though it's not as nice looking as JRemote.