Topic: Cover Art (Read 27821 times)

rjm · « **Reply #100 on:** January 13, 2012, 12:10:04 pm »

Quote from: Matt on January 13, 2012, 11:20:32 am

We will, but why are you importing sidecar subtitle files?

Two reasons.

1) My policy that every file in my media folders must be imported, properly tagged, and properly named/located. I guess I could change this but I like knowing there is nothing hidden or messy in my library.

2) When browsing movies with MC (in a non-explorer view) there is no way to know if a movie has subtitles unless the subtitles are imported. Again, I guess I could give this up but prefer not to and hope you find a solution.

leezer3 · « **Reply #101 on:** January 13, 2012, 02:33:22 pm »

To me, that's absolutely defeating the purpose of the database

Every file is referenced in the DB, so therefore as long as I've got the database and a good set of backups stored, I see no reason to go overboard on file naming/ location.

I do agree though that there ought to be a better interface for showing what language/ sub streams are available from a browsing point of view.
From a theatre view POV, I'd be inclined to add little icon overlays in the corner of the thumbnail for files possessing multiple subs/ language streams.

-Leezer-

rjm · « **Reply #102 on:** January 13, 2012, 05:46:14 pm »

Quote from: leezer3 on January 13, 2012, 02:33:22 pm

To me, that's absolutely defeating the purpose of the database

I understand, but if you have good tags it is easy to properly locate and name files with MC so I do so. I find having well organized discs reduces the chance of a making a backup mistake.

Recently I ran into another huge benefit. I am using Air Video to send video from my server to my Apple TV with my iPad. Air Video has no concept of tags and simply navigates the file system. Because I used MC to create a really clean structure for my video it is easy to find what I am looking for.

glynor · « **Reply #103 on:** January 13, 2012, 05:52:49 pm »

Quote from: rjm on January 13, 2012, 05:46:14 pm

Recently I ran into another huge benefit. I am using Air Video to send video from my server to my Apple TV with my iPad. Air Video has no concept of tags and simply navigates the file system. Because I used MC to create a really clean structure for my video it is easy to find what I am looking for.

True, though AirVideo in particular is smart enough to not even display files that it doesn't understand (including the sidecar XML and JPGs).

I also prefer, in theory at least, to have EVERYTHING on my media drive imported into MC, simply because there is way too much stuff in there to manage manually through Windows Explorer or any other means (and I only want stuff that MC manages in there).

However... I don't really care about them being "imported" per-say... The auxiliary files don't bother if MC manages them completely behind the scenes (so long as I never have to deal with them manually). What I don't want is a situation where there are a bunch of files on disk somewhere that I cannot deal with "through MC". Because if that happens, they're essentially "lost". If I ever move a big directory structure, I count on MC being able to browse all of the files in order to delete empty directories and whatnot.

So, I want those filesystem locations to be completely managed by MC, though I don't necessarily care if all of the stuff is imported into MC.

darichman · « **Reply #104 on:** January 16, 2012, 07:24:15 pm »

I like the new coverart changes.

Traditionally, all of my video covers have been in the form 'folder.jpg' in the same file as the video.
All my coverart files are also imported in the MC database.
I wish to convert/rename them all to match the video filename as per the new changes.

Is there a way to do this in one fell swoop? I note previous mentions that MC only touches files in the separate coverart directory when the 'cleanup' tool is run.

Johnny B · « **Reply #105 on:** January 23, 2012, 09:46:02 am »

I just tried MC17 today for the very first time and I quickly noticed some of my Blu-ray ISO Cover Arts were missing in my Cover Art view. Checked the wiki, let MC do its thing (Clean cover art folder), did some experiments = all in all I must say this is a mess, it's not working as described in wiki (probably due to some special characters) nevertheless even after renaming the ISOs to plain English names, MC could not find these problematic images (trying all the naming variations).
Disappointed -> going back to MC16 -> restoring backup DB and backup Cover Art folder

Matt · « **Reply #106 on:** January 23, 2012, 09:51:14 am »

Quote from: Johnny B on January 23, 2012, 09:46:02 am

