Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Vincent Kars]

I use a directory structure
\\NAS\Sound
\\NAS\Sound\blues
\\NAS\Sound\classical
\\NAS\Sound\Jazz

I have a library NAS  pointing to \\NAS\Sound  so containing all audio

I created a new library called Classical
It is cloned from NAS to preserve all custom views

I set auto import to monitor \\NAS\Sound\classical
I set File Location to \\NAS\Sound\classical

I run auto import with Fix Broken Links: Yes

I expected after running auto Classical to contain the audio in \\NAS\Sound\classical only and all audio in the other directories to be removed from the library.

All audio remains in place and all play.

I expect changing the file location to do the job.
Might it be that when cloning a library the original file location is preserved and no way to remove this location using the interface?

Media Center 15.0.171

[Alex B]

I run auto import with Fix Broken Links: Yes

This is separate from the set import (and other) locations. "Fix Broken Links" just checks if the files in the library exist also on the disk. The files in the library may have any file paths. For instance, you can use the library tools to move files outside of your import folders and they will still be preserved in the library. You can also import by using other means than the Auto-Import feature.

When the Auto-Import feature was first introduced a few years ago I requested that each stored Auto-Import path would have its independent cleaning options, which would be effective only under the specified location, but I was quite alone with my request.

I expect changing the file location to do the job.
Might it be that when cloning a library the original file location is preserved and no way to remove this location using the interface?

Naturally you can simply select the files and remove them from the library. You can also temporarily hide the media files (for instance, rename the base folder outside MC) and then run Auto-Import with the Fix Broken Links option.

[Vincent Kars]

Nothing wrong with cloning a library but I do expect to clone definitions like views etc.
Getting the content also is ok but the major reason to clone is of course that you want to change a couple of things.
If I remember correctly in older versions you could clone a library and at creation time specify a folder for the audio. This forces a refresh
Today this is no longer the case.

I have the impression  that they have changed a couple of things to improve novice experience at the expense of configurability.
Personally I prefer
- Specify a library (the database)
- Specify multiple path to the audio given this library
Adding/removing a path should add/remove the content from the library

[rick.ca]

I have the impression that they have changed a couple of things to improve novice experience at the expense of configurability.

I'm not sure about what has been changed or when. But as for imputing a reason for the way it is now, the opposite is closer to the truth. Rather than files being arbitrarily restricted based on where they happen to reside, we're free to include any files in the library. That clearly supports configurability, while probably making things more challenging for novices who are likely to understand their file system better than the database.

Adding/removing a path should add/remove the content from the library

"Adding/removing a path" from where? Removing a path from an import specification should do nothing but stop future importing of files from that path. Removing files has nothing to do with importing. And while there's no separate command for it, there's nothing stopping you from selecting all files in a particular root path and removing them from the library.

Also, let's not forget most users would not choose to maintain multiple libraries. Doing so obviously involves more maintenance effort, so it should only be done when there is some compelling need that justifies the additional effort. Part of that would include the presence of mind to store media destined for different libraries in different locations, and to configure each library to import only it's own media. Most users, however, are better served by maintaining all media in one library—relying on the flexibility of the program to have it all handled appropriately. For example, there's no reason why popular and classical music can't be effectively handled in the same library—just as there's no reason why music, images and video can't be effectively handled in the same library.

[Vincent Kars]

Maybe because I’m a former WMP user, I expect a dialog showing me all the folders monitored by the library.
Of course one can make a view emulating this because the information is available in the library