Minim stream being throttled on QNAP NAS ?

[windbag]

(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]

(30-11-2024 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.

[windbag]

(30-11-2024 18:19)simoncn Wrote:  In standard UPnP, it works like this:...

Thanks or the great amount of detail, simoncn.
A whole load of questions come to mind, but I'll leave those to another post.
First I'll report other findings.

(30-11-2024 18:19)simoncn Wrote:  ...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.

That is my phone => URL proxying is happening
What is governing this and what are the implications of that ?
Does this mean that Bubble on the phone IS doing transcoding?

My main music database, where I rip my CDs to directly, is currently 1.02 TB with over 100k files in it. I rip CDs to album-based folders with FLAC & Mp3 as the main output into my main music database. I've always ripped to flac for fidelity when needed, and VBR mp3 to get the best lossy quality while keeping size to a minimum. Embedded artwork is limited to 30kB per track.
Currently, the full database has over 24k flac files (719GB) & almost 32k mp3 flies (230GB).
A big aim is to use m3u files as my preferred selections by artist, the equivalent of how I used to make cassette tapes.
One aim was to have my music available in the car and/or on the phone, where quality is not paramount, but storage is at a premium - so a subset of that full database is needed.
I make a separate extract for that by copying just the mp3 and m3u files to an extract area - almost exclusively VBR mp3 files.
It is that smaller area that I had hooked to Minim as the contentDir. This worked well until about 6 weeks ago, when the stuttering suddenly started.

As recent efforts to try & cure this failed, in a last resort I threw the full music database as the contentDir.
Minim still scanned OK, and not surprisingly, Bubble took somewhat longer to give the folder view. Trying similar mp3 files to before, stuttering was a bad as ever.

A new option was to play the flac files.
The first set played perfectly.
So did the second.
So have a few others.

So, there is NO inference affecting the Sonos units.
Whatever is making the stream from the the VBR mp3s must be suspect in the stuttering. The Sonos have been playing these for years without issue & have not been updated, so they can't be the source of the issue.

One important note was the Bubble display in 'Now playing', which showed as WAV 44.1kHz - whereas the stuttering VBR files were FFMpeg-based.

Another thing I did was to specifically make a fixed-rate 192 kHz mp3 set of album tracks to see how they played.
Those, too stuttered.

I made a quick dive into the Bubble settings, and realised I left them in a state where they initially worked, but had little idea of what was optimal.

In particular, having to play to the lead SONOS in a group as the target meant that if the Sonos units had been grouped so that a different unit was 'the lead', then the ability of Bubble to have different settings for every Sonos target meant that Sonos regrouping could give a totally different performance.

Crucially, the Renderer setting for FFmpeg audio decoding was set as 'formats not natively supported' rather than Never Use or Always Use.
My recollection is that Sonos reports to Bubble that it can't use some of the normal formats, so perhaps that is why I'd left on the setting I found - and what it was actually doing is not clear.

Similarly, the max supported sample rate was 192 Khz. Whether this should be unlimited or 44.1Khz is not obvious.

So when I said I hadn't set up transcoding on Bubble, it looks like that was incorrect.

I guess I need to switch to the Bubble forum to try and work out what all those renderer settings ought to be, unless anyone here already knows.

[simoncn]

(01-12-2024 22:07)windbag Wrote:  I guess I need to switch to the Bubble forum to try and work out what all those renderer settings ought to be, unless anyone here already knows.

I think this is the next step. The log you sent showed that MinimServer is delivering the original MP3 audio correctly to BubbleUPnP, so the problem must be related to the processing/transcoding that BubbleUPnP is doing to the audio stream before sending it to the renderer.

[simbun]

(01-12-2024 22:07)windbag Wrote:  I guess I need to switch to the Bubble forum to try and work out what all those renderer settings ought to be, unless anyone here already knows.

Having only CD quality rips my Sonos configuration is:
FFmpeg Audio Decoding: Never use
Gapless control: Enabled
Use Eventing: Enabled

I use this configuration to make sure Bubble doesn't perform any transcoding. If I need to transcode I'd rather use MinimStreamer/BubbleUPnP Server.

This should work with FLAC/MP3 up to 24/48.

[windbag]

(02-12-2024 00:08)simbun Wrote:  ...my Sonos configuration is:
FFmpeg Audio Decoding: Never use
Gapless control: Enabled
Use Eventing: Enabled
...
This should work with FLAC/MP3 up to 24/48.

Thanks for that advice, simbun. I've just got a regular mp3 to play OK after switching off FFmpeg Audio Decoding.
I'll see if that cures the issue with other playing scenarios.
Sorry for being thick, but what does the 24/48 mean ?

(02-12-2024 00:08)simbun Wrote:  I use this configuration to make sure Bubble doesn't perform any transcoding.

I think part of my misunderstanding is the terminologies, as Bubble doesn't use the term transcoding, just decoding.
I also might have used the FFmeg option as it implied that the it enabled the volume control on the Bubble Now Playing display

(02-12-2024 00:08)simbun Wrote:  If I need to transcode I'd rather use MinimStreamer/BubbleUPnP Server.

I've wondered about putting BubbleUPnP on the NAS, but had assumed it meant that the main 'playing control' route would then have to be via the NAS interface rather than the phone, which wouldn't work - and add more complexity to the setup
Have I got that wrong/is there a guide to (any advantages of) using a Minim/Bubble combo on the NAS ?

[windbag]

(30-11-2024 18:19)simoncn Wrote:  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...but track advance (step 4) won't happen.

Translating that sequence by swapping
server=>Minim, control point => Bubble, renderer => Sonos, I get :

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

Step1-That can't be the first step, as Minim doesn't know anything about the playlist now required until Bubble sends it that info.
Are the server and control point assignations the wrong way round in points 1&2 ?
They seem the right way round in 3 & 4

Similarly:

Bubble is not involved in step 3. However, Bubble can choose to become involved by sending a proxy URL to Sonos in step 2 instead of sending the URL provided by Minim. In this case, Sonos reads audio data from Bubble and Bubble reads audio data from Minim and manipulates it in some way before passing it on to the renderer.

Yes, that makes sense as, for the current 'lead' Sonos in the current group, I had FFmeg audio decoding switched on in Bubble, making it 'become involved' in the proxy issue.

It does make it VERY important that all my Sonos units have the same settings in the Bubble Renderer selection. Without it, making the 'same' Sonos group with a different 'lead' unit could give totally different results !
As the Sonos all too frequently has a strop and breaks apart existing groups, I wonder if this might account for the unexpected change in behaviour about 6 weeks ago.
ie I just regrouped the Sonos after a split and chose a different lead Sonos for the same group combo, but had a different renderer setting in Bubble.

[simbun]

(02-12-2024 14:08)windbag Wrote:  Thanks for that advice, simbun. I've just got a regular mp3 to play OK after switching off FFmpeg Audio Decoding.
I'll see if that cures the issue with other playing scenarios.
Sorry for being thick, but what does the 24/48 mean ?

24bit/48KHz is the maximum supported resolution that Sonos supports (CD is 16/44.1). If you want to play a file "greater" than that e.g. 24/192, then you'll need to transcode it to a lower resolution.
In an earlier post you said that you converted an MP3 to "fixed-rate 192 kHz mp3", but I think you meant 192kbps. If the source of all your music is CD and it's stored as FLAC/MP3 then you don't need to worry about transcoding/decoding.

(02-12-2024 14:08)windbag Wrote:  I think part of my misunderstanding is the terminologies, as Bubble doesn't use the term transcoding, just decoding.

Think of decoding as turning it back to PCM (CD standard), whereas transcoding is converting it from one format to another e.g. FLAC to MP3.
Most players support PCM, so if a renderer doesn't support a format e.g. OGG, the simplest thing to do is decode it to PCM and send that.

(02-12-2024 14:08)windbag Wrote:  

(02-12-2024 00:08)simbun Wrote:  If I need to transcode I'd rather use MinimStreamer/BubbleUPnP Server.

I've wondered about putting BubbleUPnP on the NAS, but had assumed it meant that the main 'playing control' route would then have to be via the NAS interface rather than the phone, which wouldn't work - and add more complexity to the setup

There's an additional component called BubbleUPnP Server that can be used to proxy your Sonos speakers so that the playback queue is held on BubbleUPnP Server rather than in the BubbleUPnP app on your phone. The advantage of this is that BubbleUPnP Server can handle multiple queues unlike the BubbleUPnP app so you can control multiple renderers at the same time.

Current process:

Code:

MinimServer -> BubbleUPnP (for browsing) <-> Sonos (for track progress and transition)
MinimServer ->                               Sonos (audio path)

With BubbleUPnP Server

Code:

MinimServer - > BubbleUPnP (for browsing) <-> Sonos Proxy (held in BubbleUPnP Server) <-> Sonos (for track progress and transition)
MinimServer ->                                Sonos (audio path)

The only change you'll need to make in BubbleUPnP (the app) is to play to the proxied Sonos renderer (same name suffixed with '(OpenHome)'), rather than the Sonos renderer itself.

[simoncn]

(02-12-2024 14:44)windbag Wrote:  Step1-That can't be the first step, as Minim doesn't know anything about the playlist now required until Bubble sends it that info.

This is the first step that is relevant to your scenario. In more detail, step 1 includes the following substeps:
1.1) The user uses the control point to browse or search the library to find an album, track or playlist that they want to play
1.2) The server responds to the browse and/or search requests by sending metadata encoded as DIDL-Lite. This metadata includes track URLs.
1.3) The control point decodes this metadata and displays the relevant elements on its display
1.4) The user selects Play in the control point to populate its playing queue

Quote:Are the server and control point assignations the wrong way round in points 1&2 ?

No, see 1.2 above.