INTERACT FORUM
More => Old Versions => Media Center 17 => Topic started by: Matt on December 15, 2011, 04:38:34 pm
-
Tonight's build introduces changes in the way cover art is handled, especially for video files.
I'll try to describe how things work, hopefully rolling the text into a wiki at some point.
Edit: It's now in the wiki, merged with the old cover art article.
Here's the link:
http://wiki.jriver.com/index.php/Cover_Art
It still needs a little cleanup, but at least it's written down somewhere.
-
I expect a coming build to nicely move and delete sidecar images for videos when doing those operations from inside Media Center.
Getting the rename tools to work nicely for DVD, Bluray, and other aggregate types would be extra credit. Whether this happens depends on how many Christmas cookies we give John tomorrow.
-
== How Images Are Stored ==
For audio, there are three ways that cover art can be stored:
In the cover art folder
Next to the file as Artist - Album.jpg
Next to the file as Folder.jpg
You can also store cover art in the file's tag, which is recommended.
Would it be possible to add an option to store cover art only in the file tag?
Currently I am adding a lot of singles cover art for compilation albums. For those albums I have a folder.jpg representing the compilation album as such in the folder containing the music files of the album and then embed singles cover art in each file in the album (with an additional dummy track # 0 file with the cover art for the compilation album embedded to get that displayed in album views, which works in standard views but not always in theatre view). As it is now I have to set the store cover art to a special location where the image file gets overwritten each time I embed singles cover art to a file in an album and then just delete all cover art in that folder to clean up. (This is not a big deal, but since you are looking at cover art handling...)
-
I expect a coming build to nicely move and delete sidecar images for videos when doing those operations from inside Media Center.
Sob. <dabs eyes> I'm so happy I could burst.
Now if only it had been able to do that a week ago when I moved a few hundred movies over to another drive... :)
Edit:
It would also be good if it could do this with subs...
-
Very cursory initial testing indicates this is working better, thanks :D
I did notice one thing that I don't understand yet. I just got data for Alias, for the first 3 shows of season 1, and the tooltips are showing the right image for all of them. Good. I deleted the existing Series art from the Cover art\Series folder, and grabbing individual episodes didn't get a Season image, not surprisingly. Okay, no problem, I r-clicked and got an image from the internet. I then went into TheaterView to see what I get for images there, and the main 'Shows' screen took about 5-8 seconds to load, appearing 'hung', then opened fine and showed the newly grabbed Series art for Alias. I clicked it and it shows the Seasons, but this seems weird still, showing the same image for 4 of 5 seasons, and one different image. (upload images is still not working so I can't quickly upload a screenie; and it locks me out of making further changes to my thread until I re-start a new reply).
After further testing, I replaced all episode thumbs on one season, and that season how shows one of the images from that season. The other season that was showing the different-than-the-rest image had not had any of the episodes run thru the old system, so after more looking, I guess it's not so weird after all.
I just have a couple hours of re-grabbing the art, and I think I'll be all fixed up.
Thanks for the quick fix Matt et al. As I said in another thread, I prefer a good fix quick to a long wait for a perfect fix. Great job.
Maybe someday the other options glynor presented can be added, but there's bigger fish to fry right now, so no worries :)
-
One minor problem I foresee is that our image views are going to fill up with cover art unless our import settings are carefully controlled. Did you investigate the possibility of directly embedding the artwork into mp4s and mkvs? Is it impossible to do without remuxing the files?
-
One minor problem I foresee is that our image views are going to fill up with cover art unless our import settings are carefully controlled. Did you investigate the possibility of directly embedding the artwork into mp4s and mkvs? Is it impossible to do without remuxing the files?
Good point. We need to make sure sidecar cover art doesn't get imported.
-
I just used the 'Rename, Move & Copy...' function to move a video, and it did not move the accompanying .jpg from the old location.
I moved it myself before I thought to try to use the new "clean cover art", so I didn't try that, whoops.
Still, MC should probably move the images also when we use MC to move files.
-
Good point. We need to make sure sidecar cover art doesn't get imported.
Or imported and hidden from most views.
-
Good point. We need to make sure sidecar cover art doesn't get imported.
I don't understand what the issue is here. If Auto-Import is configured to import only video files from the video directory, it's not going to import cover art, is it? Conversely, if I want to import cover art, configuring Auto-Import to do so should work. What is it, exactly, that needs to be prevented?
-
Or imported and hidden from most views.
I think this might be a better plan. If you could rely on the fact that all of the Cover Art MC is using will be in the database, then it would seem like you could more easily link the records behind the scenes, and use the file management tools you already have to handle problems like the Rename, Move, and Copy tool, file moves, and orphaned cover art deletion.
You just need a way to hide them from the users most of the time.
-
You just need a way to hide them from the users most of the time.
Tools > Options > File Location > Cover Art > Visible in Media Center views yes/no ??
-
You can clean up your cover art folder so that it uses the naming above by using Options > File Location > Cover Art > Clean cover art folder...
I just ran this. I had 4724 files in my P:\Cover art folder when it started.
I now have a new Videos subfolder with 130 files and an Albums subfolder with 1538 files. I assume that means it cleaned 3000ish cover art files I wasn't using, and didn't have an easy way to eliminate before.
Very nice!!
*It left 4 jpgs in the original Cover art folder, not sure why, but not a problem for me, just a curious thing really. The 3 albums do exist in the library, as does the one video file "DVDVideo - Elegy.jpg"; which is also shown as "Elegy.jpg" in the Videos subfolder.
Running it a second time took under a second, and did remove the 3 album covers, but still left the video cover.
-
im not totally understanding this.
4. Changed: Cover art assigned to video or data files is always stored next to the file
and:Inside the cover art folder, Media Center will attempt to use human readable naming. It will look like:
[Cover Art]\Albums\[Artist] - [Album].jpg
[Cover Art]\Series\[Series name].jpg
[Cover Art]\Artists\[Artist].jpg
[Cover Art]\Videos\[Name].jpg
[Cover Art]\Files\[File Key].jpg
so not always next to the file?
ps: did a cleanup of the coverart folder.. i stored in in a special folder, and in the files them selfs.. in the folder all my covers disappeared. there was a new folder called 'albums' though.. empty nonthe less.
:)
gab
-
ps: did a cleanup of the coverart folder.. i stored in in a special folder, and in the files them selfs.. in the folder all my covers disappeared. there was a new folder called 'albums' though.. empty nonthe less.
im not getting this change... a cleanup means removing all my album art from the external folder? i just did a coverart>save coverart to external location specified in options... and it copied a cover (just did 1 album) to the right place. then a cleanup removed him again... ?
-
im not totally understanding this.
and:
so not always next to the file?
Maybe I didn't explain that well. From the first post:
Sometimes a need arises to save cover art for a file that can not support artwork next to it. Imagine setting an image for a file on an optical disk. In these cases, the cover art is placed in the cover art folder.
-
im not getting this change... a cleanup means removing all my album art from the external folder? i just did a coverart>save coverart to external location specified in options... and it copied a cover (just did 1 album) to the right place. then a cleanup removed him again... ?
It removes cover art that is not referenced by the library. If the artwork is in your file tags, there's no real need to keep a second copy in the cover art folder.
-
ok :P. maybe it should be clear in the options then? and why is it called audio mode? it works for video apparently the same.
:)
gab
-
and why is it called audio mode? it works for video apparently the same.
At the top of this thread I describe how audio and video is stored. The option is only used for audio.
-
OMG, I was requesting a baby step (mainly to protect cover art from unintended deletion in the future), but now we got this. It is a brave step and I am sure that the end result will be good. Since these changes impact many things it seems obvious that the new system is not yet quite finished and bug free.
I have been busy with other things, but I tested the new build very briefly and already noticed a few oddities and bugs. I guess there is more to come. I can do more testing over the coming weekend and post a proper report.
For now, I wouldn't recommend releasing this cover art system publicly. If you would like to release a public build before the next week, it could be the build 54 or if you have promised some changes that are only in the build 55 or later, you could publicly release 56 with the old cover art system, and perhaps 57 with the new system for beta testing.
-
but I tested the new build very briefly and already noticed a few oddities and bugs.
Could you give a brief summary?
I'd like to iron out any issues today.
Thanks.
-
I've not been able to check out the new build yet. It's good that we now have a reliable system to separate the art from the media it self. I like that. Well done. Looking forward to checking it out.
I also hope the system will have some flexibility as to where this folders is placed. At least in the future. Editing sidecar files to point MC to the right location for art is not the best way. Editing sidecar files at all, to get correct metadata is not great.
-
I've not been able to check out the new build yet. It's good that we now have a reliable system to separate the art from the media it self.
Not for video files (yet?). The episode images sit next to the videos currently. Only Audio allows cover art to be put in another folder.
I also hope the system will have some flexibility as to where this folders is placed.
For Audio and Season cover art, this is currently possible, and works well in my testing so far.
-
At the top of this thread I describe how audio and video is stored. The option is only used for audio.
well then call me dumb.. how i read it...:
audio covers are stored as set in the coverart options: audio mode.
video covers are always stored next to the file.
except those that are for some reason stored in the coverart directory you set by setting the audio mode to : 'in specific folder'
and when set 'also store image in files tag', the only files stored in the option set in audio mode are the video covers, in a folder coverart/video.
?
and i know my english is not that good but. i tried to get a new cover for a movie and it stored in the specific folder and not next to the file. (while typing this after changing the audio mode settings it does seems to work).
btw... i think it is a bad idea to just remove the covers when the image is also in the file. reripping all or one file will make quick find in coverart directory useless. i scanned all my albumart and that folder was a backup at least.
and i really dont like the idea that i can not say where i store my video jpgs.. they were just fine where they are.. and im not sure where i need a coverart folder for then, it will end up empty except for empty folders that are named video and audio
-
i tried to get a new cover for a movie and it stored in the specific folder and not next to the file.
the Series artwork is considered cover art, and goes into that folder. the Episodic art that is obtained from the 'Get Movie & TV info...' is what sits next to the video files, and isn't optional
btw... i think it is a bad idea to just remove the covers when the image is also in the file. reripping all or one file will make quick find in coverart directory useless. i scanned all my albumart and that folder was a backup at least.
and i really dont like the idea that i can not say where i store my video jpgs..
I agree :)
I'm also curious if the same quality/resolution is retained by storing them in the files, or will people lose high quality scans with this tool, if they also keep them in the actual files?
-
Could you give a brief summary?
I'd like to iron out any issues today.
Thanks.
Here is a preliminary list that I wrote after my brief test. It is incomplete, unfinished and unsorted. I wrote the notes mainly for my future testing.
- The "automatic moving" sounds a bit dangerous. Does it happen immediately when just the path string is changed in the options? I'd like to be able to run the process at a preferred time.
(Did this already change in your above description? I can't find it anymore.)
- I also would like to keep my audio cover art in the album folders, but be able to store other cover art that cannot not go to the album folder in my preferred location (for instance the artist images).
- Regarding video cover art will the automatic renaming apply also to them. For example, I have a TV series that has one common cover art image and 22 video files in each "season" folder (5 different cover art images for five seasons). I would not like to duplicate the cover art file 22 times.
- Have you considered duplicate name handling? For example, "setting: album cover art in single folder" and more than one "(Multiple Artists) - Best Of" albums. The old system overwrote the duplicates.
- After importing a bunch of audio files to a new library and specifying a certain old cover art folder, the Quick Find tool does not work. Does it check only the non-existent "Albums" subfolder or is it totally broken?
- Will this system preserve cover art, if it is stored in the default location (still in appdata?) when the user "fully" uninstalls MC17 after installing a future version?
- Does this work correctly with a portable install?
-
the Series artwork is considered cover art, and goes into that folder. the Episodic art that is obtained from the 'Get Movie & TV info...' is what sits next to the video files, and isn't optional
i have not the faintest idea what series artwork is and how, and especialy why it should be different from episodic art ? i just want the cover from my movies, and at the place where i store them for ages.
;)
gab
-
Thanks Alex. That list looks like mostly clarification (which I'm happy to provide a little later), but you said we should hold release because there appear to be scary bugs. I'm particularly interested in what these might be, because I haven't seen them myself.
Thanks.
-
i have not the faintest idea what series artwork is and how, and especialy why it should be different from episodic art ? i just want the cover from my movies, and at the place where i store them for ages.
I understand. They are both for TV Shows. Series atrwork is the cover art for a TV Show, often taken from the DVD, and is shown in TheaterView when browsing "Shows". Episode art is a thumbnail from each individual TV show. It's downloaded when you use the new 'Get Movie & TV info' tool, and is always stored next to the individual shows.
Cover art for Movies is basically the same as Series artwork, but downloaded/scraped from different locatons/databases, but effectively the same. These covers are what gets put in the "Cover art" folder, which you can customize/change the location of.
-
...there appear to be scary bugs. I'm particularly interested in what these might be, because I haven't seen them myself.
I'm also curious if the same quality/resolution is retained by storing them in the files, or will people lose high quality scans with this tool, if they also keep them in the actual files?
Also, it is a pretty big change, and has barely been tested. I'm also not so sure turning this loose on the general public before the weekend is a great idea. It might lead to issues that thorough testing might otherwise prevent.
I "lost" 3000 covers when using it. I suspect this is fine/correct for what I intended it to do, but others might not agree.
-
I understand. They are both for TV Shows. Series atrwork is the cover art for a TV Show, often taken from the DVD, and is shown in TheaterView when browsing "Shows". Episode art is a thumbnail from each individual TV show. It's downloaded when you use the new 'Get Movie & TV info' tool, and is always stored next to the individual shows.
Cover art for Movies is basically the same as Series artwork, but downloaded/scraped from different locatons/databases, but effectively the same. These covers are what gets put in the "Cover art" folder, which you can customize/change the location of.
thank you...
well one of the several reasons i stored the covers in an external folder is that i have my movies on external disks.. they are off, except when i need them. when i look for a movie the popup also gave me the cover.. now i have to turn on all the external hd's to see those.. they are not part of the thumbs folder of mc.
-
Thanks Alex. That list looks like mostly clarification (which I'm happy to provide a little later), but you said we should hold release because there appear to be scary bugs. I'm particularly interested in what these might be, because I haven't seen them myself.
Automatic moving when just a new path is written in the box would have been scary. (Was this in your original description or where did I get it from?)
Consider a potential new user who has folder.jpg images and inconsistent file tags running the MC trial and experimenting with the cover art options.
Have you actually tested if this works correctly when an MC16 (or earlier) user is testing MC17, but does not want to make the move yet.
-
Not for video files (yet?). The episode images sit next to the videos currently. Only Audio allows cover art to be put in another folder.
Oh. Bummer. I hopes we could have everything in this directory.
Well... It's a great start at least. This Cover art folder will be able to contain any new Art files that MC introduces later on. Like season, banner and manual backdrops. That is good. I would however also be very happy if there is also a way of moving the episode screen shots to this cover folder.
Structure could be:
[Cover Art]\Series\Season\[Series name] - [Season]E[Episode].jpg
-
Consider a potential new user that has folder.jpg images and inconsistent file tags running the MC trial and experimenting with the cover art options.
guess they will feel WMP'd. i would.
and actually... i do, and im a user.
-
my wife, i just explained her, thought it was funny... a cover art folder where you can not store the coverart. i wonder how much wiki is needed to explain that.
i think you are trying to do two things at the same time. there is coverart and this other art, and both deserve their own setting.
-
my wife, i just explained her, thought it was funny... a cover art folder where you can not store the coverart. i wonder how much wiki is needed to explain that.
i think you are trying to do two things at the same time. there is coverart and this other art, and both deserve their own setting.
I suppose it could be intuitive if the user was allowed to add art in the Cover Art directory. The user would have to be very careful with the naming for MC to pick it up though. I doubt however, that MC does this in it's current state..
-
Next build:
Changed: Cleaning the cover art folder will only delete album images for artist / album values that aren't in the library (even if no files reference the artwork).
-
Automatic moving when just a new path is written in the box would have been scary. (Was this in your original description or where did I get it from?)
Consider a potential new user who has folder.jpg images and inconsistent file tags running the MC trial and experimenting with the cover art options.
Import would find their folder.jpg files and their inconsistent file tag images.
Auto-import might get some cover art for them, and this would be stored in the cover art folder (which by default is a private JRiver folder).
I don't think there's anything scary.
-
Next build:
Changed: Cleaning the cover art folder will only delete album images for artist / album values that aren't in the library (even if no files reference the artwork).
I take this to mean that "as long as the album is in the library, the corresponding cover art will be left alone, even if you're not 'using' it currently", which I think is a great change, thanks.
-
Good point. We need to make sure sidecar cover art doesn't get imported.
... unless preferred. I have imported and tagged my cover art files so that I can move them together with the other files. I have explained this 1001 times.
Actually, this reminds me about the most requested thing. The users want to move their unimported sidecar cover art files together with the imported media files.
Personally I have a lot of additional stuff in the file folders, other cover images (back, CD, booklet), documents (reviews, liner notes, rip logs), etc. I have imported them and I use a custom view for organizing them.
-
- The "automatic moving" sounds a bit dangerous. Does it happen immediately when just the path string is changed in the options? I'd like to be able to run the process at a preferred time.
(Did this already change in your above description? I can't find it anymore.)
Like I mentioned above, I'm not sure what you mean by this.
- I also would like to keep my audio cover art in the album folders, but be able to store other cover art that cannot not go to the album folder in my preferred location (for instance the artist images).
I believe you've always been able to do this, and that hasn't changed.
- Regarding video cover art will the automatic renaming apply also to them. For example, I have a TV series that has one common cover art image and 22 video files in each "season" folder (5 different cover art images for five seasons). I would not like to duplicate the cover art file 22 times.
You can pick any number of files and use Cover Art > Add From File... If you say "yes, copy the file to the spot in options", it should create a sidecar image for each video. This is required to support per-episode artwork.
- Have you considered duplicate name handling? For example, "setting: album cover art in single folder" and more than one "(Multiple Artists) - Best Of" albums. The old system overwrote the duplicates.
There are no changes here.
- After importing a bunch of audio files to a new library and specifying a certain old cover art folder, the Quick Find tool does not work. Does it check only the non-existent "Albums" subfolder or is it totally broken?
It only checks in the 'Albums' subfolder.
- Will this system preserve cover art, if it is stored in the default location (still in appdata?) when the user "fully" uninstalls MC17 after installing a future version?
There have been no changes to this. We might move to 'My Documents' as you suggested, but first we had to write a move tool (which is in the build).
-
... unless preferred. I have imported and tagged my cover art files so that I can move them together with the other files. I have explained this 1001 times.
I know. We won't do anything to limit you on this.
Actually, this reminds me about the most requested thing. The users want to move their unimported sidecar cover art files together with the imported media files.
Personally I have a lot of additional stuff in the file folders, other cover images (back, CD, booklet), documents (reviews, liner notes, rip logs), etc. I have imported them and I use a custom view for organizing them.
Sidecar images will move nicely in today's build. The "lots of additional stuff" will have to wait.
-
If I understand this (and I make no guarrantees), this is a great development that both streamlines and empowers (I copied that from one of JimH's press releases).
Like Alex, I want to import my cover- and artist-art, but like the others I don't want it cluttering up image views, unless I'm looking for cover art.
I wish I could test this out, but all my covert art is on my new computer, which is back revisiting the factory. For once the issue was not a misunderstanding with the finance company (after all, the first paymant hadn't even gone past due yet). Rather, due to a defect in the--wait for it--display.
-
Like Alex, I want to import my cover- and artist-art, but like the others I don't want it cluttering up image views, unless I'm looking for cover art.
Like any view, your Rules for file display will determine which files are included, and which are excluded.
-
Two names that do not work when the "Save Cover Art To External Location Specified In Options" tool is used for moving folder.jpg to the specified single folder.
Album Artist (auto): The Doors
Album: The Doors: 40th Anniversary Mixes
The expected filename: The Doors - The Doors_ 40th Anniversary Mixes.jpg
The resulting filename: The Doors - The Doors without a filename extension, the resulting file size is zero
The resulting Image File field value: ...\The Doors - The Doors: 40th Anniversary Mixes.jpg
Album Artist (auto): Yngwie Malmsteen
Album: 20th Century Masters - The Millennium Collection: The Best of Yngwie Malmsteen
The expected filename: Yngwie Malmsteen - 20th Century Masters - The Millennium Collection_ The Best of Yngwie Malmsteen.jpg
The resulting filename: Yngwie Malmsteen - 20th Century Masters - The Millennium Collection without a filename extension, the resulting file size is zero
The resulting Image File field value: ...\Yngwie Malmsteen - 20th Century Masters: The Millennium Collection.jpg
Edit: the expected yngwie was wrong ;)
-
Two names that do not work when the "Save Cover Art To External Location Specified In the Options" tool is used for moving folder.jpg to the specified single folder.
Album Artist (auto): The Doors
Album: The Doors: 40th Anniversary Mixes
The expected filename: The Doors - The Doors_ 40th Anniversary Mixes.jpg
The resulting name: The Doors - The Doors without a filename extension, the resulting file size is zero
The resulting Image File field value: ...\The Doors - The Doors: 40th Anniversary Mixes.jpg
Album Artist (auto): Yngwie Malmsteen
Album: 20th Century Masters - The Millennium Collection: The Best of Yngwie Malmsteen
The expected name: : Yngwie Malmsteen - 20th Century Masters_ The Millennium Collection.jpg
The resulting name: Yngwie Malmsteen - 20th Century Masters - The Millennium Collection without a filename extension, the resulting file size is zero
The resulting Image File field value: ...\Yngwie Malmsteen - 20th Century Masters: The Millennium Collection.jpg
Next build:
Fixed: The updated cover art system wasn't properly handling characters in the artist and album that weren't possible file system characters.
-
Import would find their folder.jpg files and their inconsistent file tag images.
Auto-import might get some cover art for them, and this would be stored in the cover art folder (which by default is a private JRiver folder).
I don't think there's anything scary.
I was afraid that changing the cover art path would trigger a library wide cover art move and delete all folder.jpg or other linked cover art files from the old locations. Apparently it moves only the files that are linked from the previous specified cover art folder. This is one of the things that I had not actually tested earlier.
Regarding inconsistent tagging, I meant inconsistent or missing Artist and Album tags (or untagged wave files with only the Name tag inside the library.) An accidental library wide move from folder.jpg to a single folder could have destroyed most of the user's cover art collection or at least made it unusable with other programs.
-
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 wish I could test this out, but all my covert art is on my new computer, which is back revisiting the factory. For once the issue was not a misunderstanding with the finance company (after all, the first paymant hadn't even gone past due yet). Rather, due to a defect in the--wait for it--display.
A long time ago, I sent a Sony VAIO back because it had problems with the front facing camera. It came back with a picture of the guy who had repaired it.
-
OMG, I was requesting a baby step ...
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!
-
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.
-
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.
-
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.
-
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.
-
This is gonna hurt.
(http://a6.sphotos.ak.fbcdn.net/hphotos-ak-snc3/30602_389861523035_161282948035_4141568_3892257_n.jpg)
-
Perhaps a more appropriate response would have been...
(http://i6.photobucket.com/albums/y217/kezler/facepalm2.jpg)
-
Funny guys.... :)
Yea. I see that he said that. I was mixing up some replays. Sorry.
-
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?
-
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
-
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.
-
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.
-
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?
-
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.
-
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!) (http://www.omniglot.com/language/phrases/christmas.htm)
-
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.
-
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?
-
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 :(
-
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.
-
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 :)
-
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?
-
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.
-
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. >:(
-
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.
-
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.
-
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 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.
-
Rename, Move and Copy is still failing on mkv files with coverart too :(
-
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.
-
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...
-
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.
-
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.
-
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.
-
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.
-
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...
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.
-
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.
-
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?
-
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?
-
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.
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.
-
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.
-
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.
-
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?
-
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
-
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.
-
have a nice summer.
Gah, curse you upside down people from the bottom of the planet. It's 30 below outside right now... :)
-
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.
-
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.
-
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.
-
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 :)
-
We're looking at better handling sidecar art that happens to be imported during rename and delete.
Thank you. And subtitles please.
-
Thank you. And subtitles please.
We will, but why are you importing sidecar subtitle files?
-
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.
-
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-
-
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.
-
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.
-
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.
-
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 :(
-
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.
-
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
-
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...
-
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.
-
In a coming build:
Fixed: Albums that ended with period characters would unnecessarily have their external cover art saved without the periods.
-
Is this problem solved now?
-
Is this problem solved now?
At least for artist images MC now retains a trailing dot as far as I can tell. Thanks!
-
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
-
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... :)
-
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
-
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.
-
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
-
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).
-
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..
-
+1 on having movie covers (and fanart?) in one central folder (same as series).
-
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.
-
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 (http://yabb.jriver.com/interact/index.php?topic=70168.msg473288#msg473288) of an issue with offline drives I'm aware of, it seems the covers are still being maintained in the separate folder.
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.
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.
-
Let's all have a beer together and enjoy the day.
-
Let's all have a beer together and enjoy the day.
Hear, hear! I'm buying.
-
Are you sure it's not beer that caused the problem in the first place? ;)
-
Are you sure it's not beer that caused the problem in the first place? ;)
that is true rick.. :)
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 (http://yabb.jriver.com/interact/index.php?topic=70168.msg473288#msg473288) 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.
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.. :)
Let's all have a beer together and enjoy the day.
Hear, hear! I'm buying.
:P guess it will be my place then.. the beer is fairly good in this part of the world
-
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
-
I suppose the offline drives thing is part of the bigger issue of how to handle HDD used as removable storage. Matt indicated here (http://yabb.jriver.com/interact/index.php?topic=69873.msg471380#msg471380) 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.
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. ;)
-
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...
-
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.
-
... 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?
-
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.
-
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.
-
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?
-
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..
-
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:
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, 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.
-
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.
-
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.
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...
-
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... ;D
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: 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
-
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.
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.
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.
-
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.
-
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.
-
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.
-
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.
-
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.
-
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...
-
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?
-
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...
The reason is that many users have a mixed environment, with users accessing file shares for playback as well. For series you would have at least 2 sidecar files for each episode. That is not great to work with. To simply hide these, many users would be satisfied. I show hidden files, and would have no problem editing it anyway... So I can only see positive things from this. It would stop a lot of noice on these forums I think. And in my experience, it should be pretty simple to implement as well.
-
to start with a part of one of the posts where i tried to explain ...
part II: the reason why i think its a big step back that video covers are not stored any more in the cover directory (as it was in mc 11 to 16 as an option)..
a: i take small videos with my foto camera. mc nicely takes them off the camera and puts them in a folder together with the images, at a place i have chosen. when i want to make a thumb for those small videos, 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 cover art folder, where they belonged.
and actually its worse .. mc has overwritten files that came from my camera, without warning,.. luckily i do have backups.. btw backup software would in this case have destroyed the original ones. 8 years of personal files well organized are not well organized anymore because there are images added or overwritten.
maybe i should tell a bit about the files that get overwritten... when i take a video with my camera (panasonic, also in the past) the camera adds a jpg with the same name as the video containing important meta data about the video, like when it was taken and with which camera, something i always found very elegant. the image belongs to the video. by doing a cleaning of the cover art folder or when i take a new screenshot, these images are overwritten.
-
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?
wow ... that's actually a key point i hadn't considered ... i keep my media in a nas (unraid), it doesnt need to spin up any drive other than the one that's accessed for playing content, but if metadata files are scattered across drives, all of them would need to be spinning :o
-
wow ... that's actually a key point i hadn't considered ... i keep my media in a nas (unraid), it doesnt need to spin up any drive other than the one that's accessed for playing content, but if metadata files are scattered across drives, all of them would need to be spinning :o
Once thumbnails are built, sidecars are only read if you play. And you can't play if the drive isn't spinning, so this has no impact on whether drives spin.
-
Once thumbnails are built, sidecars are only read if you play. And you can't play if the drive isn't spinning, so this has no impact on whether drives spin.
Just to be sure I got you: Once I've imported my new videos and powered off my external HD I still can browse through these movies and see my cover art in MC17?
-
Also just one thing I noticed with some experimenting: the cover art in a ripped DVD folder is always called "VIDEO_TS.jpg". Maybe it should be renamed to the name of the folder one level up.
-
Just to be sure I got you: Once I've imported my new videos and powered off my external HD I still can browse through these movies and see my cover art in MC17?
You can browse Media Center with all your media drives disconnected.
If a drive is attached but spun down, browsing will likely spin up the drive. This is because the program checks to see if files exist when they're shown so it can display a red x.
-
And the red x will replace the cover art, yes? At least if the disk is actualy offline. Not just spun down.
This is touching the offline discussion we had a while ago? It's connected.... Everything is connected! My head hurt.
-
And the red x will replace the cover art, yes? At least if the disk is actualy offline. Not just spun down.
The red x is an overlay on the file. It's not related to cover art.
This is touching the offline discussion we had a while ago?
Yes it is. Miles to go before we sleep.
-
The red x is an overlay on the file. It's not related to cover art.
I did not mean the cover art, but rather the thumbnail. But, yea. Ok. As long as the thumbnail is not replaced by the x, it's still browsable I presume. I've never had problems with this my self, except for the few times I had a share connection problem, and saw all the red X's in normal view.
-
edit: maybe i should tell a bit about the files that get overwritten... when i take a video with my camera (panasonic, also in the past) the camera adds an jpg with the same name as the video containing important meta data about the video, like when it was taken and with which camera, something i always found very elegant. the image belongs to the video. by doing a cleaning of the coverart folder or when i take a new screenshot, these images are overwritten.
I'm not sure exactly how the cleaning function works, but I assume its purpose is to clean-up the cover art folders so they would include only the images not maintained beside the media under the new system. If that had been done at the time of the change, and covers were previously saved in the separate folder, then there would be nothing to overwrite. I'm not sure if the function has any purpose beyond that one-time use. If it does, however, then there would be no images in the video folder that could overwrite covers saved beside the media.
Why would you Use Screen Grab for Thumbnail when you know that's going to overwrite an existing cover you want to keep? There is a Screen Grab to File... command for saving the image with a different file name. If you do this often, it would probably be easier to routinely copy the camera images to a different filename (e.g., {video filename} [camera data].jpg) so they're preserved.
-
sure rick, if you want an explanation about this function please start a new thread.
-
sure rick, if you want an explanation about this function please start a new thread.
No thanks. I'm quite sure my understanding of the function is sufficient to support my comment. Neither of the things you mention have any bearing on whether the cover art system needs to be changed or improved. If you want further advice on how to use these functions correctly, please start a new thread.
-
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.
im not sure if this is possible, but some check to prevent mc to overwrite a file that is not made by mc with cover art.
:)
gab
(actually in my case, the files from the panasonic camera, something that would save the tags from those files in the new ones would do it)
-
i actually just had a very stupid idea... why not save the files in there own format.. mcjpg. something like that. its coverart for in mc only..
:)
gab
-
Hello Gappie,
That would work for you maybe but not for me and a lot of other users/customers I'm afraid. If I would want to use them in another program I would first have to copy them and then somehow have to rename them to their normal jpg extension.
I think a tool for getting them into a certain folder would do it for (almost ;D) everybody.
@ Matt: have you thoughts about my question about the way every image is called VIDEO_TS.jpg? I'm asking because I want to switch to your way of handling cover art soon and if things will be changed I'll wait for that. If not I'll be replacing my cover art into each movie's folder.
(counting on the fact their will be a tool someday).
-
@ Matt: have you thoughts about my question about the way every image is called VIDEO_TS.jpg?
All sidecars follow the name of the video.
DVD rips use VIDEO_TS.* for the video files.
This has never bothered me, but I suppose you could remux your DVD files to MKV if you wanted the video files to have better names.
-
Remux more than 2000 DVD's? No thanks! :o
I was asking because of the future tool to save them into a folder. In that case they have to be renamed anyway. It would be cruel to find out that newer versions of MC17 will be renaming them after I changed everything to VIDEO_TS... ;D
So I guess I can make a start then.