Importing Nas folder issue

[steelrat]

OK, so I've been reading through a whole bunch of the older threads, but I haven't come across anything that fits the bill for this just yet....

zp120 - wired is currently the only device, although, there will be more shortly.

I'm working on trying to import the MP3 directories stored on one of the servers in the house....

Currently I have setup a DFS root share with the MP3's as a sub directory of that. I know that sonos will reference only the root share, so I've gone ahead and used the ntfs permissions to lock the sonos user out of what I don't want them to read. The heirarchy looks like this:

\\domain\mp3 (share path to sonos)

Structure under that share:

\\domain\mp3\->

itunes stuff -> itunes xml directories
computername -> archived mp3s from old computers
MP3's (this is the folder with the actual MP3's)

This contains the contents of the secondary share below which works

other stuff

If I use this with the folder permissions set (or not actually), the import starts and never ends..... it just seems to start over and over. I've watched the open sessions on files, and I'll see the sonosuser id read the director contents top to bottom, then just start over again in a loop. Like it doesn't know it's finished.

I've created a new share from the:
\\domain\mp3\mp3's

So if I use this to sonos (\\domain\newmp3share) the structure has:

albums\artist\album
jazz\artist\album
.... etc.

I've used the permissions to deny access to a few folders that don't have the id3 tags cleaned up, cover art etc.....

With this share, the import's complete with all the 18K songs in about 20mins or so max....

Share permissions are the same. The method to deny permission to the folders is the same.... I just can't figure it out. I'm wondering if it's over the 256 character path limit, but the OS or any other application have never complained.... At first I thought it might have been the " ' " in the folder name, but I removed it, and tried again.... no luck.....

Any ideas? Software started with the version 3.7.... and it works otherwise without issue, or the IOS app for control.....

TIA....

[steelrat]

So I added a play:3 to the sonos list today.... It's currently running wireless, so it the network configuration is:

router -> switch -> zp120 -> sonosnet to the play3

The funny thing is, after spending a few hours listening to internet radio, and a few other queue'd items, I thought I would try re-adding the problematic \\domain\mp3 share again....

This time, although slow.... it actually worked. I was rather surprised. The only change that I made was to the \\domain\mp3\zzz-last-folder (took out the dashes) and added a mp3 file just to reference. Thought, ok, maybe it was the special characters....

Then after testing the range of the P3 outside in the backyard.... I had to power off....

That's when I figured out that the p3 was the root device for the sonosnet (although it's still wireless) -- and it was the one that successfully indexed the \\domain\mp3.

So I did some searching, and set the zp120 as the zone master again, and tried the refresh of the library..... same "looping" symptoms continue.... Sounds like I've found a nice bug....

Submitted diagnostics while is running in the loop on the refresh.....

2068811

TIA, hope you guys can see something.... Oh and I'm thinkin' a bridge as the root device might solve my issue, since I'll have it securly wired.

[buzz]

steelrat,

This is an interesting situation.

Note that these forums are not an official support channel. Diagnostics referenced here do not always get to support. I suggest that you follow up with SONOS support. They will have a look at the diagnostic.

[steelrat]

Thanks Buzz, I wasn't sure if you guys would have access to all the diagnotics or not.... I know when you are "sysop'ing" depending on the corporation rules change. <G>

[ratty]

A passing comment:

The SonosNet root status doesn't determine which node performs the library scan. They're two completely different issues.

The root is a network Layer 2 concept, and by default would be the first player/bridge to be registered.

The library scan is performed by the player associated with the controller ("AssociatedZP" in About my Sonos) which -- I suspect -- is the first player to respond to the discovery broadcasts when the controller starts/wakes. It can be the player which has controller focus (showing in Now Playing) but doesn't have to be. A library scan can't be made by a Bridge.

[steelrat]

Originally Posted by ratty

A passing comment:

The SonosNet root status doesn't determine which node performs the library scan. They're two completely different issues.

The root is a network Layer 2 concept, and by default would be the first player/bridge to be registered.

The library scan is performed by the player associated with the controller ("AssociatedZP" in About my Sonos) which -- I suspect -- is the first player to respond to the discovery broadcasts when the controller starts/wakes. It can be the player which has controller focus (showing in Now Playing) but doesn't have to be. A library scan can't be made by a Bridge.

Thanks Ratty,

I wasn't sure if the bridge was only for network routing.... wired to sonosnet, or if it would also cache the available content on the network, rather like a domain controller.... <G>

Hum.... I guess I'll see what happens when support gets a chance to check the diagnostic.

I can always revert the share pathing if necessary, but I'd prefer to keep it as is, so the imported playlists, etc, will likely be happier. <G>