Minim stream being throttled on QNAP NAS ?

[windbag]

Thanks again simbun, yes I realised you were not Simoncn, just wanted to thank for folks taking time with my query

(25-11-2024 18:53)simbun Wrote:  the last time I tried, if I played to one of the slaves it played from just that speaker, but things may have changed.

I just re-tried it, and you're right - except it splits that selected Sonos from the group. In this instance the group was already streaming radio from outside, and the remaining 3 in the group kept doing so.
It seemed to then stream OK, but broke down at track 4. A common observation is that, once it breaks down, it can hardly play anything. Clear playlist, try different album (yes, this has happened with at least 20 diff albums since it started), it just coughs and splutters and skips tracks.
I did grab some more resource screens during the process. You can see the Network usage spikes piling up after the first failure.
After clearing the playlist, then browsing on the phone to use a different album of music, I got a new-to-me error:
Current state of service prevents this action. Connection error or no response.
Bit disconcerting as the phone and target Sonos are next to each other (both about 10 feet from WiFi repeater)
By the time I'd written that down, browsing then worked again, but it was now in a won't play-anything state again - that was when all the Network Usage spikes came forth.

(25-11-2024 21:28)windbag Wrote:  Does the MP3,128 kbps,stereo,44100 Hz, indicate it IS being re-coded ?

(25-11-2024 22:22)simbun Wrote:  It only indicates transcoding if the source file isn't MP3@128. Try doing the same on a track you know is of better quality.

Almost exclusively, my files are Mp3 VBR, so not exclusively 128 kbps. So I wondered if transcoding were making them to a steady 128. I could make a special 128 or 256 kbps files for testing, I guess.

(25-11-2024 22:22)simbun Wrote:  If you click on the track's URL in BubbleUPnP does it download successfully, and, with the local renderer selected, does it play back successfully in BubbleUPnP?

Just tried that. Seemed to stick a couple of times then played fine. But it can do that anyway, so could be a fluke? So, just tried another track from a different album and that just payed fine.

(25-11-2024 22:22)simbun Wrote:  I guess you could put the log in [debug]mode

If still a good idea, would that be .loglevel=debug ? (zip need noted)

[windbag]

(25-11-2024 22:10)simoncn Wrote:  How is your QNAP connected to the SONOS over your network? Can you try changing this? For example, if this is a wired connection, can you try wireless instead (or vice versa)? I think the issue is probably with your network connection rather than something on the QNAP.

Thanks again, simoncn.
My house has an ethernet backbone, but it can't cover the whole house.
The router, PC, laptop, QNAP NAS are directly connected, as is one Sonos unit that I don't often use directly for output (near the TV via a port switch).
My recollection when setting up the (now old) Sonos system was that it was temperamental about multiple connection to the ethernet backbone. I seem to remember it failed if more than one unit was directly connected, as it wanted to assign one unit as the main internet connection.

In my instance, I could theoretically connect up to three directly, but the other four are located too far from the backbone - but all 6 without direct connection have always worked OK when grouping using the internal Sonos grouping-mesh facility, with no sign of this stutter-stream fail before.

I can try connecting two more, but have a horrible feeling the Sonos may go off and sulk in a corner ;-)

[simoncn]

Frrom everything you have said it sounds like the problem is on the Sonos side of things rather than the QNAP/MinimServer side of things.

The difference between 128k and 256k MP3 files is not significant with regard to this issue.

You need to set .logLevel to debug on the MinimServer configuration web page to create a debug log. To ensure the log file doesn't contain unnecessary output, do the following:

1) Start MinimServer with the default logging level (info)
2) Before playing the test tracks, set the logging level to debug
3) As soon as you get a couple of failures, set the logging level back to info and make a copy of the minimserver.log file
4) Zip/compress this copy and post it here

I think the log will show that the Sonos renderer is closing the connection before streaming of the track is complete and possibly retrying streaming the track a few times. It would be good to have definite confirmation that this is happening.

[windbag]

Thanks, simoncn

(26-11-2024 22:24)simoncn Wrote:  ...
2) Before playing the test tracks, set the logging level to debug
3) As soon as you get a couple of failures, set the logging level back to info and make a copy of the minimserver.log file
4) Zip/compress this copy and post it here

For info I made these plays:
1) a new album, 1st track seemed OK so cleared playlist and browsed to
2) almost new album that has been tested in earlier posts
- immediately stuttered so cleared playlist and browsed to
3) slightly older album. Immediately stuttered, so cleared playlist and browsed to
4) album 1. Now stuttering. So carried out the logfile instructions.

Ironically, the new album is now playing without issue as I type this... update - it has just stopped on track 4, skipped to track 5, 6 & now 7, so is behaving like most other recent playlists.

Zip attached but original file made for 1674 kb which is too big.
Opening it up, it seems to be carrying all the earlier issues with artwork, as about 90% of the file.
So I edited the middle bit with the
Warning: ignoring additional ID3v2 tag
etc entries, leaving the header and the recent entries with times on them, bringing the zip down to 18kb. Please advise if I've hacked out too much

(26-11-2024 22:24)simoncn Wrote:  Frrom everything you have said it sounds like the problem is on the Sonos side of things rather than the QNAP/MinimServer side of things.
The difference between 128k and 256k MP3 files is not significant with regard to this issue.

