Topic: Cover Art (Read 27820 times)

jgreen · « **Reply #50 on:** December 16, 2011, 07:25:46 pm »

Rick.ca--

I get that part, but like many MC users I use root-level views (video, images, audio and that other one) for 99% of my library navigation. Cover art, in a sense, is an MC "system" file.

rick.ca · « **Reply #51 on:** December 16, 2011, 08:48:17 pm »

Quote

I get that part, but like many MC users I use root-level views (video, images, audio and that other one) for 99% of my library navigation. Cover art, in a sense, is an MC "system" file.

Sorry, I don't understand. If you don't want to import covers, don't. If you do, but don't want them to appear in your root level views, exclude them.

MrHaugen · « **Reply #52 on:** December 16, 2011, 09:17:13 pm »

I do think that jgreen knows about how to avoid cover art being imported, or how he can exclude art from the normal views. That is not the point. The point is that this is things most users (probably by far) consider them "system" files as jgreen calls it. You can seriously mean that users should start to edit their exclusion list for each view?

You should of course be able to import it if you want. But most of this stuff should probably be treated as "Special Files" that is not normally imported. Like the option we have today for folder.jpg and so on. That is where this discussion comes from I believe. Just a heads up to JRiver, to think about this files for new imports. One of Parks posts earlier in this thread I think.

rick.ca · « **Reply #53 on:** December 16, 2011, 10:49:05 pm »

Quote

That is not the point.

Well, thank goodness you're here to tell us what the point is. I still don't get it. He said he wanted to import cover art, but also seems to be saying he's concerned they'll show up in his views. Seems inconsistent to me, especially considering both are under his control.

MrC · « **Reply #54 on:** December 16, 2011, 11:28:29 pm »

This is gonna hurt.

rick.ca · « **Reply #55 on:** December 16, 2011, 11:59:43 pm »

Perhaps a more appropriate response would have been...

MrHaugen · « **Reply #56 on:** December 17, 2011, 07:56:16 am »

Funny guys....

Yea. I see that he said that. I was mixing up some replays. Sorry.

park · « **Reply #57 on:** December 17, 2011, 10:40:22 am »

May I ask what the rationale for forcing video cover art to be put next to files is? I have always used a specified cover art folder on a shared drive that has sufficiently survived each MC upgrade with no hassles. I don't like the idea of sidecar cover art.

Also, can I ask again why there isn't an option to embed the cover art directly into mp4/mkv files?

gappie · « **Reply #58 on:** December 17, 2011, 01:54:43 pm »

Quote from: park on December 17, 2011, 10:40:22 am

May I ask what the rationale for forcing video cover art to be put next to files is? I have always used a specified cover art folder on a shared drive that has sufficiently survived each MC upgrade with no hassles. I don't like the idea of sidecar cover art.

i guess you wont get an answer... my guess: so that it would be easier to program for the including of the cover when moving video files. ofcourse that was never a problem when you saved them to an external folder. except when you renamed them...

i wanted to roll back for a while because of it... but since my coverart folder got so messed up, i lost all connection, so i had no choice then to live with it.. ahwell.

gab

Matt · « **Reply #59 on:** December 17, 2011, 08:14:52 pm »

Quote from: park on December 17, 2011, 10:40:22 am

May I ask what the rationale for forcing video cover art to be put next to files is? I have always used a specified cover art folder on a shared drive that has sufficiently survived each MC upgrade with no hassles. I don't like the idea of sidecar cover art.

We believe it's the cleanest way to handle per-episode artwork for television.

It makes it so that we can be sure to have a unique name for the artwork so that it won't collide with the artwork for a different video.

Matt · « **Reply #60 on:** December 19, 2011, 10:28:05 am »

Quote from: Alex B on December 16, 2011, 06:19:50 pm

Build 56,

I intended to test the fixed illegal characters handling, but "Save Cover Art To External Location Specified In Options" didn't work at all when I tried to copy folder.jpg audio cover art to the specified location (W:\_pMCmedia\art\). Nothing appeared in the the Albums subfolder and the Image File field continued to show "Folder.jpg".

