Skip to main content

I select a folder with some 24 tracks in it.  The folder is on a Network Attached Storage (NAS) device I have my music on.  I start to play them.  All goes well.  I select shuffle and repeat (not repeat 1).  I expect the 24 tracks to be played indefinitely or until I stop to play.  This is within the Sonos app running on an iPad.  The app stops playing the tracks after some seemingly random amount of time and tracks, frankly I am not even sure, I have not checked it yet, if it plays all the 24 tracks at least once before stopping.  When it stops, the queue points to a track in a middle of the list.  I can press play and the app will restart playing the tracks but it will stop again sometime later.    To sum up, no other apps or services are involved, only the Sonos app and a folder on a NAS device.

Please help.  What can I possibly be missing here?  This, to me, is a very basic function.

Seems odd. I’m, of course, assuming you mean tracks, and not trucks. I’m certainly not experiencing this issue, although I have a lot  more than 24 tracks. I’m using S2 on an iOS device, and a WD NAS, which Sonos is reading via SMB v3. Have you tested not using the ‘random’ function, to see if it plays through the 24 tracks?

Which controller are you using? Have you submitted a system diagnostic within 10 minutes of experiencing this problem, and called Sonos Support to discuss it? Don’t post the resulting diagnostic number here, they get sensitive about GDPR.

There may be information included in the diagnostic that will help Sonos pinpoint the issue and help you find a solution.

When you speak directly to the Support staff, they have tools at their disposal that will allow them to give you advice specific to your network and Sonos system.

 


Thank you Bruce.  Correct assumption, tracks, no trucks, my bad 🙂.

I am also using S2 and my NAS is a Synology one. 

Good idea about submitting the diagnostics.  I’ll do it next time it happens.  I’ll also try your idea to play the list without using the shuffle function on it.  I called Sonos support but they just got me to do a basic “manual” check with selecting the last track in the list, advancing it nearly to the end of that last track and then making sure that the first track plays next.  That worked as expected.  Funny, I though that every time the entire list finishes to play the app would re-shuffle the list.  Looks like I was expecting too much 🙂.


I haven’t shuffled a list in a while. As I recall the list is shuffled as you execute the command. If you repeat the list, it will not reshuffle. The tracks will play in the same order until I execute the shuffle command again. You should check me on this.


I suspect you, buzz, are right. 

BTW, I started the play the folder again and, after playing for a while, it stopped at what looks like time 0 of the first track in the shuffled list.  I submitted the diagnostics and will call Sonos tomorrow.  I’ll try to play the list again without shuffling it this time.


I (in concept) disagree, although I’ll admit it’s based on memory, not current experience ;)

If I recall correctly, each time you hit ‘randomize’ it re-randomizes the order of the tracks. I suspect tied to a random number generation, with each track assigned (previously) a number. So, it does reshuffle. 

For ​@panap , no worries, typos and autocorrect ‘mistakes’ are common for me. If you watch my posts in the first minutes after they’re posted, you’ll often see ‘corrections’ for my mistakes. Which tend to be many!

What you’re dealing with is fairly esoteric, IMHO, for many CS reps, at least in my experience, many don’t truly understand, and are reading from a script, and doing pattern matching for the issue you’re experiencing. You may want to play ‘CS roulette’ before finding one who truly understands your issue. And certainly, a diagnostic or two would help. I’ve been lucky, each time I’ve needed to call in, I’ve reached someone who both understood the issue I was experiencing, and were able to provide a good solution. But, at least with other company’s CS, I’ve always been willing to terminate, and call back, to see if I can reach someone more ‘knowledgeable’. And frankly, I always call, I, as yet, don’t trust AI / Chat to be able to appropriately understand much of my issues, but then when I do call in, it isn’t for fairly ‘simple’ things. 

Were I you, I’d call during the week. Mostly because I’ve done scheduling in my life before, people who end up on the weekends tend to be ‘newer/less skilled’. Not bad people, just often less conversant with the subject matter. 

