Print

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

[lise]

I currently use subgenre and keywords for all types of files (music, documents, etc), so each field has a gazillion entries. Not an issue at all but for one thing - the list of field entries isn't always filtered according to the View Scheme rules.

In the picture below, I am in my Documents/Film view scheme, which displays only those files with the Film genre. It works great when I select the scheme in the tree: the subgenre column in the panes displays only those entries related to the film documents. (left column in the picture)

But when I select a file in the list (insted of the pane) and double-click on the subgenre column to modify, or if I select a result from a search within that pane and "add new subgenre" in the upper panes, I get a list of ALL subgenres for everything (picture on the right).

Image of Documents/Film View Scheme:


I can only gather that the list drop-downs cannot be filtered according to the View Scheme rules.
Nor can search results, although I don't understand this part because searches are already filtered automatically to search the current 'screen' if you will. Not sure why selecting a search result and selecting "add new subgenre" up top in the panes now suddenly displays the list of "all" subgenres rather than the filtered one. Must be some strange limitation.

According to other threads I've read, the only solution is to additional fields used only for those filetypes or whatever criteria I choose, which would mean new subgenre fields for the "recipes" genre, the "Film" genre, etc. We are talking lots of new fields here.

Is that really the only option? And if it is, does having a gazillion fields require more MC ressources?

[Lasse_Lus]

Is that really the only option? And if it is, does having a gazillion fields require more MC ressources?

i don't have gazillion fields, but +200 custom fields, and i see no performance issues

..and you can always remove fields if you think there is

[MusicHawk]

I have many custom fields, mostly list-type, which likely require more processing when grouped and in views to parse out and create virtual records, and it seems to work well.

Perhaps you could create new fields driven by expressions based on existing fields, to see if you can then get what you want. No permanent "damage" because when you delete a custom field it simply disappears (each field is a separate library file).

Of course, it can be much more efficient to use separate libraries for different types of files, each using only the fields appropriate to the files. My main libraries are Music, Photos, Videos, plus some other smallish special-purpose libraries (Christmas Music, Radio Shows, Sound Effects, Historic Recordings...)

[lise]

Perhaps you could create new fields driven by expressions based on existing fields, to see if you can then get what you want.

That would be ideal but for one thing -- while expression-based fields are great for viewing the info, you can't use them for tagging. All my document views are dual-purpose, but I use them mostly for tagging.

Of course, it can be much more efficient to use separate libraries for different types of files, each using only the fields appropriate to the files. My main libraries are Music, Photos, Videos, plus some other smallish special-purpose libraries (Christmas Music, Radio Shows, Sound Effects, Historic Recordings...)

Wow, you have a lot of libraries. I used to have two: music and everything else. The everything else was always open on my laptop because I use it as a database for all my documents. It had to be everything-else because when I want cooking stuff, I want recipes, cooking shows, photos, etc. I don't care about filetype: I care about the genre, or should I say the 'project'. But I like to listen to tunes all the time, so I would always have two copies of MC running, for each library. I don't recall why I decided to go for a one-library-for-everything. Maybe running two instances of MC was too taxing on my laptop? Don't recall really, but maybe I should give that another shot.

Lasse_Lus, do you use any of those custom fields in file-renaming expressions?
I ask because I've encountered an issue. My generic subgenre field, the one I'm complaining about, worked perfectly for at least one thing: I could rename my files using a rule that basically said: if subgenre is empty, name the file Genre\name, otherwise genre\subgenre\name.  But if I create all these custom subgenres for each genre, I'm snookered because I can't say: if all these various subgenres are empty do this... because they WILL be all empty except for the one that is not (ie filmsubgenre).

Looks like I might have to choose between living with the too-long subgenre lists I started with or manually renaming files all the time.

[MusicHawk]

To predict resource and performance loads, it would be helpful to know how MC handles various scenarios -- maybe Matt will enlighten us sometime. For instance:

Are 2 running instances of MC totally separate, therefore use double resources? Or do they use the same program instance but separate data areas, like a browser runs multiple sites via tabs or windows? Is the difference material? How would this compare to the sometimes-requested ability to let MC load multiple libraries for "fast" switching between them?

When a library is loaded, does MC ignore all fields that do not have data, therefore are presumably not being used in that library? This could mean MC avoids the overhead of opening their files (each field is a file). Or maybe better, does MC open only the fields that are in the current view?

And related, what fields does MC open even if not explicitly used by the user/view, such as last-something date and count fields, and what is the overhead of this? If there is notable overhead, can this be managed somehow? (For some uses, last-something dates and counts are meaningless...)

Are some types of fields notably more efficient than others? What is the impact of one long field vs. the same data in multiple shorter fields? (My Keywords field has many values, so the pick list is quite long, and sometimes so is the data of a particular record; works for my needs, but I've wondered if splitting it up logically would be productive.)

How does MC handle abandoned and "white" database space? Classic databases must be packed/compacted periodically (manually or automatically) to recover the space of deleted data and store variable-length data more efficiently. A larger-than-necessary database can be inefficient, but the packing process will really bog down the system (lots of I/O). Is this a factor in MC?

What is the performance impact of showing cover art, small in a view column, a bit larger in the Tag window, medium in certain view types, large in theater view, etc? How does performance compare when the image is in embedded, or in Folder.jpg, or in a specified folder?

What Options settings materially affect performance?

There are probably lots of other questions (and perhaps some have been answered that I haven't noticed), but these are the kinds of factors I like to understand about a database system so I can use it efficiently.

[Lasse_Lus]

Lasse_Lus, do you use any of those custom fields in file-renaming expressions?

lise, i very seldom rename my files...but i cant see any problems if i would, groups of custom fields are for groups of projects, in different views, so i fill in needed fields first i suppose 

[lise]

lise, i very seldom rename my files...but i cant see any problems if i would, groups of custom fields are for groups of projects, in different views, so i fill in needed fields first i suppose 

Ah, we work very differently then. I work with ToImport folders. Every new document, download, mp3, photo, etc goes into that computer's ToImport folder which is watched by MC's auto-import. I always know which files haven't been tagged, and auto-import doesn't have to keep an eye on my entire computer--just the few ToImport folders. When the files are tagged they get renamed/moved using expressions.