Our Sonos is used to stream UK Radio4 pretty much 24/7 (which stops when Bubble takes over). In the past, have tried several radio bitrates, all of which worked, and continue to do so, without any such stuttering - so there is no major interference when the stream is originating from the internet - which I'd have guessed was more prone to interruption. I do understand that there are no "play new file" commands that way, but it is odd that any interference only affects that specific bit of data exchange.
It is the ongoing capability to stream from the internet without issue that made me question whether it was a Minim issue. Could it be a Minim file corruption? Could deletion/re-installation help ?
Hopefully the log file may shed some light.

[simoncn]

Thanks for this log and the information about how it was produced and what files were played.

The log shows that MinimServer is working correctly. It received requests from the renderer to stream 10 audio files and it responded correctly to all these requests. There were also a number of requests for artwork images. In some cases there were two requests for the same audio file: a probe request and a play request. The details of the audio file requests are shown below (scroll up and down to see all 10 audio files):

Code:

The Sun King/01_Distant Land.mp3
probe request at 12:13:04.876
play request at 12:13:06.093 (1 second later)

The Sun King/02_As The Crow Flies.mp3
probe request at 12:13:09.731

04_The Murder Wall/11_A Silent Drum.mp3
probe request at 12:15:52.570
play request at 12:15:53.702 (1 second later)

04_The Murder Wall/13_A World Beyond Man.mp3
probe request at 12:15:57.437
play request at 12:16:55.720 (58 seconds later)

04_The Murder Wall/05_Another Man's Smile.mp3
probe request at 12:16:58.291

04_The Murder Wall/11_A Silent Drum.mp3
probe request at 12:17:10.444

02_Depth of Field/01_Rosherville, Part 1.mp3
probe request at 12:17:33.605
play request at 12:17:34.837 (1 second later)

02_Depth of Field/02_Holywell Street.mp3
probe request at 12:17:40.009
play request at 12:18:04.354 (24 seconds later)

02_Depth of Field/03_Ghost Planes.mp3
probe request at 12:18:08.229

The Sun King/01_Distant Land.mp3
probe request at 12:18:57.999
play request at 12:18:59.436 (1 second later)

The probe request is reading information about the file. The play request is actually playing the file. Having both of these separated by about 1 second seems like normal behaviour.

The log doesn't show why the renderer failed to play the files despite receiving correct responses from MinimServer to all requests. A possible explanation could be that the renderer cannot cope with receiving large amounts of data in a short time. For example, the play request for the first file sends 7945700 bytes of data in 14 milliseconds, which is equivalent to 7945700 * 8 * 1000 / 14 = 45400400k bits per second. The renderer should be buffering and/or throttling this data and playing it at 128k bits per second but it might have bugs that prevent it from doing this correctly in some circumstances.

In contrast, audio data from the Radio 4 live stream arrives at a steady 320k bits per second and is played back at the same speed, so very little buffering is needed.

This problem has occurred in the past with some faulty renderers, so MinimServer provides a way to work around it by using the flowControl option of the serverOptions property. For example, if you set this option to flowControl=2x, MinimServer will slow down audio data sent to the renderer to an average rate of twice the playback rate. If you set this option to flowControl=3x, the data rate will be three times the playback rate, and so forth. It would be worth trying this to see if it helps.

[windbag]

Thanks for looking at the log and diagnostics

(27-11-2024 18:03)simoncn Wrote:  ... A possible explanation could be that the renderer cannot cope with receiving large amounts of data in a short time. For example, the play request for the first file sends 7945700 bytes of data in 14 ms...=45400400k bits per second....
MinimServer provides a way to work around it by using the flowControl option of the serverOptions property...set o flowControl=2x...slow down audio data sent to...
twice the playback rate...flowControl=3x...three times the playback rate, and so forth. It would be worth trying this to see if it helps.

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.

[simbun]

@simoncn,

I don't know if it'll be of any use but here's a debug log of playback to a pair of Sonos PLAY 1s using BubbleUPnP.

I don't have any MP3s but I can convert some if you think it's somehow size/format related.

[simoncn]

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

[simoncn]

(28-11-2024 12:40)simbun Wrote:  @simoncn,

I don't know if it'll be of any use but here's a debug log of playback to a pair of Sonos PLAY 1s using BubbleUPnP.

I don't have any MP3s but I can convert some if you think it's somehow size/format related.

Thanks for this. It shows two differences from @windbag's log:

1) The renderer doesn't read the whole file while probing. This is because the FLAC file is much larger than an MP3 file, so reading stops after sufficient probe data has been analysed. This difference should not be significant.

2) A different renderer is being used for the play requests.

Your renderer's user-agent string is this:
Linux UPnP/1.0 Sonos/81.1-58210 (ZPS1)

@windbag's user-agent string is this:
Lavf/60.16.100

This presumably means you are using a different (later?) version of the Sonos firmware. This difference is likely to be significant.

[windbag]

(28-11-2024 14:32)simoncn Wrote:  You can activate the free 30-day trial license to try this. This provides all the functionality of a full license.

Thanks. I'll try this tomorrow morning & report on any change