@Stanley_4 all that being on a Synology NAS using SMBv2/v3 ?
And today I took my iPod 4 out of storage (used only to trueplay Sonos) for charging and updates and noticed I had album art. Checked my Android tablets and it was there too.
Aside from connecting with the iPod no changes were made (not even an auto index) aside from just time passing.
NTLMv1 Authentication was required for Sonos when using SMBv1 on DSM 7.0.1
Hi @el rubio
No, I didn’t turn off the NTLMv1 Authentication - I didn’t even know it was there, let alone what it does!
Cheers,
John
@jreddaway thanks for the feedback - did you also disable the NTLMv1 Authentication (under Advanced Settings - Other)?
The 13.4.1 system update has sorted the Album Art issues for me although, subjectively, it appears to be a little bit slower than before in serving up the images. Maybe it needs a little time to propagate, as I have rebooted the NAS after changing the file system settings and re-indexed the music library, so we shall see….
I have changed the SMB service settings on my NAS to switch off SMB1 (now running “SMB2, SMB2 and Large MTU, SMB3”), so the security worry is gone too.
Good work, Sonos. Thank you.
I surrender, temporarily, I finally gave up hope of ever seeing a ReBoot option come back and ordered some switched power cords from Amazon.
One more trip behind the heavy furniture, this time to install the switches instead of just un and re plugging my Sonos.
https://smile.amazon.com/gp/product/B000KKND86/ref=ppx_yo_dt_b_asin_title_o00_s00?ie=UTF8&psc=1
We shall (in a few days) see if a full system reboot gets the new App to show cover art.
Well rats, no art here.
I’ve been checking for updates and it finally showed up so I updated. Didn’t get album art.
Reset the SMB server to SMB 3 and verified my connection as SMB3_02. Still no art.
Did a reindex. Still no art.
Power-cycled one speaker, the one I was connected to. Still no art.
Sigh… Life has other demands so I’m out for a while.
I think the reason there’s been little reaction is that it’s a unique (well, at least very small) issue with something on your specific computer, and not something that occurs to the vast majority of users. And as such, likely extremely hard to track down without lots of specific data from your computer. And some of that data may not show up in a diagnostic, I’d think, because those are focused on the operation of Sonos, and not the actual install process.
If I were to hazard a guess, and I emphasize the randomness here, it could be an issue with a .dll not being properly updated/initialized, etc. And since it’s not technically with the Sonos app itself, it’s not showing up in the diagnostics.
This thing with the Sonos installation rebooting Windows have been there for a long time, but it is not always happening. I raise a thread on it a couple of years back, but there was little reaction.
Yes, I see cover art after the update. Now, the past weeks it has been on and off, so it may be a bit too early to say for sure.
You're right: let's not get ahead of ourselves. We'd better see how things develop. I'm optimistic, though.
And, yes, the installation of the Windows controller rebooted Windows, without giving a warning.
That's strange, my Windows 11 PC didn't reboot after having updated the Sonos Desktop Controller. It never has, I add, after a Sonos update.
Yes, I see cover art after the update. Now, the past weeks it has been on and off, so it may be a bit too early to say for sure. However, I also see cover art when browsing albums, which I never did with 13.4 (unless I disabled SMB2/3 on the NAS). But as florismk notes, the cover art is coming quite slowly. I don’t have any issue with dark mode on my Andriod phone.
And, yes, the installation of the Windows controller rebooted Windows, without giving a warning.
Album art issue is definitely still present in 13.4.1. Also, Sonos no longer switches to Dark Mode to match Android, and the Appearance setting that's supposed to control this has vanished. Thus far, not impressed with 13.4.1.
Sounds promising! I will have to find a spot for upgrading the system. That is, I need to close down stuff on my Windows machine, in case the upgrade decides to reboot Windows. Which it often does - without asking.
Can confirm @beynym's update: update 13.4.1 was offered (Android controller, Windows controller, and system). Album art still erratic though. Slow to load and far from complete in the Android controller, very slow to load but eventually complete, apparently, in the Windows controller.
It may be significant that my Windows controller is connected to the Beam, which lies in close proximity to my router, while the Android controller insists on being connected to the One, which is much further away.
I'm happy to report that my system just updated to 13.4.1 and my cover art has returned.
Contacted chat support to add my case to the growing body of issues. Support asked for new diagnostics, submitted 547048099. Keeping my original thread up-to-date as well.
Got another confirmation that the issue is related to SMB2/SMB3, and that engineers are working on a solution with an unknown ETA.
I get the feeling that we are ‘guinea pigs’ and used as an extended test group across different continents to escalate which features are mostly not working
One of the issues on teams I’ve worked on is that often people forget to make allowances for what are considered in the US “non-standard” characters, such as many languages around the world actually use, and are considered “standard” there.
Not sure whether that’s the case here, just an example of unintentional bias that might not be caught by the assumed “small” number of beta testers.
I can’t really see that this the issue in this case. But interesting enough, the issue I ran into in May was exactly that. Sonos One SL players botched non-ASCII characters when they indexed the music library. But for folder problem, I have not see any such correlation.
One of the issues on teams I’ve worked on is that often people forget to make allowances for what are considered in the US “non-standard” characters, such as many languages around the world actually use, and are considered “standard” there.
Not sure whether that’s the case here, just an example of unintentional bias that might not be caught by the assumed “small” number of beta testers.
On the other hand, I think they knew there were potential issues and decided not to make a public announcement. There were many a time when I was unaware of issues, and made the announcement in public about the feature, only to be inundated with “but it doesn’t work on my machine” from many customers. My guess is that’s why there’s currently silence. They, at the last moment, figured out there were issues, and it was too late to pull back the release, but they were able to not make a public announcement around the feature.
All of that blows up as soon as the phone folks have told people about the feature, as indicated in previous posts, but, at least in orgs I’ve been in, CS is a different group than forum support folks, so there could have been a message that got lost between the various groups as to whether or not to talk about it.
This is all speculation on my part, mind you, based on several decades of software experience. It could be something much more nefarious….but I just have a hard time believing Sonos would be intentionally screwing its customers. It’s bad business to do that.
Hi
@Airgetlam makes a valid point about “bugs” and how they are discovered and subsequently resolved. It’s important to understand that when dealing with multiple types of end-user hardware; testers look at general realities that cover most scenarios in the real world. There will always be those one-off scenarios that weren’t covered.
For example…writing code to auto alphabetize common last names that works 99.9 % of the time; but fails when a hyphenated last name is introduced. That’s a bug that the code writer didn’t take into account and therefore must enter a “what-if” line to fix the bug encountered by the end-user of the software.
As mentioned by @Airgetlam …that’s probably the case here-in-point.
Most likely why Sonos hasn’t ‘announced’ the SMB version upgrade. It appears to be mostly, but not completely, working. I’d imagine their engineers are working overtime trying to figure out this issue, which may not have shown up in beta testing, given the numbers of people testing. At least, having run a fair number of betas for gaming software and not having a bug show up until it was released to everyone, that is what I’d assume.
PS: Setting the NAS to use only SMBv1 did solve the album art issue. But in order to be able to access my NAS from Windows 10, I had to re-enable SMBv1 in the OS, and even then Windows had issues accessing the shared folders on the NAS. And with the strongly worded Microsoft blog piece on the reasons why we should no longer use SMBv1, I've decided to accept the album art issue for now, and wait for Sonos to fix the SMBv3 issue.
On the upside, did discover that my NAS was still set to support Apple and Linux protocols, so switched those off.
Chiming in late to the party to report that on my Synology Diskstation, I have the same issue, though oddly enough only in the Android controller; the Windows Desktop controller shows artwork. Full report here; diagnostics 89729938; thanks to @buzz for pointing me to this thread. I've set my NAS to use only SMBv1 (though I remember reading that this is unwise for security reasons). Album art is now showing up in the Android controller, after a library index refresh (same effect as right after I prioritized Sonos and phone in my Wifi router). Hoping for a quick fix, because if there is a security issue with SMBv1, I'd rather switch back soon.
What surprises me most about this issue is that the album art display was so erratic. Without closing the controller on my phone, over the course of the same day, I can see some artwork showing in the morning, disappearing in the afternoon, and showing again in the evening. I wonder why Sonos doesn't just have the controller cache the artwork?
Yes. I think that it is a little unreasonable. Sonos 13.4 has not been out for two weeks. I started this thread nine days ago. Also, recall that Sonos are located in the US where the passed week was a short week due to Thanksgiving.
To compare, I started thread on a broken update in May, and in this case it took 13 days before from someone Sonos appeared in the thread and confirmed that there was an issue. It took a couple of releases until a fix appeared. That issue only affected Sonos One SL, but in a way it was more severe, as some music files were rendered inaccessible. This time it is after all only cover art.
I also like to point out that Sonos has already confirmed the issue. Even if they have not posted directly to this thread, others have relayed the information.
As for a fix, I can see three options:
- Roll back on SMB2/SMB3 support. That should be easy, but there could other improvements that are dependent on this support, so they may not want to do that.
- Gives us in option to disable SMB2/SMB3. That would be a very un-Sonos thing to do.
- Actually fix the issue. This is of course the desirable long-term solution, but it may also take longer time to roll out.
And, again, it’s only cover art. When I started this thread, my main concern that Sonos might have decided not support folder.jpg at all. I can live with not always seeing covert in my players for a month or so.