Print

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

[rjm]

I am doing a massive cleanup to my media file organization and tagging.

I am wondering if I should do anything to clean up my library internals.

Does the MC library become less efficient after many adds/deletes/changes are made?

Is there any benefit to creating a new library and exporting/importing the original library MPL?

Are there any other best practices for keeping the MC library data in tip-top shape?

Thanks in advance.

P.S. The power of MC for making wholesale changes to the organization of media never ceases to amaze me. I love it!

[rjm]

bump...

Anyone know if libraries need to be cleaned up once in a while?

[hit_ny]

Curious as to why you think a 'cleanup' would make the library more efficient.

i think of the library as text on a very long page, you can re-order it...

..but its still going to be just as long

[rjm]

The library (in my mind) is a complex set of linked tables. I am wondering if it becomes fragmented and filled with junk over time as you add/delete/change items.

[John Gateley]

We recommend Murphy's Snake Oil for cleaning libraries, works like a charm.

(No maintenance needed for your library)

j

[Alex B]

rjm,

You may want to check the following links.

http://yabb.jriver.com/interact/index.php?topic=28266.0
http://yabb.jriver.com/interact/index.php?topic=29216.0
http://yabb.jriver.com/interact/index.php?topic=30238.0

Depending on your chosen Auto-Import options deleting a lot of files may build excessive bulk in the deleted files database section. I don't know if this can affect the program speed, but at least the database can grow bigger than it needs to be. The linked threads have instructions for cleaning this part of the database if it happens to contain old useless data.

Auto-Importer should be able to clean the deleted files database automatically if you use its maintenance options, but if you don't, the files may not be removed.

EDIT

The library (in my mind) is a complex set of linked tables. I am wondering if it becomes fragmented and filled with junk over time as you add/delete/change items.

I don't think fragmentation can slowly become a problem. If I have understood correctly how the library works its data is quite "fragmented" from the beginning and the used system does not suffer from fragmentation problems. (Matt and John Gateley, please correct me if this is inaccurate.)

[rjm]

Thanks for the tips Alex.

I inspected my deleted files and only have about 400, most of which are podcasts which I assume may be wise to keep so they are not re-downloaded.

I'll try to stop worring about my library. Just habit I guess since evey other database I've used has some form of compact or re-index function.

[JONCAT]

Not a big deal as I suspect few use vast number of cue files, but since cue files (at least .ape cue) aren't handled properly I have to use an exclude tag to hide 2000+ files that show up with properties of the entire cue file (i.e. each file = 200mb+ duration = 57 min, 45min etc.) - they won't play but the "correct" ones do.

That's the only "clutter" I can think of: it would not be desirable to have 100,000+ files drawn entirely from cue files as you would have 200,000 files in your MC library.

DC

[hit_ny]

Not a big deal as I suspect few use vast number of cue files, but since cue files (at least .ape cue) aren't handled properly

What improvements can you suggest ?

I have to use an exclude tag to hide 2000+ files that show up with properties of the entire cue file (i.e. each file = 200mb+ duration = 57 min, 45min etc.) - they won't play but the "correct" ones do.

That's the only "clutter" I can think of: it would not be desirable to have 100,000+ files drawn entirely from cue files as you would have 200,000 files in your MC library.

i differentiate the files in the cue from the source by tags, so i have two viewschemes, one to show just source files as in the big file. This is used to get an idea of physical filespace occupied.

and another that excludes the big file and only includes the cue files. I prefer to use this one to get the actual filecount as that's what it would be if cue files were not used.

[JONCAT]

No suggestions as it's really out of our hands. Excluding the files is all I can. I avoid cue files altogether now.

I exclude the source files, and I'm done with them. Does MC report space correctly? I know I have some that show up as a 1:1 ratio....1 source file that is the size of the cue and named the album name. But I also have a lot that list each track in the cue file, with full size of the source cue file e.g. :

xxxx - 1  300mb
xxxx - 2  300mb
etc.

yyy - 1  495mb
yyy - 2  495mb
etc.

DC

[hit_ny]

A recent build addresses that by pro-rating size based on duration, the catch is you have to import them again into MC as the cue is only used for the import, there is no link to it after that.

I have a lot of cue albums and am wondering how to do this via MPL.

[Alex B]

Dr,