Good luck!


Heh. Our posts passed each other, likely while I was editing my post ;)


Thank you Bruce!

I just wanted a background music during a visit of our friends.  And then I started to notice that I had to restart the playing a few times during the evening at, what seemed like, different intervals (not 100% sure as I did not pay attention to the timing of it).  At this time, whether the list is shuffled once or each time it is replayed does not matter that much to me.  Using the “manual” walking through the list method suggests that the shuffling takes place only once, or, every time the shuffle button is reselected.

I could not agree more with your comments about the CS.  I’ll try to call them next time during regular business hours on a weekday.  Last time I called them on a Saturday.


One final comment (or two), then I’ll leave you alone ;)

To my knowledge, all of this is handled on ‘the player’ side, i.e. the speaker, and not in the UI part which is the controller. Again, to my knowledge, the controller was completely rewritten last year in a new code base, for version 80.x, but not, the Linux code running on the speakers. So the affects made by the crossed arrows (randomize) and circled arrows (repeat) shouldn’t be any different for either OS.

All that being said, it’s entirely possible a ‘bug’ has surfaced, and certainly your diagnostic should help, when received and processed, in tracking is there is an issue. My own experience with coders has suggested that hard diagnostic data beats anecdotal data for every programmer out there ;)

Please, keep us posted. I would certainly be affected by what you find out, although it’s relatively rare for me to re-randomize my playlist, and it’s large enough I’m not sure I’ve ever actually reached ‘the end’, give the frequency that I lose power here in the boonies. But knowledge is a great thing, IMHO, rather than supposition. 


The diagnostic may help, I've had playing stop randomly and it appeared to be communications errors.

Might. Want to look at the signal strength for each Sonos and see if any are low.


Hello,

I called Sonos two times today but the caliber of the CS representative was not as high as I would like it to be.  The representatives were nice and trying to be helpful but, at the end of the day, I am not getting much “real” help from them.  They put me through first rescanning the library and then removing and re-adding it.  It did not seem to have changed anything.  Well, at least I got a bit of more info from them into what is happening… 

The diagnostics did help.  First of all they confirm that the playing does stop.  Well, the first diagnostic confirmed that the playing stopped but they did not give me the reason why (and I forgot to ask).  Another diagnostic that I submitted today stated that a “resource was not found” and the CS rep explained that it means that a track file could not be found.  I suspect that all the diagnostics I submitted failed for the same reason but, I forgot to ask about the exact failure reason in the first set of diagnostics.

I started to look at it a bit more myself and I noticed that the folder I am trying to play has 26 mp3 and 1 m4a file, so 27 music files in total.  When I view the folder in the Sonos app I do see all 27 of these files.  When I start to play the folder, by selecting the first file in the folder, I get 24 tracks in the Sonos queue.  3 of the files are not added to the queue.  Why???  I see that these 3 missing files are the files I added to the folder less than a week ago (but the library was rescanned and even re-added).  Why are they not added to the queue?  I looked at the media info for these files and they do not seem to differ much from the other 24 mp3 files in the folder.  So this is mystery #1. 

Then there is one track in the queue that shows with no name and it cannot be selected.  When the queue plays Sonos app skips it, or at least this is what it did the time I was playing and advancing towards the end the previous track.  What does it mean to have a track/file like this in the queue?  I do not see anything strange in the name of that file.  This is mystery #2.

I suspect that that my issues may be related to the names or formats of the files, though I am not 100% sure.

Could you please comment on this?  What do you think could be happening here?

Thank you.


For mystery #1, perhaps Sonos doesn’t read those files, for some reason? Have you looked at the supported audio formats FAQ, and confirmed whether these files match properly?

For mystery #2, what happens when you ‘move’ the file out of the area where Sonos scans and plays from, temporarily (perhaps a ‘new’ folder on your desktop, so you don’t lose data), rescan, and re-attempt to play/randomize?


