Print

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

[bunglemebaby]

In an effort to make searching performance quicker on my slow machine I've set up some custom fields as my default search fields (using only these few fields). In these list-type fields I've combined any of the fields that I would normally want searched by default, grouping them logically.

So, my [searchartist] field is filled by the expression
=[artist]; [album artist], [musicians], [producer] ...    (etc.) using confishy's AutoTagger plugin.
This works fine enough, except that the list contains duplicate entries. So if John Zorn is both the [artist] and [album artist] then John Zorn will be in [searchartist] twice. This isn't a huge deal, but I'd prefer to keep these fields lean and mean if easily possible.

So, is there a way to automatically combine the duplicate entries within a list-type field into a single entry?

I've noticed that if I select a single file, manually edit the list (but don't change any values) and then hit <enter> the list will compact. But it's obviously not practical to do this for all files in my database. Also, oddly, for this operation it only works if there is more than one entry...so John Zorn; John Zorn will stay as is, but John Zorn; John Zorn; Ikue Mori will combine to John Zorn; Ikue Mori.

Thanks for any ideas,
JB

[Matt]

Instead of going further down the road of a workaround, maybe you could describe in more detail why you need the workaround.

Searching should be fast.  How large is the library, and what is the CPU?

Making new fields to search instead feels icky, and I wouldn't actually expect it to be faster.  It's possible there's just a bug or issue with your particular library slowing things down.

Thanks.

[bunglemebaby]

Fair enough...
CPU is Core Duo T2300 @ 1.66GHz.
The main audio library is 29K (most searches happen with views limited to this). The full library, all inclusive, is 78K. It is spread across two USB HDDs, with audio located on a bus powered slower drive (5400rpm).

The searching feels slow. It's not slow to the point where I'm counting seconds while waiting (usually), but I guess I like filtering type searches to feel almost instant. Often it seems like I can see the filtering "stages" happening. I'll type in my whole search and then wait as I watch files disappear in chunks or batches. It's not really a "batch" per letter or anything, but for a 10 letter search I might see three such transitions, with a bit of a pause at each one. This behavior is significantly worse on thumbnail views.

My defaults search fields are: Album, Album Artist, Artist, Caption, Composer, Events, Grouping, Genre, Keywords, Lyricist, Name, Notes, People, Places, Series, Style plus my custom fields: Game, Influences, Musicians,Publisher, Remixer.

This seemed like a number of default fields, so the idea was to consolidate...

-JB

[JimH]

Where are the MC database files stored?  Storing them on the local drive will improve the speed of searches.

You could set up a second library that way, just to test.  File/Library/Library Manager.

[bunglemebaby]

The library file is located at the default Docs & Settings location, which is on the local drive.

Edit: My Cover Art directory is not on the local drive, however. Could this be related since the behavior is worse on large thumbnail views?

[Matt]

Try this:

Make a smartlist: [Media Type]=[Audio]  Then use the search box in that smartlist.  

Is it faster?  This will let us know if it's the database that's slow or the (possibly fancy) view you're using.

Then we'll go from there.

Thanks.

[bunglemebaby]

Make a smartlist: [Media Type]=[Audio]  Then use the search box in that smartlist.

This seems to be about the same as my view schemes.

[bunglemebaby]

Bump:

1) To see if anyone has any ideas regarding my apparent database slowness.

2) I'd still like to be able to delete duplicate entries from list type fields, unrelated to the performance gains I originally thought the combined-type fields would give me. It would still be nice to be able to use these type of fields in Pane based view-schemes.

-JB

[gappie]

In an effort to make searching performance quicker on my slow machine I've set up some custom fields as my default search fields (using only these few fields). In these list-type fields I've combined any of the fields that I would normally want searched by default, grouping them logically.

So, my [searchartist] field is filled by the expression
=[artist]; [album artist], [musicians], [producer] ...    (etc.) using confishy's AutoTagger plugin.
This works fine enough, except that the list contains duplicate entries. So if John Zorn is both the [artist] and [album artist] then John Zorn will be in [searchartist] twice. This isn't a huge deal, but I'd prefer to keep these fields lean and mean if easily possible.

So, is there a way to automatically combine the duplicate entries within a list-type field into a single entry?

I've noticed that if I select a single file, manually edit the list (but don't change any values) and then hit <enter> the list will compact. But it's obviously not practical to do this for all files in my database. Also, oddly, for this operation it only works if there is more than one entry...so John Zorn; John Zorn will stay as is, but John Zorn; John Zorn; Ikue Mori will combine to John Zorn; Ikue Mori.

Thanks for any ideas,
JB

well, when using john zorn as an example you keep cleaning up the expression filled field.   amazing musician.
i actually think it could be a nice addition to have something that could clean up fields like that, preferrably an expression like CleanUpList()  . ofcource you could try to make an expression that starts with a list field first (musicians?) and then checks if the next field is already there before adding it. but that would only work if there is only one list field there otherwise it would become very complex.

actualy i use a field a bit like yours, but then as a live expression, and i use it in one view and in theaterview, but not in the searches, never in the searches. im also on a dualcore older machine, and for me the searches are fairly quick. when you take the field out of the searches, is it quicker? when not, it might not be a bottleneck.
(i reacently posted the expression i use with some pics, when you are interested, its here somewhere: http://yabb.jriver.com/interact/index.php?topic=58612.msg396708#msg396708

 
gab