I just tried MC17 today for the very first time and I quickly noticed some of my Blu-ray ISO Cover Arts were missing in my Cover Art view. Checked the wiki, let MC do its thing (Clean cover art folder), did some experiments = all in all I must say this is a mess, it's not working as described in wiki (probably due to some special characters) nevertheless even after renaming the ISOs to plain English names, MC could not find these problematic images (trying all the naming variations).
Disappointed -> going back to MC16 -> restoring backup DB and backup Cover Art folder

Please start a thread and post more technical details about the issue.

Thanks.

Chili-Jam · « **Reply #107 on:** February 09, 2012, 04:26:07 pm »

I have some album names that do not work when "Clean cover art folder..." is used.

It seems to happen every time the album name ends with a dot "."
e.g.
Bruce Springsteen - Greetings From Asbury Park, N.J.
Bruce Springsteen - Born In The U.S.A.
Glenn Hughes - From Now On.....
Gotthard - G.
Miles Davis - E.S.P.

My coverart got deleted as unreferenced

Johnny B · « **Reply #108 on:** February 09, 2012, 05:03:22 pm »

Regarding "Clean cover art folder" function, would it be possible to add an option "Keep unreferenced files" in any way? (maybe in "_unreferenced" folder) The way it is now is very brutal as MC does not even inform what files were deleted...

Matt · « **Reply #109 on:** February 10, 2012, 03:14:27 pm »

Quote from: Chili-Jam on February 09, 2012, 04:26:07 pm

I have some album names that do not work when "Clean cover art folder..." is used.

It seems to happen every time the album name ends with a dot "."
e.g.
Bruce Springsteen - Greetings From Asbury Park, N.J.
Bruce Springsteen - Born In The U.S.A.
Glenn Hughes - From Now On.....
Gotthard - G.
Miles Davis - E.S.P.

My coverart got deleted as unreferenced

Currently Media Center will save the cover art without a trailing dot, so it's possible the version with trailing dots is unreferenced.

It's sort of unnecessary that the system is removing the dots. It has to remove non printable characters of course, but should probably leave trailing dots.

Matt · « **Reply #110 on:** February 10, 2012, 03:24:37 pm »

In a coming build:
Fixed: Albums that ended with period characters would unnecessarily have their external cover art saved without the periods.

JimH · « **Reply #111 on:** March 14, 2012, 06:26:37 pm »

Is this problem solved now?

vagskal · « **Reply #112 on:** March 14, 2012, 06:51:23 pm »

Quote from: JimH on March 14, 2012, 06:26:37 pm

Is this problem solved now?

At least for artist images MC now retains a trailing dot as far as I can tell. Thanks!

gappie · « **Reply #113 on:** March 16, 2012, 06:04:39 am »

Quote from: Matt on January 13, 2012, 10:50:22 am

gappie, it would be helpful if you posted details about your problem and tried to work with us.

well tried to post them back then.. but i ive been trying mc 17 again the last few days.. and the cover art is a mess again.

so i will.

but first things first..

gab

gappie · « **Reply #114 on:** March 16, 2012, 06:26:32 am »

Part I: mc moved all my covers out of the coverart directory and placed them beside the movies (more about that later). the thumbnails, though, are not updated nor does it help to rebuild them. but mc does have the link in the imagefile tag, and shows it in the popup. but not in Theater View or any other thumbnail.. i need to download all new again when i want to have that fixed.

gab

EDIT: ah.. a trick i forgot but works: click 'remove coverart'. then on the question if you want to delete the coverart files permanently, say no.. then do a quickfind.. and there they are...

gappie · « **Reply #115 on:** March 16, 2012, 07:37:54 am »

part II: the reason why i think its a big step back that video covesr are not stored anymore in the cover directory (as it was in mc 11 to 16 as an option)..

a: i take small videoos with my foto camera. mc nicely takes them of the camera and puts them in a folder together with the images, at a place i have choosen. when i want to make a thumb for those small videoos, via use screengrab for thumbnail, mc places an extra image inside that folder and imports it... i always tried to keep those folders clean with only the images from my camera, and not without a reason. before the screenshots where nicely placed in the coverart folder, where they belonged.

b: i have my videoos on external hd.. they are off, and i turn them on when heeded. with the coverart besides the movies, the cover wont show up in the popup when the hd's are off.. before i had the covers on my internal disk and that problem did not excist..

c: now i have a coverart folder on my hd that is empty with folders mc made that are empty, apparently for important stuff.. but the covers are important for me, and i can not get them in there..