The tool worked with video cover art as described. It correctly created 22 "episode" sidecar images from the old single "series" image (I had 22 video files and one cover art file in the test folder).

I haven't been able to reproduce this. I was able to move to Folder.jpg or to the cover art folder.

Thanks for any additional details.

Alex B · « **Reply #61 on:** December 19, 2011, 10:46:54 am »

Quote from: Matt on December 19, 2011, 10:28:05 am

I haven't been able to reproduce this. I was able to move to Folder.jpg or to the cover art folder.

Thanks for any additional details.

It works today with the same test files. Could it be possible that a reboot was needed?

Matt · « **Reply #62 on:** December 19, 2011, 10:52:52 am »

Quote from: Alex B on December 19, 2011, 10:46:54 am

It works today with the same test files. Could it be possible that a reboot was needed?

I can't think why.

One thing that gets a little weird is when the program is also saving in the file tag. It can cause the 'Image File' field to get set to 'Inside File' so that it's hard to know, at least from inside the program, if the copy to the specified location is working.

Alex B · « **Reply #63 on:** December 20, 2011, 02:35:14 pm »

Quote from: JimH on December 16, 2011, 06:52:57 pm

I think this is the first time I've ever seen you sit up straight and utter a near-profanity. Matt and John deserve a lot of credit for getting your compleat attention.

Hyvää Joulua

And thanks for ten years of helping us walk straight!

Thanks Jim. Helping you to walk straight (when I can) is not always easy, but I have never lost my trust in you..

Hyvää Joulua ja Onnellista Uutta Vuotta! (Merry Christmas and Happy New Year!)

MrHaugen · « **Reply #64 on:** December 21, 2011, 01:59:50 am »

Quote

4. Changed: Cover art assigned to video or data files is always stored next to the file.

Does this mean that placing cover art for episodes via sidecar files to another directory is impossible? In that case, me and other Sickbeard users is pretty screwed. I got all my episode specific cover art in a sub folder for each season.

rick.ca · « **Reply #65 on:** December 21, 2011, 03:37:19 am »

Quote

In that case, me and other Sickbeard users is pretty screwed.

It seems to me MC found Sick Beard images in subfolders before. Why would it stop now?

MrHaugen · « **Reply #66 on:** December 21, 2011, 03:56:48 am »

Sickbeard updates the image URL in the sidecar files directly, and MC updates the database with this changed info. I'm just afraid that this system might break this. Either removing links and rebuilding art next to the episodes, or moving the current art next to the files. Leaving me with empty directories for each season. I don't think it will, but I'm not willing to test it in my live system. Don't have a decent test system setup right now either

gvanbrunt · « **Reply #67 on:** December 21, 2011, 08:24:29 am »

MC doesn't change where you store images. If you already have them somewhere else. It only places them in MC's "default" locations if you use MC to fetch metadata or move them etc. At least as far as I know. I'll have some time to play over the holidays and see how this relates to Sickbeard.

Also it isn't Sickbeard directly that saves the files where they are now. It's the modification that sgomes did that does it. If I have more time I can see about fixing that as well if he does not. I need to create some kind of a script etc with the git repository so I can merge the mod with the latest release of sickbeard. At least until the mod makes it into the main release. I don't think it will though.

MrHaugen · « **Reply #68 on:** December 21, 2011, 09:49:01 am »

Quote from: gvanbrunt on December 21, 2011, 08:24:29 am

It's the modification that sgomes did that does it. If I have more time I can see about fixing that as well if he does not. I need to create some kind of a script etc with the git repository so I can merge the mod with the latest release of sickbeard. At least until the mod makes it into the main release. I don't think it will though.

I've been planning on looking at this my self, but I've been way to busy with setting up my new network and servers lately. And now we have Christmas and the new star wars MMO. Time will fly

mojave · « **Reply #69 on:** December 21, 2011, 03:45:54 pm »

I'm ripping my first TV shows (Columbo) to my HTPC. I see on TMDb that there is Season cover art. When I go to Theater View and use the Season view it will show me one of the episode covers when listing the seasons. Are there any plans to add Season cover art?

park · « **Reply #70 on:** December 23, 2011, 10:53:15 am »