Import cue files only once and don't try to update library from tags when cue files are selected. Also, it might be wise to not incluce folders that have cue files in Auto-Importer's folder list or at least use a different configuration for cue folders.

As hit_ny said, cue handling has changed. The new system calculates the reported track sizes so that the combinated size matches with the audio source file's size. In any case the reported size is for information only. It does not affect performance. You may need to clean up old messes manually.

[JONCAT]

Okay, my impression is that you're not seeing the same "mess" I noted above. I'll try a re-import of the files.

So I should still end with the "duplicates" but only one cue/source dup instead of an album full?

thanks
DC

[hit_ny]

The problem with a re-import is you lose tags, ie rating, AA etc.

You can save these to MPL, and possibly apply it after the re-import, but this requires editing out the [filesize] tag in the MPL first.

[Alex B]

Dr,

You don't need to import the audio source file if you mean that. Import only the cue files. I usually just drag the cues to Playing Now and right-click import from there. In this way I can literally see what goes in.

Apart from the possibly imported big source file you should not get any duplicates. (If you use Auto-importer you can tick only the cue file type.)

I import the source files too because I want to handle them with MC, but I keep them separate from my standard audio library files by using a custom tag and view scheme rules.


hit_ny

The following will work:

1. Export MPL
2. Delete the cue tracks
3. Clean the deleted files database
4. Import the original cue (MC calculates new filesizes)
5. Update data by importing the MPL file. This updates all usual library fields but the file sizes do not change anymore.

You need to manually export the static playlists that contain cue tracks if you want to preserve them.

Easy as pie, isn’t it?   

[hit_ny]

5. Update data by importing the MPL file. This updates all usual library fields but the file sizes do not change anymore.

If by update you mean File->Import Playlist->MPL or Tools->Import Folder ?

Then isn't the filesize in the MPL, being ignored, a bug ?

way i understand the updates is,

- if the tag does not exist, MC updates it from the MPL,
- otherwise it ignores the value in the MPL.

So since filesize is by default already present, there is no way to change it. But then its possible to do this with the updates too so maybe i'm not so clear on this after all  ?

Easy as pie, isn’t it?   

you should put this saying in your profile i think

[Alex B]

If by update you mean File->Import Playlist->MPL or Tools->Import Folder ?

Then isn't the filesize in the MPL, being ignored, a bug ?

way i understand the updates is,

- if the tag does not exist, MC updates it from the MPL,
- otherwise it ignores the value in the MPL.

So since filesize is by default already present, there is no way to change it. But then its possible to do this with the updates too so maybe i'm not so clear on this after all  ?

Tools > Import Folder and Auto-Import cannot update existing field values from an mpl file. All files that are already imported are bypassed when these tools are used for importing.

File > Import Playlist is more powerful. It can update all library fields, but it seems that an already existing cue track size remains as it is. I don't know why.

you should put this saying in your profile i think

Perhaps... 

[hit_ny]

File > Import Playlist is more powerful. It can update all library fields, but it seems that an already existing cue track size remains as it is. I don't know why.

If that's the way it is then i'm completely fine with it.

It will make incorporating the new cue features much more easier.

[JONCAT]

I'm having some issues setting up the db delete smartlist; I used to have one but the options seem to have changed a bit?

Alex, you posted this in your linked thread - do you still use the same rule?

"My current "DB delete" rule looks like this:
DB: All   Not Playlist: DB Main, DB CD, DB Playing Now, DB Explorer   Not Genre: Podcast
The actual "edit by typing" code is this:
~d=a -playlistid==1000064206,=675452638,=830687242,=883564058,=596886313 -[Genre]=[Podcast]
I addded the "podcast exclusion" because I want MC to keep track of the deleted podcasts. The numbers are references that MC uses internally."

I also noticed that the Limit Database field doesn't explicity list "Delete".

IIRC, the yellowed music note icon represents db delete items?

DC

[Alex B]

Alex, you posted this in your linked thread - do you still use the same rule?

Yes

I also noticed that the Limit Database field doesn't explicity list "Delete".

You are correct, it doesn't. That's why my "Delete" smartlist is "All" minus the other limited smartlists.

IIRC, the yellowed music note icon represents db delete items?

It means that the file is not in the "main" database. As you can see it can still be present in other parts of the library.