Skip to main content

It’s been confirmed by Sonos that “local Music Library is not going anywhere, though SMBv1 support has been permanently removed. Local Music Library searching is something that is still being worked on”.

And on the roadmap that’s been shared, it states “Local music library search and playback: mid-June”.

Now that SMBv1 has been disabled for music libraries, can we have confidence that the issues with SMBv2/v3 indexing will be resolved when the update does arrive?

I have just tried adding my music folder which lives on a USB drive in my Asus XT8 mesh router. I have forced the router to use SMBv2 for the drive, and I am still seeing the ‘//path’ is no longer available message when indexing fails after a reasonable amount of time. Chunking my music up into groups of folders occasionally allows me to add a smaller folder, but then I see the error message again. And after that, nothing can be added.

I had previously raised this in the post below (pre-update).

Have SMB V2 V3 music library issues been resolved yet?

The use of SMBv1 has been the workaround for this issue for over two years. Please can we have some indication that the indexing issue is being resolved now that SMBv1 has been disabled?

Thanks

Please can someone comment on my query. While I use other services, it will be good to know that my full library will be indexed and available mid-June.

Thanks

As users we don’t have much to say that hasn’t already been covered in other topics.

Sonos Staff have little information and are likely buried in other issues so I wouldn’t expect a lot from them here.

Calling in, looking at other topics, doesn’t seem to be a good option either.

I’m not happy but for now I’m sitting this out, hoping things improve and we get more information.

I am also having trouble indexing my library through an ASUS router (RT-AC3100) using SMBv2. (I am attached to an external USB hard drive.) The router log reports:

smb2_validate_message_id: client used more credits than granted, mid 1026, credits_granted 0, seqnum low/range: 1026/0

I take this to be an error message. The Windows-based SONOS application reports that the disk drive is inaccessible (when asked to index it). I spent about an hour with support yesterday with little effect. I don’t believe I will do the same again. 

I think this may be a bug (or feature in Sonos-speak).

 

 

 

Now that SMBv1 has been disabled for music libraries, can we have confidence that the issues with SMBv2/v3 indexing will be resolved when the update does arrive?

 

To clarify for completeness: SMB 1 has not been removed for S1; my NAS still works fine, I have never left S1.

If you are not on S1, roll back to S1 has been barred, and will be re opened by Sonos at some unspecified time in the future.

When that bar is removed, those that can use S1 should have a fully functional NAS that uses SMB 1, for those that choose to use it.

I am also having trouble indexing my library through an ASUS router (RT-AC3100) using SMBv2. (I am attached to an external USB hard drive.) The router log reports:

smb2_validate_message_id: client used more credits than granted, mid 1026, credits_granted 0, seqnum low/range: 1026/0

I take this to be an error message. The Windows-based SONOS application reports that the disk drive is inaccessible (when asked to index it). I spent about an hour with support yesterday with little effect. I don’t believe I will do the same again. 

I think this may be a bug (or feature in Sonos-speak).

 

 

Good idea to check the router error log. I see the same message except I have 1025 where you have 1026. So we have a clear error, and Sonos has already acknowledged it, so we just need to wait for a fix

Unfortunately there are 2 sides to smb credits, which are defined in the MS docs.

The client, Sonos can request a number of credits, and the server, in this case the Asus router, can change how many are granted vs requested. Available credits isn’t all on the Sonos side to control and specifically from Microsoft docs

  • The server MUST ensure that the number of credits held by the client is never reduced to zero. If the condition occurs, there is no way for the client to send subsequent requests for more credits.

So if the client, Sonos, has 0 credits, the server, Asus Router has failed in its requirement to prevent it happening.

Yes there are bugs to fix, but it isn’t as simple as a one and done Sonos need to fix it and it works forever for everyone. It will more likely be a combination of a client and a server bug, or even just a server bug for a particular type of device.

 

Thank you @sigh for the detailed response. You clearly know your stuff 🤓

If you keep up with the defect investigation, a job at Sonos awaits!

What you say does make sense. Hopefully this can be progressed and we get some feedback. It’s not impossible that it’s resolved mid-June with the library updates.

Terms & ConditionsCookie settings