More > JRiver Media Center 25 for Mac
Excluding data folders from auto library imports
JimH:
Changing MC seems like a kludge to fix a problem with another kludge.
Is that something iTunes supports or is it supported by another app?
blgentry:
@kane2
It occurs to me that if all of these folders were in one tree with only FLAC files, then we could easily fix this by telling MC "in this directory tree, only import FLACs". Then it would ignore all the rest of the "phony" extensions and files.
That would mean a structure that looked something like this:
Your Music/FLAC/Artist1/Album1
Your Music/NotFLAC/Artist2/Album2
I have my collection separated that way because I wanted to get rid of all of my MP3s and other lossy file types. So I put them in different top level directories to help me with organization.
If your file types are all under one common directory structure, then this isn't as easy. MC can probably help you if you want to move all FLACs to a new top level directory (keeping the existing Artist/Album/whatever structure too).
Of course this would mean that ITunes would lose track of all of your media then and would have to re-import it in it's new location.
Which brings up a good question: Are you planning to keep using ITunes? If so, I have to ask why you would use both MC and ITUnes. They are quite different and most MC users kind of scorn ITunes. If all of this is a huge workaround to keep using ITunes, the best answer might be to dump ITunes since MC can do almost everything it can (other than talking to iphones and ipods). Or maybe my "move all FLACs" idea.
Thanks,
Brian.
kane2:
Other programs and computers use the iTunes Music Library, which is why iTunes needs to know about it (Apple's homepod and sharing of music to other Apple devices, such as ipods, or iphones) depend on iTunes knowing and cataloging the files. The ability of excluding certain named data folders, is a general solution to this and other problems. A great example is the way rsync works, it's ability to exclude certain names of directories is of paramount importance. MC just assumes that everything in a Musics hard disk structure is to be imported, or excluded on a case by case basis. Giving a grep like --exclude would allows MC to play nicely with that hard disk so that it can be shared with other programs and utilities. This large music file directory is networked (NASH) and shared by other computers (of various operating systems) running different programs, depending on the hardware playing the music. Even the ability to call out to a small program with the file path to return a true or false to importing would be great (it could even by a python, ruby, bash command or scripting language, anything like that) would allow you to do this. The ability doesn't have to be within MC.
RoderickGI:
--- Quote from: kane2 on July 03, 2019, 03:18:30 pm ---Even the ability to call out to a small program with the file path to return a true or false to importing would be great (it could even by a python, ruby, bash command or scripting language, anything like that) would allow you to do this. The ability doesn't have to be within MC.
--- End quote ---
Sorry, but that is just getting silly. MC would still have to know to call out to an external program, and would have to accept the result coming back. I don't work for JRiver, but if I did, I would never consider that. Particularly to support third party functionality, and a kludge at that.
The wildcard idea isn't a bad one, but have you noticed how MC only allows you to select existing folders for import, and validates each folder as you enter it? Of course, you can add a folder through the Browse functionality, but you can still only select an existing folder, even if you just created it. A change to using wildcards would require big internal changes.
If you wish to support multiple iDevices and Apple technology applications, why don't you just convert your FLAC files to ALAC? MC plays both, and you could potentially simplify your whole music management process. I just had a quick read on the Pure Music Bookmark solution. Ahhh!!!
But if you really must maintain iTunes for iDevices, and don't want to convert your FLACs to ALACs (which I believe would be a lossless conversion), and therefore want to keep using the Pure Music solution, just let MC import all those extra files, and then exclude them from all View and Smartlist definitions. They will be there, but you won't see them in MC.
-[Filename (path)]="data_folder"
-[Filename (path)]="Pure Music Bookmarks"
In English, those expressions say 'The path does not contain "data_folder"', for example. Including both those in all your View and Smartlist definitions will hide all files stored in those folders and any subfolders. It would be a bit of work to add those to all View and Smartlists, but not too onerous.
kane2:
Unfortunately ALAC files max out at a much lower resolution than flac so that's not really an option.
Adding a simple call out via a straight forward API to a little code snippet and acting on it's return value is not difficult to add from a technical viewpoint. I've done this for countless programs over the years. I understand that this isn't a feature that you need, but the actual disk with the media files is a shared resource and this would just help MC play nicely when working with many types of programs (metadata programs, catalog, other players or streaming software, etc) that also use that resource and act on the data. None of this is MCs fault, but it reflect the reality of a shared area and that it can get a little messy. I have numerous servers using the same library.
Another solution might be to add terms such as you suggest right into the auto import rules. The current interface for auto-import VERY simple (just a directory path), and the ability to use those general kinds of terms (tags that return values) already exists within MC.
I like your solution, but I'm assuming you mean to add that individually to each smart playlist that exists. I was talking about keeping things out of the libraries to begin with, so the program can truly ignore them.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version