It would help to have more details. Playing on the client? Or server? What OS? Playing to what device? Etc. Details will help us reproduce the problem.
The problem has recurred for me this morning.
I was trying to play on my Windows 10 Pro (all Australian updates) Workstation running MC24.0.46 64bit using a local database, no Media Server running, playing locally from the motherboard sound card to PC connected speakers. I tried to start RP three times shortly after starting MC and go the message each time.
I just tried it on my Windows 10 Pro (all Australian updates) HTPC running MC24.0.42 64bit as a server, with Media Server running, playing to my Receiver via TOSLink from the motherboard sound card and it worked immediately.
I stopped RP, restarted it, stopped it, then upgraded to MC24.0.46 and tried again. It still worked fine first time. It is still playing background music for me now.
So back to my Workstation, I tried RP again and it worked fine immediately. That is without closing MC since earlier.
Closed MC. Made sure no MC processes were running in Task Manager. Restarted MC, cleared Playing Now as it still had the last RP track listed. Checked the RP Playlist was empty. Restarted RP and it worked.
Cleared Playing Now again. Played a local audio file. Stopped playback. Closed MC and checked no processes running. Restarted MC and immediately tried RP. Worked fine.
The only pattern I see is that RP didn't work first time after it hadn't been played for a while, but only on my Workstation... which made me suspicious that maybe the first attempt through my router's firewall was being blocked. Checked logs, but there was nothing in there to say it blocked anything today. So not that. I checked the local PC firewall as well, and nothing there.
So not much light on the topic there. If I was a betting man, I would say that the RP server is not accepting a connection from a new IP Address for a little while, initially, for the connection type MC is using. That could mean that they are at the limit of the number of connections allowed for that connection type, and that they possibly dynamically increase that limit when it gets hit, but that increase takes a little while.
Maybe RP even keep a list of IP Addresses that connect using MC, and once connected it is allowed, but if the limit is hit it can take a while to increase the limit. That would explain why my Workstation failed, but shortly after my HTPC worked, and then the Workstation worked, as both the HTPC and Workstation would expose the same external IP Address to RP. That would be consistent with something else that I have noticed, which is once a connection to RP is made, even when you stop playback, that connection is kept for a while. I did this on the HTPC in the test above, and even though RP was stopped during the introduction, it still downloaded the playlist and changed to the first track to be played, with a little bit of audio played at track change.
Thinking further, I'm sure that RP track and count the number of MC connections to their server. I sure would in their situation, to understand the level of demand and if it remains within any agreement made. Perhaps their monitoring process has introduced an issue that causes the first connection from a new IP Address to be delayed and therefore fails to start playback? Then once an IP Address is "counted" they wouldn't want to count it again for a period of time, if users start and stop playback over a certain period, so it would be on a list for a short time, and then would drop off the list. Once it is off the list, the problem would recur.
Next time I see the problem on my Workstation I will simply wait a few minutes and try again, wait and try again, etc. to see if a connection is eventually allowed and playback starts.