gab

MrHaugen · « **Reply #116 on:** March 16, 2012, 07:58:35 am »

I think this is a setback my self. Most problems would be solved if we just could point the files to ONE common location like the one artist and series images use today. Thing like moving media should not be such a big problem then I believe, when you know that cover art is either in the video folder, or as a default named image in that specific directory. Options should be individual for the media types, and you could even force moving of all images/thumbs if the option is changed, to prevent media moving and broken links between cover art. Would need a warning or something though.

If this change is to big, please consider an option to hide the sidecar files like jpg's and xml's when created. This would at least solve some peoples problems.

gappie · « **Reply #117 on:** March 16, 2012, 10:19:46 am »

Part III: in the old days the cover art for dvd videoos where saved as DVDVideo - SomeNameOfAFilm.jpg... so it was easy to backup and find back, especially when they were in their own folder... now they are saved besides the files and are called VIDEO_TS.jpg.... welll...

gab

rick.ca · « **Reply #118 on:** March 16, 2012, 06:56:01 pm »

Quote from: gappie on March 16, 2012, 06:26:32 am

mc moved all my covers out of the coverart directory and placed them beside the movies...

I. Solved.

II a. If it matters (I'm not sure why), move the videos to a separate folder.

II b. I'm not sure why the behaviour is so, considering it would be possible to continue to display thumbnails. I suppose the answer is thumbnails are removed when a cover is no longer found because that normally means the cover needs to be replaced and new thumbnails created. Maybe there should be an exception for drives taken off-line.

II c. The cover art folder is for images not related directly to files.

III. A VIDEO_TS.jpg file is saved in titled folder, so there's no impediment to backing it up or restoring it, as long as the backup includes the path (which, normally, a 'backup' does).

gappie · « **Reply #119 on:** March 16, 2012, 07:23:40 pm »

Quote from: rick.ca on March 16, 2012, 06:56:01 pm

I. Solved.

II a. If it matters (I'm not sure why), move the videos to a separate folder.

II b. I'm not sure why the behaviour is so, considering it would be possible to continue to display thumbnails. I suppose the answer is thumbnails are removed when a cover is no longer found because that normally means the cover needs to be replaced and new thumbnails created. Maybe there should be an exception for drives taken off-line.

II c. The cover art folder is for images not related directly to files.

III. A VIDEO_TS.jpg file is saved in titled folder, so there's no impediment to backing it up or restoring it, as long as the backup includes the path (which, normally, a 'backup' does).

no rick

I is not solved. its just a way around a bug.

II a. it would matter. ive set files that way since 11, as mc placed them there straight from the camera, and they felt happy there. moving them is out of the question.. for many reasons.
II b the point is that it is not displaying a thumb then, but connects to the file as written in the imagefile tag, always did.
II c.. no again. i ripped some dvd files and mc asked me about the dvd when i started rip, and gave me file info and a cover. the file info was placed with nicely in the tags but the cover ended up in the cover folder not connected to the file ofcourse, but just some orphan from a wrong question asked. besides that.. the covesr of my audio files are there, why not those of my videoos?

III.. i dont back up my video files. dont have the media for that. but i have the disks. ive always backed up my library with my coverart, as they are part of the tags. and easy to handle. making it much less work when it goes wrong..

lboregard · « **Reply #120 on:** March 16, 2012, 08:38:12 pm »

+1 on having movie covers (and fanart?) in one central folder (same as series).

rick.ca · « **Reply #121 on:** March 16, 2012, 10:04:31 pm »

Quote from: gappie on March 16, 2012, 07:23:40 pm

no rick

Sorry if you thought I was arguing with you. If you're unwilling to adapt to the change, that's your choice. But the (good) reasons for it have been explained a number of times, and the negative consequences that have been mentioned don't seem very compelling. So it seems unlikely it will be changed back to the way it was.

rick.ca · « **Reply #122 on:** March 17, 2012, 04:30:06 pm »

Quote

the answer shows you dont know what you are talking about

You can dismiss me as ignorant if you want, but at least I went to the trouble to consider your rant and found something of possible significance. But maybe that's a non-issue as well. In the only other mention of an issue with offline drives I'm aware of, it seems the covers are still being maintained in the separate folder.

Quote from: Matt on January 13, 2012, 10:50:22 am

gappie, it would be helpful if you posted details about your problem and tried to work with us.

But it seems you're bent on complaining, and have no interest in helping to improve the program.

Quote

nowhere in this thread there is written down a good reason for taking that option away.

Not being a fool like me, I suppose you don't have the time or patience to wade through this 3-month thread to confirm there are a number of posts that explain reasons for the change.

MrC · « **Reply #123 on:** March 17, 2012, 04:43:34 pm »

Let's all have a beer together and enjoy the day.

JimH · « **Reply #124 on:** March 17, 2012, 04:53:27 pm »

Quote from: MrC on March 17, 2012, 04:43:34 pm

Let's all have a beer together and enjoy the day.

Hear, hear! I'm buying.

rick.ca · « **Reply #125 on:** March 17, 2012, 05:00:39 pm »

Are you sure it's not beer that caused the problem in the first place?

gappie · « **Reply #126 on:** March 17, 2012, 05:27:59 pm »

Quote from: rick.ca on March 17, 2012, 05:00:39 pm

Are you sure it's not beer that caused the problem in the first place?

that is true rick..

Quote from: rick.ca on March 17, 2012, 04:30:06 pm

You can dismiss me as ignorant if you want, but at least I went to the trouble to consider your rant and found something of possible significance. But maybe that's a non-issue as well. In the only other mention of an issue with offline drives I'm aware of, it seems the covers are still being maintained in the separate folder.

well... mines are not.

Quote from: rick.ca on March 17, 2012, 04:30:06 pm

Not being a fool like me, I suppose you don't have the time or patience to wade through this 3-month thread to confirm there are a number of posts that explain reasons for the change.

i think i know the thread by heart rick, and there are reasons for some changes, but not for taking the option away..

Quote from: JimH on March 17, 2012, 04:53:27 pm

Quote from: MrC on March 17, 2012, 04:43:34 pm
Let's all have a beer together and enjoy the day.
Hear, hear! I'm buying.

guess it will be my place then.. the beer is fairly good in this part of the world

gappie · « **Reply #127 on:** March 17, 2012, 05:31:53 pm »

Quote from: rick.ca on March 17, 2012, 04:30:06 pm

But it seems you're bent on complaining, and have no interest in helping to improve the program.

now this is not true rick... im not just complaining.. i fight with all i have in me, because i think this change is really a bad one and another step in the iWMP direction.

gab

rick.ca · « **Reply #128 on:** March 17, 2012, 08:06:12 pm »

I suppose the offline drives thing is part of the bigger issue of how to handle HDD used as removable storage. Matt indicated here that will not be addressed soon. It's probably not worthwhile trying to fix cover art handling for this circumstance if the causal issue is to be dealt with in due course. While I don't do it myself, surely it's not a rare practise—so, hopefully, it will be addressed sooner than later.

Quote

i think this change is really a bad one and another step in the iWMP direction.

It's clear that you're unhappy with the change, but none of the other 'problems' support the contention the change is a bad one. They're sort of thing you nor anyone else would give a second thought if this were how it worked all along. The argument meta data should not be saved beside its media because "I don't want it there" or "it messes up my folders" is flaccid. I realize you're arguing for the reinstatement of an option rather than the reversal of a change, but the developers have already explained supporting that option is problematic and the new method is more reliable. So I think the change is good one, and I'm pretty sure "another step in the iWMP direction" is just more rhetoric.

gappie · « **Reply #129 on:** March 18, 2012, 04:56:31 am »

so apparently the coverart option is problematic for video covers but NOT for audio covers. ? and it is not problematic for what ever they want to put in the new but empty file and video and artist folder made beside my audio coverart. the fact that i can not easily backup my coverart anymore, something i sometimes put a lot of work in, is more then an 'i dont like it' argument..

the iWMP reference is not only rhetoric.. the reason i ones searched for a good media player was that i got sick of programs that started to move my files around without me having anything to say about it.. and this is what happens when switching to mc 17.

besides that. saving coverart in a separate folder was always the most secure way, from 11 to 16.. otherwise it was,for instance, easy to loose connection between covers and files when organizing files.. and now its not reliable anymore...

lboregard · « **Reply #130 on:** March 18, 2012, 08:02:04 am »

Quote from: glynor on January 11, 2012, 02:50:57 pm

It wasn't just TV Shows, it was all video types. That was just a common example, made worse when MC had the ability to Get TV metadata (including cover art) from online.

With the old system, if you had a bunch of video files in the same folder (maybe a M:\incoming\ catch-all directory) and they had the same [Name] tag, then they would all "share" the same cover art file. If you changed one, it would change them all (overwriting the previous file). This is because the files were stored with the filename template: Video - [Name].jpg. If you didn't store your images alongside the media files, it was even worse. No video in your database could have identical [Name] tags at all, or they would all share the same cover art file on disk.

For TV Shows, it was slightly different. If the video file in question was a [Media Sub Type]=TV Show, then it used the template Video - [Series].jpg instead. So, this would make all episodes of a particular show have the same cover art (continually overwritten by whatever was newest).

It was broken.

The new system ensures that EVERY video can have a unique file name without resorting to magic and randomized file names. The video files themselves all have to have unique file names (or else they couldn't co-exist on the filesystem), so just putting them right with the file, and using the same name, solves the problems once and for all.

after reading the whole thread, the explanation above made by glynor is spot on and it took only about 10 lines of writing (counting space lines)

nevertheless, my personal opinion is that i don't agree with the results of the analysis. Several naming schemes come up to mind that can prevent this issue ... if the database holds a pointer to where the files reside, it shouldnt be a problem when moving movies or series around .. actually i think it would be even easier, because you just need to do nothing ... the art folder would be in the same place as before.

also you should consider that there are different levels of users .. some will accept all the handholding you provide, while others may have a more personal view of how their content and related metadata should be handled.

for instance, after letting mc17 import cover art for my movies and series, it ended up changing the timestamp of all the folders where it deposited an image. you may say .. who cares ? ... well, i do and now i have to come up with a shell script to reverse these changes.

JimH · « **Reply #131 on:** March 18, 2012, 08:29:27 am »

Quote from: gappie on March 18, 2012, 04:56:31 am

... the fact that i can not easily backup my coverart anymore, something i sometimes put a lot of work in, is more then an 'i dont like it' argument..

Is that your major problem with the new system?

Fabricio · « **Reply #132 on:** March 18, 2012, 08:42:40 am »

I can not backup cover art audio. Only cover art video working for me.
JRiver media center only reads the tag information audio file and shows cover art, but no backup.

gappie · « **Reply #133 on:** March 18, 2012, 09:08:03 am »

Quote from: JimH on March 18, 2012, 08:29:27 am

Is that your major problem with the new system?

no, my 2nd major problem.. ill give it one shot to explain the major problem...

ill use mc to get the files of my camera. this is a mixture of images and small videoos. and mc does that nicely in a date folder.

then we make a backup of this new folder on a usb stick, and my wife takes it with her to a backupdisc on her work (ive lost a bunch of pictures ones after a crash and it still hurts a bit).

at one point we will start doing some tagging on the files. for me, one of the major tags of the videos is a screenshot that nicely shows what is in the video.. thats the 'cover'. before this cover was nicely residing in the cover map that was also backuped nicely. now it puts the image besides the other files as if it is something from my camera, which is not the case. ofcource i could before tagging move the videoos to an other map and do someother mc magic to still get them in the same views.. but this will break the very easy backup system we use. besides that.. we sometimes change the cover to a better one.. the coverart folder nicely takes up that change.

JimH · « **Reply #134 on:** March 18, 2012, 10:08:39 am »

Quote from: gappie on March 18, 2012, 09:08:03 am

no, my 2nd major problem.. ill give it one shot to explain the major problem...

ill use mc to get the files of my camera. this is a mixture of images and small videoos. and mc does that nicely in a date folder.

then we make a backup of this new folder on a usb stick, and my wife takes it with her to a backupdisc on her work (ive lost a bunch of pictures ones after a crash and it still hurts a bit).

at one point we will start doing some tagging on the files. for me, one of the major tags of the videos is a screenshot that nicely shows what is in the video.. thats the 'cover'. before this cover was nicely residing in the cover map that was also backuped nicely. now it puts the image besides the other files as if it is something from my camera, which is not the case. ofcource i could before tagging move the videoos to an other map and do someother mc magic to still get them in the same views.. but this will break the very easy backup system we use. besides that.. we sometimes change the cover to a better one.. the coverart folder nicely takes up that change.

So the problem is that you want to maintain two sets of video files and their cover art, but that you do the tagging after you've made the split into two sets. Is that it?

gappie · « **Reply #135 on:** March 18, 2012, 10:19:20 am »

Quote from: JimH on March 18, 2012, 10:08:39 am

So the problem is that you want to maintain two sets of video files and their cover art, but that you do the tagging after you've made the split into two sets. Is that it?

sometimes english is hard for me.. so maybe you mean the same..
i want to, and have been till 17, maintain one set of files that comes from my camera, so images and videos, that will be backed up outside this house. and after tagging it including the important cover, will be easy to recover when things go wrong..

Matt · « **Reply #136 on:** March 18, 2012, 10:41:23 am »

Glynor gave a nice explanation of why we made cover art changes:
http://yabb.jriver.com/interact/index.php?topic=68476.msg464973#msg464973

I've tried to document how things work here:
http://wiki.jriver.com/index.php/Cover_Art

I know several users want to use a common folder instead of sidecars for video. The complexity (coding and user support) are major deterrents. I described this here:
http://yabb.jriver.com/interact/index.php?topic=70666.msg476942#msg476942

@gappie, I'm not able to understand your issue well. You said:

Quote

i want to, and have been till 17, maintain one set of files that comes from my camera, so images and videos, that will be backed up outside this house. and after tagging it including the important cover, will be easy to recover when things go wrong..

Why does where a file is stored change whether it can be backed up? I use robocopy + batch files on my backup drives, and this allows pulling backup data from all over my computer. I assume most backup programs support something similar. I would recommend backing up all video sidecars (tags, subtitles, commercial skip, cover art, etc.) as long as you're doing it.

gappie · « **Reply #137 on:** March 18, 2012, 10:59:31 am »

Quote from: Matt on March 18, 2012, 10:41:23 am

@gappie, I'm not able to understand your issue well. You said:
Why does where a file is stored change whether it can be backed up? I use robocopy + batch files on my backup drives, and this allows pulling backup data from all over my computer. I assume most backup programs support something similar.

that is nice matt.. ive installed systems like that oft enough by clients.. and it is overkill, and to complex, and not necessary for us at home. especially since a library and coverart backup where enough. and the original important camera files ofcourse somewhere else. and a usb stick to carry it over to the machine of my wife at work, where she can do whatever she wants with it as long as the name and the name of the folder stay the same...

btw.. with audio i do the same.. but about once every year.. i just add the cd files i ripped to some loose hds, also somewhere in a drawer outside here. mcs database takes care of remembering the tag changes. no need for things that look at time stamps and stuff.

JimH · « **Reply #138 on:** March 18, 2012, 10:59:49 am »

Right now, you do this:

Import > Copy to USB stick > Tag (including cover art) and it doesn't work.

But this would work:

Import > Tag > Copy to USB

And this should also work

Anytime you re-tag, copy movie and cover art to USB again.

MrHaugen · « **Reply #139 on:** March 19, 2012, 04:10:11 am »

Quote from: Matt on March 18, 2012, 10:41:23 am

Glynor gave a nice explanation of why we made cover art changes:
http://yabb.jriver.com/interact/index.php?topic=68476.msg464973#msg464973

Yes, that is a good explanation. However, it does not fix all problems. It introduces lots of problems as well, as Gappie have proved. I support them fully. It DOES fix the problems with similar filename and using the same cover art. But this is imo, a quick and dirty way of fixing the problem. Reducing functionality and limiting the use of MC's potential for all of us that never ever had this sort of problems.

Quote from: Matt on March 18, 2012, 10:41:23 am

I know several users want to use a common folder instead of sidecars for video. The complexity (coding and user support) are major deterrents. I described this here:
http://yabb.jriver.com/interact/index.php?topic=70666.msg476942#msg476942

There should be several ways of dealing with this. I'll mention a couple of things I've been thinking of.
- You could allow the old behavior, but strongly warn the users of the potential problems and not giving support for it's use.
- You could go the middle way. Allowing users to separate sidecar files from their media to a custom base path. Please use the current Art folder and add to this. It's a good starting point, and it keeps things in a system as opposed to here and there like it used to be. More standards and less fragmentation. To be sure to avoid duplicates, you could mirror the directory structure for the media in this "custom" folder. That way, duplicates would be just as unlikely to happen as today.
- You could go all out and allowing users to save things like the old days, but adding a number to files if they are duplicates, in such a way that MC can easily interpreter the real name and attributes. A special combo of a special character and a number perhaps?

As mentioned, allowing MC to write the hidden attribute to sidecar files would solve much of what the users asks for and asks questions about. A few of Gappies examples will not be solved with this though.
I have no problem with either solution. But I'm afraid I would be forever disappointed with todays solution if it remains. My biggest problem is how this subject is handled by a few. Some think this is the only solution and the ultimate solution to end all problems. And I just can't accept that. Because all the posts on interact about this proves very much otherwise. I can not remember that we had this much posts about images overwriting each other...

4BYE · « **Reply #140 on:** March 19, 2012, 01:12:42 pm »

I agree too.

@Gappie: Now I know what you mean with the cover art. I thought it didn't affect me the way I'm working but it does.

I do understand that in some cases cover art got overwritten. It did in a few cases with re-makes of movies and some episodes or movies with the same name. But I tackled that problem by renaming them to e.g. 01. Pilot (Las vegas) or Gone in 60 Seconds (2000).
Just maybe it would have been easier if you got warned like windows does when overwriting a file. "Are you sure you want to change this for that" etc. I could think of a lot of ways to add something to the filename to make it unique. Like a date with time code or adding "001" to it automatically.

I would be fine with the new solution if I could also save my cover art in to a back-up folder too. That way I'm saved when I do something stupid...

I could change my way of working but I have to save my cover art image first to a back-up file and then do it your way. The only thing I'm a bit afraid of is MC moving my files around when I'm not paying attention or make a mistake.

I just switched to MC17 at the right time...

I can see the point of having all the files into the same folder (cover art, sidecar.xml) but I have to think really good about everything before making decissions I can't turn back easily. In the worst case I can go back to MC16 to see what happens here and be able to add files the way I did. Just my two cents...

gappie · « **Reply #141 on:** March 19, 2012, 03:06:22 pm »

Quote from: 4BYE on March 19, 2012, 01:12:42 pm

@Gappie: Now I know what you mean with the cover art. I thought it didn't affect me the way I'm working but it does.

i actually expected that too, that it would not affect you , theo. but i nearly typed: cool..

for me its one of the worst mc updates ever...

gab

rick.ca · « **Reply #142 on:** March 19, 2012, 03:18:20 pm »

Quote from: 4BYE on March 19, 2012, 01:12:42 pm

I thought it didn't affect me the way I'm working but it does.

I see from another topic you have some issues with cover art on upgrading from MC16 to MC17. I'm not sure what that's about and won't comment here, but I'm sure things will work fine for you once those issues are resolved.

Let's keep this in perspective. We're talking about where the program saves data files—on the system's primary data storage device. We normally don't care much about such things, as long as they're rational and consistent, and allow things like backup routines to work properly. We can, of course, have our own independent interest in the same files, and therefore in how they are saved. But it doesn't follow that entitles us to claim the method used by the program is inferior, wrong or an unacceptable inconvenience. Saving meta data files beside media files is simple, rational and reliable. If there were no history here, it would be inconceivable this would not be the first choice of how it should be done, or that there could be any compelling reason for an optional alternative. The current controversy is good evidence of why such unnecessary options should never be allowed.

There is an issue with using removable HDD for media storage, but that's about recognizing handling them as removable storage. Ignoring that issue and insisting on some workaround for it's impact on cover art doesn't make sense.

Quote

I would be fine with the new solution if I could also save my cover art in to a back-up folder too.

If you're using a conventional backup system to backup media, the cover art will automatically be backup according to how you've configured that routine (daily, weekly, multiple versions, etc.). With the meta data saved with and beside the media, there can be no errors or confusion about what is being backed up or how to restore it. It you don't have such a backup system and want to backup only the cover art, you can use a simple batch file or one of a wide variety of free copy, synchronization or backup utilities to backup the image files in a video media folder structure. Such a routine could save multiple versions of each image (which is essential for recovering from doing something stupid), and be scheduled to run automatically as often as you consider necessary. That has to be a much better form of backup than whatever you have now.

Quote

I can see the point of having all the files into the same folder (cover art, sidecar.xml) but I have to think really good about everything before making decissions I can't turn back easily.

I suggest you focus on getting your cover art restored in MC17. Once you have, the current system for managing cover art will work well for you.

4BYE · « **Reply #143 on:** March 19, 2012, 04:31:32 pm »

I don't know what is easier than having a Cover Art folder that I can back-up whenever I want. Why would I take my seven or eight video HD and try to save those jpgs from there? I can see both sides of this issue but everyone has to decide for themselves if it works or not or is pleased or not. Reading all the topics about it it sure is a bigger thing.

I based all my things on how it worked. My simple thoughts were that I would go on like I did and had finally GIZMO/WebPlay working with MC17.

JimH · « **Reply #144 on:** March 19, 2012, 05:29:59 pm »

We recognize that there is a problem and we talked it earlier today. We think we can improve the situation a little.

But the request to store all cover art in a single directory isn't workable.

You could probably also help yourself by moving your home video files out of the image directory.

rick.ca · « **Reply #145 on:** March 19, 2012, 06:25:37 pm »

Quote

I don't know what is easier than having a Cover Art folder that I can back-up whenever I want. Why would I take my seven or eight video HD and try to save those jpgs from there?

MC no longer saves them in one folder. So, at best, this is a request for convenience feature that has nothing to do with the sound operation of the program. Data backup is generally a user responsibility, and there are a number of different approaches one might choose.

If your choice is to only backup covers, then doing so is that much easier.

Matt · « **Reply #146 on:** March 19, 2012, 06:35:28 pm »

A couple proposals we discussed:

1) An option to hide sidecars
2) A tool to make a copy of cover art for backup (Cover Art > Back Up Cover Art...)

Adding an option to always store video sidecars (tags, commercial skips, subtitles, cover art, etc.) apart from the video is not on the table for v17.

lboregard · « **Reply #147 on:** March 19, 2012, 09:19:28 pm »

i think you guys have thought hard about this and came up with the solution you consider is the best.

mc's strongest selling point (for me) is the direct show playback capability (it's second to none).