So as I feared, the new system is going to make life a bit more difficult for me. I have a share called "Home Movies". When I plug my camcorder in and import the files, it generally imports videos, but sometimes the odd photo too. If I have auto import set to import photos too I am able to see the photos appear in my Images view, and then rename/move them inside MC easily. However, if that share is now going to be full of thumbnail sidecar files I will have to turn off the import of images for that share, and thus will have to search the share manually for photos regularly.

Surely others will see similar problems? Can the sidecar files not be made into a new filetype? Kinda like what you did with the .jtv thing. Or, could you not just figure out a way for us to designate a single folder like before and not have filename issues? It doesn't sound like an insurmountable problem to me, and yet the sidecar images could be an organizational nightmare for a lot of users.

gappie · « **Reply #71 on:** December 23, 2011, 12:50:57 pm »

Quote from: park on December 23, 2011, 10:53:15 am

So as I feared, the new system is going to make life a bit more difficult for me. I have a share called "Home Movies". When I plug my camcorder in and import the files, it generally imports videos, but sometimes the odd photo too. If I have auto import set to import photos too I am able to see the photos appear in my Images view, and then rename/move them inside MC easily. However, if that share is now going to be full of thumbnail sidecar files I will have to turn off the import of images for that share, and thus will have to search the share manually for photos regularly.

Surely others will see similar problems? Can the sidecar files not be made into a new filetype? Kinda like what you did with the .jtv thing. Or, could you not just figure out a way for us to designate a single folder like before and not have filename issues? It doesn't sound like an insurmountable problem to me, and yet the sidecar images could be an organizational nightmare for a lot of users.

yeah... i did an autoimport on the files from my camera and was surprised to see all these 'new ' pictures.... it tuned out to be the screenshots from the mov files the camera takes. before they were nicely in a folder outside the autoimport. now it messes up my nicely organized folderstructure and all my views.. and that is only just one issue..

btw.. my coverart folder is still empty.. use mc the whole day and still have no idea what should get in there.

rick.ca · « **Reply #72 on:** December 23, 2011, 06:29:37 pm »

Quote from: park on December 23, 2011, 10:53:15 am

Surely others will see similar problems?

I must be missing something. Why does it matter? Unwanted files are easily excluded from views using Rules for file display. I don't import images from my Video folder, but I do for my Audio folder—to get the cover art. The issue seems to be the same. I get my Audio cover art, but I have to exclude or otherwise deal with the other images in there I'm not interested in. I think that's an easy and sensible thing to do—rather than attempt to dictate how files get saved in a file system.

park · « **Reply #73 on:** December 23, 2011, 08:52:46 pm »

The point Rick, is that thumbnails will add a lot of noise to our views (especially views based on imports from phones, cameras and camcorders), and give us more work.

rick.ca · « **Reply #74 on:** December 24, 2011, 03:41:59 am »

The point, Park, it that in a system allows the user to control what files are imported, and then whether or not the files that are imported are displayed in any particular view, arbitrarily deciding some files are "noise" to be excluded is unnecessary and more likely to be a source of confusion than help anyone.

gappie · « **Reply #75 on:** December 24, 2011, 03:47:52 am »

Quote from: rick.ca on December 24, 2011, 03:41:59 am

The point, Park, it that in a system allows the user to control what files are imported, and then whether or not the files that are imported are displayed in any particular view, arbitrarily deciding some files are "noise" to be excluded is unnecessary and more likely to be a source of confusion than help anyone.

the problem is, rick, that for instance camera files are a mixture of jpg and what ever video files so excluding jpg files is no solution... mc imports them from the camera and places them in one folder. and now it polluted all those folders with new jpg files.

marko · « **Reply #76 on:** December 24, 2011, 04:05:30 am »

Rename, Move and Copy is still failing on mkv files with coverart too

park · « **Reply #77 on:** December 24, 2011, 05:50:03 am »

Quote from: rick.ca on December 24, 2011, 03:41:59 am

The point, Park, it that in a system allows the user to control what files are imported, and then whether or not the files that are imported are displayed in any particular view, arbitrarily deciding some files are "noise" to be excluded is unnecessary and more likely to be a source of confusion than help anyone.

