Flow
One attempt, in order
1Look
Check whether this title is playing on this player. Match both.
2Already playing
Send nothing and report it as playing.
3Send
The first try uses one route; later tries switch to the other.
4Answer
Playing, accepted but still checking, or unknown with nothing retried.
5Wait longer
The page waits and looks again before the next numbered try.
Same title, started more than once: that was the media panel's habit. One tap on play, and the box under the TV could be told to start it again.
Two retry layers that multiplied
The server sent the start command one way. Then it waited for the media server to list the title as playing. If it didn't see it in time, it sent the command again a second way. The browser had its own loop on top: if the answer wasn't confirmed, it waited a moment and sent the whole request again. One slow start could turn into a pile of start commands. My old test even expected two commands from one request.
A late signal that looked like a missing one
Each layer waited for the title to show up in the session list. Most likely, that list lags. The box says "got it" right away, starts later, and gets listed later still. So a slow start looked like a lost one, and the code resent.
First pass: one send and an honest answer
My first change stopped all resending. After the command goes out, the server answers with one of three results: playing, accepted but still checking, or unknown with nothing retried. That third answer matters. If a send breaks after the command may have left, you don't know whether it worked, so say that instead of calling it a failure. The browser sent once and then only watched.
That stopped the duplicates. But a truly lost command now needed a second tap by hand, and I don't want a play button I have to babysit.
Second pass: a look before every try
Then I put retries back with one rule: every attempt starts by looking.
If the title is already on that screen, the server says already playing and sends nothing.
The check matches both the title and the player, so the same movie in another room doesn't count. Each request carries an attempt number. The server refuses numbers outside a small range, so a buggy page can't skip the limit. Later attempts switch to the other way of sending instead of repeating the one that just did nothing. In the browser the order is: look once, send, wait longer, then decide. I also removed a pause that used to sit before the first look.
My tests now cover a second attempt using the other route, a title already playing getting no command, and a too-high attempt number getting refused.
One gap I know about
The look isn't a lock. If the last command is still on its way and the title isn't listed yet, the look comes back empty and the next try sends. The long wait between tries is what covers that, and I haven't checked how often it falls short.