Just an update, since I haven't posted in awhile -- Headshaker's detailed information helped immensely here and I believe we've found the root cause of these issues (or if not, we've found another substantial issue that needed to be resolved anyway, so either way, cheers, Headshaker!)
It looks like it's actually a combination of two separate issues that have to interact in order for the problem to manifest, which is why it's been such a difficult process to track it down.
As for why this is taking so long to "fix"... first, some background -- as you may know, v3 uses a modular architecture in which the control panel can run on one physical server/VPS, and manage multiple (local or remote) physical/VPS streaming server nodes. Right now, because the autoDJ depends on MySQL, the streaming nodes aren't fully independent -- that's a holdover from how v2.x worked. Our goal for a future release (post v3.0.0) is to eventually fully decouple the streaming nodes from the control panel by abandoning MySQL in favor of SQLite, and put the autoDJ's SQLite databases on the streaming nodes, making the streaming nodes 100% self-contained and independent.
Back on point, one of the two issues that's contributing to the problem reported in this thread is the manner in which we're allowing sc_trans2/ices to pull down track information from the control panel server in the interim. Instead of putting a quick band-aid fix on that, we're taking the time to make some more fundamental changes that not only fix this problem, but will eventually need to be made anyway to "pave the road" for the move to SQLite as well.
We're wrapping up those changes now and will have a new build out in the next few days for everyone to test.
And to everyone else with unreplied forum posts, I'll be looking at those as soon as this build is done. Sorry for the wait, but because this CPU load issue is bringing down servers, it takes priority.