I understand the 65,000 track limit you refer too is not a track limit, but what I will term as ‘memory slots’ and some tracks may take up more than one slot. There are also these limitations which I found in other threads here in the community…

Field Name Character Limits

• Artists - 76
• Album - 92
• Track - 100
• Genre - 22
• File name - 100

So maybe you’re exceeding some limitation that’s causing you an issue, but maybe contact Sonos Support Staff via this LINK and see if they can perhaps assist you further.

Ken:  

 What’s the difference between Track & File Name?

Are those field and character limits new? I’m pretty sure none of my files exceed those as I like to keep my naming system simple. It’s the exact same library I’ve been using for years, so if they are not new, then I’m probably well within individual file character limit. Was hoping to see if I can glean any insights from the community before attempting support staff since they’re likely overrun these days…

Nothing probably. As stated I copied it from past threads (a long time ago) - unless it should read ‘path’, perhaps?

No they’re not new - they have been mentioned in the distant past - maybe as far back as 2016, or before.

I just searched the site and found this from 8 years ago …

There maybe older and newer mentions of the field limitations, if anyone perhaps wishes to search back through the community threads.

 Thought about it.  Maybe it’s the physical file name which could be different than the Track name in the tags.  Not sure though.

 Wish there was an accessible log that would show you where the index stopped.  I used that with other software a while back to fix boo boos I had in the library.

@Izzybones,
Not sure if this may help as a bit of a comparison … but note I’m using a NAS in this instance.

Anyhow, I just thought I would go check my own library size etc; which is setup on a Netgear NAS box and its folder size (see attached) is 230.57GB. 

That caters for 25,697 tracks plus artwork images/folders etc. and that indexes okay in the Sonos App. I’ve attached an old screen-capture just showing the Sonos App loading all the library tracks to a room queue using an *.m3u playlist I created a couple of years ago - it just confirms the total number of tracks… it wouldn’t load the playlist if they were not in the library/index.

Is it possible your router might be limiting things in this case too, perhaps?

I think there might be something in the Windows controller that might assist with this - (not sure?) - some kind of logging, others might chime-in here, perhaps?  However I think the indexing happens so quick that it can only give a bit of guide as to the whereabouts of the track causing the failure.

Since this is an S1 system, go to http://[IP address of a speaker]:1400/support/review.

Each speaker will have an entry here. After an index fail go to each speaker then open Zone Player Info and look for an entry in IdxTrk. If there is an entry here, the indexer has aborted while working on this track. You’ll need to check all of the speakers because you don’t know which one has executed the indexer.

You don’t have any control over which player will take charge and execute the indexer. PLAY:3 is a bit memory constrained. You may have better success if you power down PLAY:3 while you index. This will prevent PLAY:3 from taking charge.

@buzz was that comment for me? My system in my house is not S1, it’s S2 (or whatever you call the latest app) - arc, sub, 2 symphonics, roam, one, move and a play3 - I’ll look into that on the play 3. It does seem to be a size issue though - not a particular file - as when I experiment with adding different artists, it’s when I go over 20Gb that failure happens. For example I add a folder that’s 15 GB, Sonos indexes it without issue, then I randomly start adding new artists one or two at a time, get up to 19.54 GB, everything still good; add one more artist folder which takes the indexed amount over 20 GB and that extra addition will trigger the error and it won’t get indexed to the library, and no other attempts at adding any additional files will succeed. So maybe the play3 is indexing and causing issue then, if it doesn’t have the memory? Weird though since my library has been the same for years, so before I had my newer higher memory speakers, and everything indexed fine. I’ll try powering down the play3 tomorrow and see if I can add anything more to the library. Thanks for your input.

Your Profile lists a PLAY:5 Gen1. This is S1 only.

@buzz No, I’ve sold a few components along the way - I don’t have that one anymore. Just realized you got that off my profile - forget that existed; I’ve updated it.

Try looking at IdxTrk.

I think people are missing the point. The memory limits and 65,000 entry limits have not significantly changed that we know of, and the same library used to index on pre-May 7th code. 

We know that they have been in changing the indexer code as witnessed by the mess that are compilation (mainly) albums, and there are other threads on here where indexing appears to halt unexpectedly. Best guess on the latter is that there are some odd characters in filenames that are causing the issue, or in some cases an SMB buffer credits issue. Maybe Buzz’s suggestion to look for idxtrk will help. 

If it is ‘non-std’ characters then this tool may make life a bit easier…

https://answers.microsoft.com/en-us/windows/forum/all/how-do-i-remove-or-replace-every-special-character/55fb4b47-8a30-4062-8d31-61e204756d9b

You can easily discount the Play:3 as the issue by just turning that off. Unlikely, even though it is the most memory constrained unit. 

It would seem like many other things, Sonos have taken something that was working (for many years) and broken it… 

So, if none of that works, and as much as it makes me sound like one of the camp-ers round here, you may have to submit a diagnostic and contact support to possibly get a better handle on it. 

If there is a memory issue, due to excessive metadata, break the library into more shares, rather than simply adding more tracks to a share. Up to 16 shares is supported.

