Threaded Mode | Linear Mode

windbag · 28-11-2024, 21:39

(28-11-2024 14:46)simoncn Wrote: 2) A different renderer is being used for the play requests.
...This presumably means you are using a different (later?) version of the Sonos firmware. This difference is likely to be significant.

As in OP, I'm using old Sonos units, which I’ve used for years. I was forced to abandon the Sonos Streaming approach when I got a New QNAP last year as the new one required a security level the older Sonos streamer could not handle. But it was working just fine with a massively older/slower QNAP NAS. I always knew about the ridiculous 10k track limit of the Sonos system, even when updated, so it was a good time to explore an alternative way of listening to my NAS music without such a limit - which had been working until a few weeks ago.
I can't update the old Sonos Units unless I also throw away & replace 4 NexusII control tablets, which I'm sure you understand is not attractive financially.
For info, I'm doing all these tests using Bubble on my reasonably new Samsung phone, but older versions of Bubble do work on the Nexus II units.

The PLAY1s that simbun is using (thanks for the debug log) will be on the update, and the fact that the target unit is different would almost certainly be the case anyway.

I do wonder about the too-fast speed diagnosis. The error that the Sonos throws, as in earlier post, is a complaint that it isn't receiving the stream FAST enough, not that it is too fast for it to handle. If Minim is doing its job correctly, is it Bubble that is throttling ? Might there be a Bubble setting that I should be tweaking to keep the stream across fast enough for them ?

I'll try to achieve the flowControl=2 or 3x tomorrow.

windbag

(28-11-2024 14:32)simoncn Wrote:
(28-11-2024 11:36)windbag Wrote: Looking at Properties-Advanced-serverOptions it directs me to the Other features page, and the final line of Server options-flowControl says:

Note: This feature requires a MinimServer full license.

You can activate the free 30-day trial license to try this. This provides all the functionality of a full license.

Just doing this, but note that the field now has an entry indexArtwork=auto
I added
, flowControl=2x and it seemed happy, but the save was greyed out,
so I overwrote the with the indexArtwork=auto with flowControl=2x
and saved.

Have I done the correct thing ? Will over-writing the indexArtwork=auto give other problems ?

Anyway, just tried it, and it stuttered on track 3 in a similar way to before.

So, setting it to flowControl=3x, save, clearing the tracklist select a different album & trying again. Immediately stuttered. Clear tracklist, then go back to previous album, but track 3. Immediately stuttered. Clear playlist & re-browse to same album, go to playlist and press the arrow button instead of a track (plays list from start). Immediately stuttering.

It is the same story throughout - on 1st play, it gets a bit into the playlist, then fails.
Once failed, it stays in fail mode, stuttering on whatever is requested next - until it settles down for another few-tracks-then-fail.

My partner says she doesn't have a clear mental picture of which part of the steaming chain does what, and I have to concur - I'll probably start a new thread along those lines. For example, once Bubble has presented a playlist to Minim, those commands execute and steaming starts, is it Bubble that controls the streaming flow or a combo of that and Minim ? My partner asks, if the phone with Bubble on it goes out of range, does the stream stop ?

simoncn

(Yesterday 17:15)windbag Wrote: My partner says she doesn't have a clear mental picture of which part of the steaming chain does what, and I have to concur - I'll probably start a new thread along those lines. For example, once Bubble has presented a playlist to Minim, those commands execute and steaming starts, is it Bubble that controls the streaming flow or a combo of that and Minim ? My partner asks, if the phone with Bubble on it goes out of range, does the stream stop ?

In standard UPnP, it works like this:

1) The server sends a list of track URLs to the control point (BubbleUPnP) together with other metadata
2) The control point tells the renderer (Sonos) to play one of these URLs
3) The renderer reads the audio data from the track URL (i.e., from the server) and plays it. The control point is not involved.
4) Shortly before the end of the track, the control point sends another URL to the renderer for playing when the current track finishes
5) Steps 3 and 4 are repeated until the control point's playing queue is empty

The control point is not involved in step 3. However, the control point can choose to become involved by sending a proxy URL to the renderer in step 2 instead of sending the URL provided by the server. In this case, the renderer reads audio data from the control point and the control point reads audio data from the server and manipulates it in some way before passing it on to the renderer. For example, if you have configured BubbleUPnP to transcode the audio data, this is how it happens.

If the control point is not available for any reason (off or out of range), the current track continues to play (step 3) but track advance (step 4) won't happen. Also, URL proxying (if in use) won't work, so the track would stop playing part way through after any buffered data has been played.

As using the 2x and 3x settings has made things worse, it does sound like there is a blockage somewhere in the chain between the server and the renderer. MinimServer is definitely sending all the data requested.

You can confirm whether there is any URL proxying by checking the IP addresses of your devices. In the log you sent, the device reading the audio data from MinimServer has the IP address 192.168.0.72. If this is the IP address of your Sonos renderer, there is no URL proxying. If this is the IP address of the phone running BubbleUPnP, this means that URL proxying is happening.