Network Session | Client Queue not refreshing from Host immediately

AnthonyB

This is kinda important as a Client with Remote Control can only see the Queue in ST4, and therefore in a Band situation, this is the equivalent of knowing the Set List and seeing what songs are coming up next. As I type this up, I'm getting a sense of deja vu, as though this is an issue that I've reported in the past, has been fixed, but with recent changes is now back again?

ST4 Build: 2195
Device & iOS Version: Host/Client: iPad 9th Gen, iOS 26.1.0, Client: iPad 5th Gen, iOS 16.7.12

Issue Description:
There appears to be some delay in the Client receiving thew Queue from the Host and it requires the Host to select multiple songs (either in Playlist or Queue itself) for the Client to receive the latest Queue list from the Host

Steps to Reproduce:

On the Host, clear the queue so it is empty
Setup Network Session with a Client
On the Host, select a Playlist of songs
Observation: On the Host, the Queue now contains all of the songs from the Playlist. On the Client, the Queue is still empty.
On the Host, press Play so that the first song in the Queue starts playing
Observation: Queue on Clients is still empty
When song ends and moves to next song in Queue, the Clients now receive the entire Queue. Alternatively, you can force the Clients to get the full Queue by, on the Host, select a 2nd song in the playlist.

Expected Behavior:
The Clients should receive the Queue from the Host as soon as the Host Queue updates/changes. (note: if you clear the Queue on the Host, this does automatically reflect on Clients)

Actual Behavior:
The Clients don't receive the Queue from the Host until a 2nd song is selected, manually or because playback on the Host completed the first song and loads the next song in the queue.

peter

I had a hard time reproducing this. Only the iOS18 host seemed to have this issue and then only sometimes. A code analysis showed now error. Each queue change triggers a send to the clients.

So in the end I think the message can get lost sometimes due to the fast but unreliable UDP network messages. I will have to check whether I could replace UDP messages with reliable TCP messages without sacrificing too much performance. But that will take time.

AnthonyB

peter I had a hard time reproducing this.

That's odd. It is 100% reproduceable for me with both iOS 26 and 16 Clients.
Would you like me to send logs through from my 3 devices after a repro?

peter

No, the logs don't contain useful info about this. But the next update will switch to TCP data transfer. So I guess it will be fixed with todays update.

AnthonyB

peter But the next update will switch to TCP data transfer

Interesting given our previous UDP vs TCP discussion that we've ended up here. It will be interesting to see if we observe much change in network session performance as a result.

peter

With build 2219 all network data is sent via UDP so that no more packets can get lost. I didn't notice any higher latency or load in my tests. Seems like another good example for over-engineering. I wanted to optimise network transfer but instead made it more complex with the UDP approach without noticeable gains.

AnthonyB

peter With build 2219 all network data is sent via UDP

I know that was meant to be TCP 🙂

peter Seems like another good example for over-engineering. I wanted to optimise network transfer but instead made it more complex with the UDP approach without noticeable gains.

LOL. Well, we've all over-engineered and created 'a monster' before. That experience can sometime makes us a little sceptical of doing similar again. The reasons for staying with UDP, on paper, were valid. Glad we were forced to try TCP and (touch wood) have come out with a more robust solution!