File Name is the field used by the storage operating system when fetching the file. Track Name is for the user display. The ripper may use the same text for both. There is very little reason to use long file names. I store each CD in its own folder and use very short file names, such as “Trk01.FLAC”. Even “01.FLAC”, “02.FLAC”, …, would be OK.

@buzz @Ian_S It’s noticeable that this issue is getting a bit more airtime in the community recently. I’m surprised as it’s been an issue for years, perhaps brought to more prominence now by the deprecation of SMBv1 support on S2 (which had been a workaround).

When I index my library, I do shut down my older speakers (Playbar, Play 1s etc), and effectively force an Era 100 to do the work. Generally my indexing completes, but not always. I didn’t know about Idx Trk so will have a hunt for that next time I encounter an error.

@Izzybones You should be aware that TP-Link is one of the router brands that seems to be afflicted by the problem; Asus being another (which is the brand I use). I don’t believe you’ll be hitting any limit, unless you have crazy long file paths. Your library is a similar size to mine. My folder structure, paths and metadata are all very clean (I am good in this regard), and looking now I have 126GB of MP3s made up of 15,396 files in 1,520 folders. It’s fair to say that router SAMBA capabilities are considered pretty flaky, working for basic file sharing, but often failing when asked to do more.

I’m currently trialling Plex with a month of Plex Pass. I’ll buy a lifetime subscription on Black Friday if I like it. This is a common way of getting round local library annoyances, but does seem to come with its own quirks. Another is iBroadcast.

I do think there’s value in submitting a diagnostic to Sonos and contacting support when you see an error. You might gain some insight.

@buzz yes, I have tried splitting into more than one share, I can delete and add between the shares and Sonos will index properly, but if the amount of music the the shares are indexing goes over the 20GB limit I can no longer add additional music to any share - even if I add a single album to  brand new share, it will error out if I already have reached 20 GB between the other shares. I tried unplugging the Play3 to see if that was the speaker doing the indexing, but it didn’t change anything.

For the idxtrx you were referring to, is it found when I go to that http://ipaddress.. link you mentioned earlier? When I do that, I get a list of all my speakers that are online, and can click on each entry to expand for more info, but none of them have anything pertaining to idtrx. The list beneath each speaker is identical, actually, and no reference to idtrx.
 

Appreciate your input, thus far. Thanks.

@DGR1 Thanks for your comment. I think my file and tagging structure is pretty clean as well. I took great pains when originally ripping my CD collection to use a tagging software to make everything consistent and simple. If the problem was something like a bad file then you’d think I wouldn’t be able to add it at all, whereas files that won’t get indexed if I’m at 20 GB with the existing share, will get indexed if I first remove some files from the music share. I also have a One which I unplugged along with the Play3, but still no change. I’m glad to know that you’ve got a larger share - is it also on a usb drive connect to your router? I assume you haven’t had to delete and re-add the entire library at any point since the new app? I’m wondering if this indexing issue is primarily affecting people who had to start over with indexing, rather than those who never did any big changes in the first place. I hope it’s not my new router limitation; it works great otherwise. My older router was cheap but seemed to play nicely with the Sonos library before they took away the SMBv1 support. 

Hi @Izzybones Yes, I have a USB thumb drive plugged into my main router node. And yes, I have removed and re-added the library a few times since May. I don’t link this particular issue to the new architecture that’s been deployed.

I always use the desktop app as opposed to mobile because you get no indication of progress on the mobile app. My music is split into 11 folder (ABC etc) because that has been recommended, but at present I only have a single entry for path/music that is working. Whenever I see the error, I also see an SMB credits error reported in my router’s log.

TBH, sometimes when I add an album to my collection (I love buying cheap CDs from ebay and ripping them), and then use ‘Update Music Library Now’ from the desktop app, I can get an error almost instantly. Other times it will work. So I haven’t entirely convinced myself that this isn’t an Asus issue. However, I saw the same issue when using an old WD MYBOOKLIVE NAS. It supported SMBv2, but a full index would often fail.

I can access and use shared folders from my USB drive from other devices with no issues.

Your issue is slightly different in that you can recreate the problem at will, just by breaching a size limit.

Are you able to see your TP-Link router logs anywhere to check for any SMB credit messages?

@DGR1 I use the desktop app as well. Prior to this I was using a router with the SMB1 protocol and didn’t experience issues, although my library has remained static so never needed to update my library, and I was able to avoid all the updates until recently when somehow my speakers got an update (tho I had those updates turned off, along with app updates, so not sure how that happened). It’s the change to SMBv2 that seems to be the problem, so maybe you’re right that this is a separate issue from the new architecture, and as someone else pointed out is just becoming more evident since more people are forced to move away from SMBv1.

I can see a general log on my router, and there’s a bunch of entries that relate to various processes starting stopping, including some references to USB3 and Samba processes, but nothing that stands out as an obvious error message. And no evident correlation between times I can successfully index vs not, but I’m no expert in these things.

@buzz I see, I’d didn’t expand them enough for the additional info. Thanks.

I checked all the speakers and they are all blank in the idxtrk column, so does that mean they are not getting hung up on any particular files?
 

If nothing else, I’m learning random info about my speakers…