I've made copies of the problem files, all ripped flac, renaned them x1, x2, x3 and stripped out all the tags. A reindex and the x files all played so I named them back to the original names with a "-1" and reimdexed again, most played, a couple needed odd characters changed out. Did the same with the tags and ended up with all working.


I do think the issue is with the file names and or content (some “special” characters) in some tags.  I do not think it is the format.  The format is mp3 and the encoding parameters seem similar as in the working files.

Ahh…, I hate modifying the music files in such a way.  The problem is that all these files are in my iTunes library as well and I know that iTunes gets very “non-cooperative” when you modify a library file.  I have recently had issues with exactly this.  I modified the volume level in some music files and it messed up iTunes really badly.  Having a file with the same name but with different modification times caused problems of files not being found after syncing to phones and tables.  I ended up going file by file for the problematic files, removing them from the iTunes library and readding them.  This was pretty painful and time consuming.

On top of that I rely on some of the tags, like the “comment”, to be there as I use them in iTunes auto lists.  And, to make things worse, this is just one folder with 27 files in it.  I have tens of thousands of music files and no idea which ones may have the same problem.  Without knowing exactly what the issue is it nearly impossible to address it across the entire library as the problematic files can be present in many files in many folders.  Frankly, even if one knows exactly what the issue is, going through thousands of files to search for “problematic” characters in meta tags sounds like an awful proposition...

Hmm, not sure what to do.  Maybe I can try to press Sonos for more specifics about these 2 issues and what they choke on in terms of characters in file names and tags…?  Knowing exactly what the problem is would at least be a better starting point...

 


Don't modify your original files until you have found the exact issues with each that are causing the problems. Make and work with copies.

Forcing a reindex, then submitting a diagnostic followed by trying to play the problem files and a second diagnostic might capture the issue. Diagnostics capture a limited amount of data in a small window of time so one of each operation isn't a bad plan.

Once all are submitted CALL them in, that is almost always the best contact method.


So I put some time aside to experiment a bit before calling Sonos.  The idea, as you suggested, was to create a copy of one of the 3 excluded by Sonos files with a different name and then to start removing the different tags from this file while trying to play the entire folder after each change, until the excluded file would not be excluded any more from the queue.  Then, the plan was to do something similar with the track that showed in the queue with no name.

I started with selecting the same folder expecting to see, as I did many times in the last few days, 24 out of the 27 tracks to be added to the queue.  To my surprise, after selecting the folder, all the 27 tracks were added to the queue and there were no tracks with no name in the queue.  In other words, this time around, everything seems to be working as expected.  No files on the NAS were changed or added or removed.  However, the last thing I did yesterday was removing and readding the main folder in the library (with 99% of the files including the ones in question).  I did this after rescanning the library.  Rescanning did not help with anything; that is I still saw the same result which is 24 tracks instead of 27 and one track with no name. 

It looks like removing and readding the (effectively entire) library changed the behavior to the correct one.  The last time I did something like this was a few years ago.  Perhaps Sonos logic used while reading the library files got smarter (some bugs got fixed) and now it handles better the files (names and tags) which created problems before.  It also looks like rescanning does not help with fixing whatever was broken but remove/readd did fix it.

I shuffled the queue and I am playing it to see if it will stop again, but, this time, I am hopeful that it will work as expected as I see nothing odd in the queue.  It looks like there are reasons why the CS rep had the remove/readd of the entire library on his list of things to try...

Thank you for your help!


Hmm, after reading my comments above I think I need to add a bit more.  I stated yesterday that I tried to play the folder in question after removing/readding of the library yesterday and that it did not work.  I am not 100% sure now if I did that but, perhaps, the readding of the library was not complete when I tried it.  I think this would be the only explanation for why it did not work yesterday but does work today.


Just reporting that the queue played for more than 3 hours at which point I stopped playing it.  I believe that the issue is resolved now and the behavior is as expected.