It's not arbitrary when the software adds them to your storage pool. That's what I call noise.

gvanbrunt · « **Reply #78 on:** December 24, 2011, 10:43:21 am »

I can see the point to some degree when you mix video and pictures in one folder as is the case with many cameras. I never noticed this as I hate leaving them this way and have always moved them to separate "areas". However it does bring up a usability issue. New users will likely have issues dealing with this situation, but in every other product I've used (that supports meta data) it isn't supported either. You have to have them in separate area's.

Perhaps it's time for MC to support a Camera Download feature? It would move things to proper area's and label etc. That would save me work as my current down loader doesn't allow separating videos from images...

park · « **Reply #79 on:** December 24, 2011, 11:05:46 am »

gvanbrunt, I would love to see MC be able to ingest footage directly fromt the camcorder, but with the myriad of camcorder types and file structures, and different ways they store file metadata would, I think, end up dominating the developer time of a whole version.

The simple fact is that a couple of weeks ago, all of the images MC required to draw it's thumbnails etc were nicely separated away from content that I purposely chose to include in my library. Things worked fine. Now, all of the files that 'I' import into the library are going to be mixed with images that MC decides to add to my storage for its' own internal purposes. That or I am going to have to customize every Import rule for each of my video shares to exclude just cover art type images. Or else I am going to have to make sure that I ingest photos and videos in a different way to how I have been doing. Regardless, due to this change my (possibly recurring) manual labor has increased.

One solution would be to embed the cover art into file types that support it.

gvanbrunt · « **Reply #80 on:** December 24, 2011, 12:50:34 pm »

Almost every camera and phone I've ever owned have had all the video's and files dumped under a directory called DCIM. On some of theses devices you could choose a more elaborate scheme, but that is certainly not the norm. So fetching files should be trivial for most devices. You would simply have to point MC to the correct directories under DCIM. Those that don't allow file system access are something else all together and I'm not suggesting MC support those. This is just an idea anyway that would save work for some of us.

What I don't think is feasible is to allow anyone to store files anywhere they want and have it "just work". This may have been ok back in the days that MC mostly did audio only, but now that the product is expanding to enable wider support of meta data it's unrealistic. Possible, but if they continue down that path, it will eat up way more developer time trying to deal with every scenario possible. This is exactly why move/copy never worked properly with movies etc before. Combine that with the pile of other features (cover art etc) and it would eat more. These features have been left "broken" for years because of this. I would much rather see more features in MC than it allowing me to store everything in any fashion I want on disk.

I have a very large collection of movies, and every time I do maintenance on it, it has eaten up many hours "hand moving" things etc. Fetching meta data, tagging etc have been what has eaten up most of my time. It is much larger than the time I spend separating video and pictures when fetching from my devices, and we take a lot of pictures/movies from a variety of devices.

rick.ca · « **Reply #81 on:** December 24, 2011, 02:47:02 pm »

Quote from: gvanbrunt on December 24, 2011, 10:43:21 am

Perhaps it's time for MC to support a Camera Download feature? It would move things to proper area's and label etc. That would save me work as my current down loader doesn't allow separating videos from images...

Thanks for attempting to steer this towards potential solutions that might actually be feasible. But I think it important to first identify exactly where a solution is required and why.

While there are many different circumstances and preferences, surely most users are putting media in folders according to media type, and then configuring Auto-Import to import from each of these folders according to the type of media they contain. A more practical way to look at this situation is files are put in folders according to the Auto-Import configuration that will import the desired media correctly. That view would lead to what might be complete solution to this issue. If one wants to import image meta data for home video and not for other types of video, then these are two different media types requiring different Auto-Import configurations. This necessitates putting them in separate parent folders that can be configured differently.

I am, of course, generalizing. Any user can potentially face a wide variety of different situations and needs, many with a number of options for dealing with them. As I mentioned previously, one of those options is to simply import media "as is" and configure views to include or exclude different types as needed. The point is, well-designed software will give the user the tools necessary to deal with whatever their situation or preferences. It won't impose arbitrary solutions like saving cover art with as a different file type, attempting to embed them or dictating what may be saved in the file system. The point too, is the user must take responsibility for deciding how this is done. While that may imply unwelcome "work" for the user, the program would not be doing the user any favours by making arbitrary choices and restricting those available to the user.