even the gui, which isn't comparable (yet, perhaps) to xbmc's or meedios', is refreshingly simple and functional.

nevertheless, i will have to pass on using it as my htpc software.

as _really_ strong as the playback is, i just don't like how the metadata management works (my personal opinion).

i'll keep an eye out for mc18.

4BYE · « **Reply #148 on:** March 20, 2012, 02:50:33 am »

Quote from: Matt on March 19, 2012, 06:35:28 pm

A couple proposals we discussed:

1) An option to hide sidecars
2) A tool to make a copy of cover art for backup (Cover Art > Back Up Cover Art...)

Adding an option to always store video sidecars (tags, commercial skips, subtitles, cover art, etc.) apart from the video is not on the table for v17.

Option 2 sounds great to me. I don't mind having sidecars in the same folder too. I want to have my cover art at hand not only for back-up but for other reasons too.

I don't know why sidecar files should be hidden? If they are there I would like to see them.
Maybe I didn't read the topic about that...

4BYE · « **Reply #149 on:** March 20, 2012, 03:17:01 am »

Quote from: rick.ca on March 19, 2012, 06:25:37 pm

MC no longer saves them in one folder. So, at best, this is a request for convenience feature that has nothing to do with the sound operation of the program. Data backup is generally a user responsibility, and there are a number of different approaches one might choose.

If your choice is to only backup covers, then doing so is that much easier.

I don't know what you use MC for but only use it for sound was in the stone age for me...
A great program like MC has more to offer than only produce sound that's why I stick to it so far.
Having extra options that have nothing to do with sound or basic use makes it even greater imo.

I can see you want to defend the choice of the "saving to cover art folder" being left out but I find your comments a little weak. I haven't put this option in, it was there, so I used it in a way that was convient to me. Maybe if it wasn't I had a different way of handling them at that point.

So I think we might conclude that there might be a tool in the future for putting them into a special folder and that there will be no way of having it "the old way". I'm fine with that unless in MC18 everything is turned back and starts over again the other way around... (just my opinion of course)

Something came to mind though... Do all my hd's have to be (powered) on to see my cover art in the new way style e.g. my movies?

INTERACT FORUM

Author Topic: Cover Art (Read 27821 times)