Print

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

[MrBiff]

Can you make the Cover Art location use an MC field rather than the current single global value.  Currently it is defined in User Settings as:

File Location - Image File Location="\[App Data Path\]Cover Art/"

and this means one library's Cover Art pollutes another library's Cover Art.  I have several test libraries, and I don't want their Cover Art polluting my Main library's art.

I'd like to be able to use an MC field in the setting File Location > Cover Art > Folder so that I can have the library define where Cover Art is located, as in:

File Location - Image File Location="\[LibraryCoverArtLocation\]/"

[HaWi]

Can you make the Cover Art location use an MC field rather than the current single global value.  Currently it is defined in User Settings as:

File Location - Image File Location="\[App Data Path\]Cover Art/"

and this means one library's Cover Art pollutes another library's Cover Art.  I have several test libraries, and I don't want their Cover Art polluting my Main library's art.

I'd like to be able to use an MC field in the setting File Location > Cover Art > Folder so that I can have the library define where Cover Art is located, as in:

File Location - Image File Location="\[LibraryCoverArtLocation\]/"

If possible, I'd love that, too.

[blgentry]

This is not a direct answer to your question.  Rather it's my opinion on this subject in general.

Centralized cover art directories are a bad idea.  It separates the metadata (cover art) from the actual file (the song file, MP3, FLAC, etc).  They should be tied together.

For me this means placing cover art in the same directory as the song files.  Better yet, embedding the cover art INSIDE those files when the file supports it.  That way they are never separated.  This is the most straight forward and easy to maintain approach.  Anything else adds additional maintenance steps and more things to keep track of. 

MC supports both of these things:  Keeping cover art in the same directory as the music files and embedding the cover art inside the files.

Brian.

[MrBiff]

Centralized cover art directories are a bad idea.  It separates the metadata (cover art) from the actual file (the song file, MP3, FLAC, etc).  They should be tied together.

For me this means placing cover art in the same directory as the song files.  Better yet, embedding the cover art INSIDE those files when the file supports it.  That way they are never separated.  This is the most straight forward and easy to maintain approach.  Anything else adds additional maintenance steps and more things to keep track of. 

MC supports both of these things:  Keeping cover art in the same directory as the music files and embedding the cover art inside the files.

This doesn't address the issue of Series and Actor images for video files.  These must live at a higher level since they are connected to many files within many directories.  The higher level avoids large duplication, and that's the only thing MC supports for certain image types.

The issue is that these files should be library-related, not global to all libraries.

[lepa]

I agree on the library level point. On attach issue my 2 cents is that hires scanned artwork might be very very big to be attached to your files and not sure if MC supports anything else than cover image attach. Also for videos I keep ALL the artwork (thumbs/covers/other) on local SSD otherwise MC is hanging all the time when NAS (or any drive on it) is sleeping. So there are valid use cases for centralized parts in the collection

[blgentry]

I don't get why you'd want to do this, but I understand that you do want to do it.  I guess I have no further input.

Best of luck.

Brian.

[lepa]

I think the goal is to differentiate "cover art" which MC show as "thumbnails" when browsing your collection from actual album art (which can be very large for archival purposes).

So yes for music I have the specific album art images in the same folder as the music files are (Front, Back, CD/Label, Gatefold, Booklet, Inlays etc). These files are also imported as library items and tagged to belong to specific album and so tied to album's songs. However from MC's library point of view I have cover images for every album in centralized folder to which library have always access when it has access to library itself. Also then library doesn't need to handle hires front covers file sized e.g. 20MB when I'm browsing my collection. There's thumbnail caching to partly handle that but I'm not sure what is the size when MC switches to use actual images instead of cache.

For videos this isn't possible at all. Location is always next to file. Generic poster or episode image got from TMDb seems more library related to me (series and season images already are centralized as well as artist images). If I have actual album art files for the release I would handle it like with audio as actual library items (or embed it to file itself in case of matroska but then MC cannot see these at all).
At least option (like with audio already) to do this would be nice.

Also related to file locactions, IMO tooltip image location would be better suited inside appdata than its current location inside MC program install folder.

[Matt]

Are you thinking a field like "Image File Location" that defaults to empty.  When filled it would be used instead of the current setting?  Thanks.

[MrBiff]

Are you thinking a field like "Image File Location" that defaults to empty.  When filled it would be used instead of the current setting?  Thanks.

Correct.   It would define the root of all images for the library (e.g. Series, Artists, etc.)

That would allow my software to interrogate MCWS for the correct location, on a per-library basis, in order to populate the various cover art folders programmatically, and avoid writing testing artwork to my Main library's artwork area.

[Matt]

Do you need the folder to vary between files?

Or would having an easier way to set a single folder do the job?

We'll get this for you one way or the other.  Thanks.

[MrBiff]

For me, a single setting per library is sufficient.  But perhaps user lepa has additional requirements.

[Matt]

For me, a single setting per library is sufficient.  But perhaps user lepa has additional requirements.

I'll make the next build store the folder per-library.

We also migrate the cover art folder at upgrade time.  I'm going to simply set the global setting as well as the per-library setting and only the global setting will get upgraded.

Testing appreciated once build 31.0.53 or later is out.  Thanks.

[lepa]

.53 changes doesn't affect me at all as it only makes current library thumb/cover art implementation per library. I'm after getting everything which belongs to library UI out of NAS. i.e. to make library's video cover art to behave similar to what can be done with audio and move everything to fast (and always available) mass memory where also library db (and my audio and and season/series covers locate).

Currently I need to use external tools like ZRatings or MCUtils to achieve that and get rid of most of the "I want to switch to another library manager MC hangs" when it tries to access files on sleeping NAS when just browsing in standard view