Saving video meta data "beside" the media is a perfectly sensible thing to do. It's easier to find, understand, keep together and maintain. It's the natural way to save meta data in a file system. There would have to be very good reason not to do so. Those don't include, "I don't like to see them there" or "I don't think I should have to make a minor change to my Auto-Import configuration."

Now, as for a camera download feature...I don't use it much, but I know there is one. It's easy to see some additional import options might be useful as tools for handling different situations. The obvious example would be the ability to set multiple rules for importing different file types to different folders—or not importing at all. Maybe there should be presets, so that different sets of rules can be saved for different devices or circumstances.

gvanbrunt · « **Reply #82 on:** December 24, 2011, 03:32:37 pm »

I think what park was getting at was that if he imports from a video camera, the camera itself creates "meta data" in the form or snapshots. When you do an download it pulls both the video and these snapshots which he normally wants imported as well. So far there is no problem. However at some point MC creates thumbnails as covers and these are also placed in the folder. On the next AutoImport because of his settings he also gets these unwanted covers imported as well.

There are probably a few ways to work around this, but all of them are going to involve some work for him. His problem is that the new feature is causing him extra work. I can understand that for sure. I've spent my far share of bashing my head against a wall with "broken/half working" features so I sympathize.

I'm throwing out ideas on how we might work around that issue, but I'm also raising the concern to JRiver that this may stump new users which is a big concern. The more users that adopt MC, the more resources JRiver will have to develop the product and we all benefit from that. So even though we both might not agree with parks idea on how to fix the problem, I think something still has to be done. My suggestion is for JRiver to allow meta data to be stored "off line" the same as cover art for albums can. Yes there are challenges to be overcome, but they are not insurmountable. I think that in a default config meta data should be stored here. Then new users will not be turned off by files suddenly appearing in their media directories.

rick.ca · « **Reply #83 on:** December 24, 2011, 05:08:14 pm »

Quote

However at some point MC creates thumbnails as covers and these are also placed in the folder.

If this is the case, the situation should be properly described so we can understand what's going on and what might be done about it. So are we to assume these snapshots (which, by definition, are meta data) are also not cover art? Or are they intended for that purpose, but not recognized as such by MC? Or for some reason, MC's screenshot created on import is considered more appropriate? What are the filenames of these snapshots? Can they be distinguished from the screenshot created by MC based on filename content or form? If so, could a rule be used to tag them on import, and then use that as a basis for including them in views while excluding covers?

But your assumption doesn't seem to fit the issue as originally described...

Quote from: park on December 23, 2011, 10:53:15 am

When I plug my camcorder in and import the files, it generally imports videos, but sometimes the odd photo too. If I have auto import set to import photos too I am able to see the photos appear in my Images view, and then rename/move them inside MC easily.

To me, "odd photo" clearly suggests actual photos, not meta data snapshots accompanying each video. This is why I asked for clarification in the first place. All we've been told since is cover art in relation to them is "noise" or "pollution" in the "storage pool"—all meaningless terms offering no insight whatsoever as to what the real issue is.

park · « **Reply #84 on:** December 24, 2011, 08:34:18 pm »

The problem is that MC generated art shouldn't be imported into my library. I don't want to have to create whole new Image views for dealing with the cover art. I do want the flexibility to be able to have my photos and videos from my cameras to be in the same storage areas. The current method of having to change my auto-import settings for to exclude cover art is not good enough. No new user should have to jump through hoops to exclude files that the software itself is creating.

The potential solutions as I see them are:

1. Embed the cover art in the files.

