Vesari Stylus ← vesaristylus.com

Help  /  Your library

Using a NAS or network share as your library

Vesari Stylus indexes a NAS or a Windows network share the same way it indexes a local drive. Everything that differs comes back to one fact: a share can vanish while the app is running.

The short answer

Point Add Folder at the share as you would at a local folder. Two things differ.

Mapped drive or network name

Both work. Register the share as a mapped drive letter (Z:\Music) or by its network name (\\nas\music); a path starting with \\ is recognised by its shape, a drive letter by asking Windows what kind of drive it is. Tracks on either carry a small globe badge in the track list, labelled Stored on a network share (NAS/SMB).

Register one route, not both. The same share reached two ways is one set of music under two names, and indexing both gives you every file twice: a library that looks full of duplicates. How scanning works covers overlapping folders; Why do I see two different "duplicate" numbers? explains the counts if it has already happened.

Network folders are not watched

Folders on your PC and on attached drives are watched while the app is open, so music dropped into one turns up a moment later. Network roots are deliberately left out: watching a share means re-checking the whole of it on a timer, which costs about as much as the rescan it would save.

After adding an album, press Rescan Library ("Find new and changed files") on the Tools tab. It indexes what is new, re-reads what changed and skips the rest, so it is far quicker than the first scan.

When the share is unreachable

Before walking a folder the app checks it can read it: up to three seconds per attempt, three attempts, half a second apart, so a brief blip is not mistaken for an outage. If it still cannot be reached:

An offline track will not play, because the file cannot be read. Ask for one directly and playback stops with a message naming the folder and what to do; the tag editor says the same. Left to pick the next track itself, the app steps over offline entries. They stay in the queue rather than being dropped, since a reconnect brings them back.

The safety net goes deeper. A scan will not drop tracks for a folder it could not walk cleanly, and it never treats a missing network folder as a deleted one, so a share that disappears mid-scan cannot take your library with it.

Getting back online

Nothing clears the offline mark on its own. Reconnect the share, then do one of these:

Do not run the app as administrator

Windows ties a mapped network drive to the sign-in token that created it, so an elevated app cannot see the Z: you mapped normally. To a scan that looks exactly like a dead share. (A network name is not a per-session mapping, so it is not affected.)

Vesari Stylus recognises the case and refuses to act on it. Rather than flag thousands of tracks offline it names the drive in a message, with a Rescan button beside it, and tells you to run the app normally. That is the fix: close it, start it the ordinary way, rescan. Your drive was fine all along.

Speed, and the rest of the differences

The first scan reads every file across the network once, so allow time on a large collection. After that a network root is read with more requests in flight than a local one, since round-trip latency rather than the disk is the limit. The library database is a local file, so none of that indexing traffic goes back over the share.

Tag writing on a share, and the path quirks a NAS permits that Windows does not, are covered in Tags and paths on a NAS. Tidying duplicates moves the extra copies into a quarantine folder on the same volume rather than deleting them, keeping the move a rename instead of a slow copy across the network: see Quarantine.

If the share is connected, opens fine in File Explorer, and the app still cannot see it, report it. Use Report a Bug under the Support tab in Settings and give the exact path you registered: Is this a bug? How to report it.