2. Make MC smart enough to be able to ignore the thumbnail files (as it can do currently with folder.jpg' files)

3. Return the option to save cover art in a separate folder. It has been working for years, and is still an option for audio files. Therefore I just not convinced that it would be so hard for videos.

rjm · « **Reply #85 on:** January 10, 2012, 03:28:22 pm »

Just tested this for the first time using Get Movie Info. I do not like the behavior.

Sidecar artwork is saved next to video. So far so good. But this artwork is not imported. I have policy that every file in my media folders must be imported and properly tagged. So I import and tag the artwork. Now I decide to move the video. MC also moves the artwork to the new location of the video. Makes sense.

Here is the problem. The moved artwork is no longer imported. And the originally imported artwork is now orphaned.

So I think maybe I can outsmart MC. This time I select both the video and the artwork and then move them together. Nope. Artwork at new location is no longer imported and tags have been lost.

I'm an experienced user and my brain hurts thinking about how I am going to avoid creating a huge mess every time I reorganize my video.

There must be a better way. What was wrong with the way it was?

JustinChase · « **Reply #86 on:** January 10, 2012, 10:27:47 pm »

I have been working on fixing my own bit of personal stupidity, and it involves me having to delete duplicate videos.

When I delete many video files that have cover art jpg's associated with them, the jpg's don't get deleted along with the videos. I think they should. I know there's a possibility for this to be a bad thing, but covers MC has downloaded, and named exactly the same as the video are unlikely to be anything that needs to be kept when the associated video is deleted.

Can this be changed/fixed?

glynor · « **Reply #87 on:** January 10, 2012, 11:30:25 pm »

Quote from: rjm on January 10, 2012, 03:28:22 pm

What was wrong with the way it was?

It was broken before. You couldn't have different cover art for different TV Show episodes if they were in the same folder. So every episode of a particular show would have identical thumbnails, continually overwritten by whatever was newest.

Quote from: rjm on January 10, 2012, 03:28:22 pm

Here is the problem. The moved artwork is no longer imported. And the originally imported artwork is now orphaned.

So I think maybe I can outsmart MC. This time I select both the video and the artwork and then move them together. Nope. Artwork at new location is no longer imported and tags have been lost.

I agree with some of this. Certainly all the stuff about when MC moves or deletes a video. The sidecar.jpg needs to move and be deleted at the same time.

Clearly, the problem with importing the files by default is that most users don't want to have their personal photos views "polluted" with a never-ending stream of cover art JPEGs. Sure, you can filter them out, but most people don't want to bother, and it needs to work right with the default views that MC provides. Their solution was to just not import the image files. I don't know if this was the right call. It is certainly the easiest solution. But now we have problems with MC not "tracking" the files well and moving them and deleting them with their "parent" files (same goes with the XML sidecar files, by the way, which aren't moved). Would their job be easier if they could just count on the files having some sort of database entry? Surely they are actually tracking these files in the database somehow (if nothing else as a field in the parent files' entries).

On the other hand, to do it the other way, import them all and filter them out of the Photos views, they'd probably need to change the default views. That's fine for new users, but every single current user of MC would need to modify their views to include the new filter. And, if they are imported files, then how will MC know that it is "okay" to move the file if the user decides to do a Rename, Move, and Copy on the file's parent? For all it knows, it is like any other imported image file. I'm sure, if they tried, they could figure a way around all of this, but I don't know if it is worth it... Clearly they decided no.

In any case, the "not importing" thing is easy to rectify. Auto-Import will import these files if you watch for the right media types in your Video folder. All of my Cover Art files are being imported.

rjm · « **Reply #88 on:** January 11, 2012, 12:43:31 am »

Thanks for explaining Glynor. I do not use TV episode artwork so have not experienced the problem this was intended to fix.

I'm ok with having to manually import and tag the artwork. Perhaps a solution is for MC to handle moves of both imported and unimported artwork. If it is imported then it should stay imported; if it is not-imported then it should stay not-imported after the move.

Another possible solution would be to import all artwork and assign a new Media Sub Type "Artwork". MC could then use Media Sub Type to filter out artwork from default views.

Whatever the chosen solution I would like to re-emphasize something that I think is really important and which makes MC uniquely powerful. A movie is not simply a video file. A movie can be a video file with a pdf press release, and an html critic's review, and an MP3 podcast interview with the Director, and a jpg poster, and an ebook that inspired the script. All in the same folder with the same tag values for Artist/Album/Name/Year/Genre and whatever custom field you choose to designate a movie.

Now that MC is creating artwork files and storing them with video files we need to be careful that we don't ruin the ability for movies (and any other class of media) to be composed of many media types.

glynor · « **Reply #89 on:** January 11, 2012, 02:50:57 pm »

Quote from: rjm on January 11, 2012, 12:43:31 am

Thanks for explaining Glynor. I do not use TV episode artwork so have not experienced the problem this was intended to fix.

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.

rjm · « **Reply #90 on:** January 11, 2012, 02:59:34 pm »

Ok, I better understand now. I never saw the problem because I never auto import from a common folder and I always tag and move the video to a unique location as soon as I manually import it.

Which of my proposed solutions, or other, do you favor to deal with imported artwork?

gappie · « **Reply #91 on:** January 12, 2012, 03:53:39 pm »

i just wanted to say that this change made me go back to 16 last weekend, and that was not easy at all... but, the fact that the covers are not showing anymore although they are there. quick find does not work, thumbs are not rebuild.. covers are stored on discs that when they are off, do not show up. pictures are added to my foto galeries. it is just to much crap, i really did try and i do know my way in this program.. i will check back in some months....

oh... and my coverart directory was still empty before i went back...

have a nice summer.

gab

rjm · « **Reply #92 on:** January 12, 2012, 04:22:38 pm »

I imported a few new movies today. We need a solution to the problems discussed above. My tried and true workflow no longer works. I cannot park new media in a WIP folder, then import, tag, and move it to the final destination because the imported artwork does not move.

gvanbrunt · « **Reply #93 on:** January 12, 2012, 05:36:39 pm »

Quote

have a nice summer.

Gah, curse you upside down people from the bottom of the planet. It's 30 below outside right now...

rjm · « **Reply #94 on:** January 12, 2012, 06:55:33 pm »

Just observed the same problem with subtitles.

I moved a video that had an imported srt subtitle file with the same file name. MC also moved the srt file however it is no longer imported at the new location and is now orphaned at the old location.

Another possible solution would be an option to turn off all automatic moving of sidecar artwork and subtitles. I'm ok with having to do everything manually but I can't live with MC breaking my library whenever I move video files.

park · « **Reply #95 on:** January 13, 2012, 08:48:45 am »

Quote from: gappie on January 12, 2012, 03:53:39 pm

i just wanted to say that this change made me go back to 16 last weekend, and that was not easy at all... but, the fact that the covers are not showing anymore although they are there. quick find does not work, thumbs are not rebuild.. covers are stored on discs that when they are off, do not show up. pictures are added to my foto galeries. it is just to much crap, i really did try and i do know my way in this program.. i will check back in some months....

oh... and my coverart directory was still empty before i went back...

have a nice summer.

gab

My solution is just to stop using MC for images. Ever since I moved to RAW photography I've needed something that worked better with xmp/DNG files anyway, and so the cascade of photo related issues made it easier for me to shift completely over to Lightroom for images.

I may still use MC for a small curated folder of jpeg images one day, when I get around to it, as it would be nice to play the occasional slideshow on TV.

Matt · « **Reply #96 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.

Anyone else, is there any problem remaining other than deciding if video cover art should be imported or excluded from an import?

We're looking at better handling sidecar art that happens to be imported during rename and delete.

JustinChase · « **Reply #97 on:** January 13, 2012, 11:16:19 am »

I still prefer to have individual episodic cover art stored in a "main" cover art folder, instead of next to the video files. If they were stored in a folder structure similar to the videos themselves, that would be fine with me also.

I really don't ever need/want to do anything with them, except perhaps updated them using the MC "get..." tools, which would allow MC to manage them for me in the background anyway.

The images in the same folders as the videos are just "clutter" to me. I know others prefer it this way, and I understand there are reasons for doing it this way, but you did ask

rjm · « **Reply #98 on:** January 13, 2012, 11:19:27 am »

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

We're looking at better handling sidecar art that happens to be imported during rename and delete.

Thank you. And subtitles please.

Matt · « **Reply #99 on:** January 13, 2012, 11:20:32 am »

Quote from: rjm on January 13, 2012, 11:19:27 am

Thank you. And subtitles please.

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

INTERACT FORUM

Author Topic: Cover Art (Read 27820 times)