INTERACT FORUM
More => Old Versions => JRiver Media Center 19 for Windows => Topic started by: JustinChase on December 13, 2011, 06:55:04 pm
-
using the latest .53 build, the problem of covers being shown for all episodes has gotten worse. It used to be that if I used this system to get the episode information, it would use the most recently 'gotten' cover for the cover for all episodes in a series/season that had been updated with this system. i.e. if I used this tool on all episodes for a season, the most recent one would be the cover shown for all episodes in the mouse-over tool tip, but each episode would show it's own thumbnail in the thumbnail view.
Today, all episodes show the same thumbnail, as does the tool tip.
I know this is a work in progress, and batch updating is on hold, based on the thread in the main board, but this issue is one I hope can be fixed before then, since it's now pretty annoying :(
You can see in the screenshot below, all but one episode has the same cover art (except one I obviously forgot to update), until I get to season 3, when I stopped doing them one at a time.
(http://www.pix01.com/gallery/B6318F5F-4769-4385-B3CA-EE27B9BD15F9/covers/356050339_orig0.jpg)
-
There is something strange going on alright. Yesterday I found 3 episodes with custom thumbnails, which did not update with the external cover it was assigned through the sidecar file. I checked the paths, and they were 100% correct. Instead they also used the same cover art, if I don't remember wrong.
I have a feeling that a better art management system would yet again prove useful. One place to set the thumbnails paths, and better control for users and programmers hopefully. The more images, the more likely we are to encounter problems like this I think.
-
I've been seeing some weirdness like this too, though my problems have actually seemed to decrease recently. I have no freaking clue as to why that might have happened...
-
I have no freaking clue as to why that might have happened...
It likes you better ;D
-
It likes you better ;D
Perhaps.
I also did a big reorganization of my media files, and they are much more rationally stored (my SageTV recordings folder is essentially empty now). I think some of this has to do with how you store the files, because it relates to the file naming scheme for the thumbnail JPEG files that are stored on disk.
If you have a bunch of files in one big "junk" directory, it seems to make the problem worse.
I should add, though, that I'm not seeing it (maybe as much, I haven't carefully tested) with new files that I tag with the Get Movie & TV Info tool. I do still have examples like your screenshot in my library, but they are mainly older files that may have been "touched" by one of the bad-old-versions of MC.
I can try to take a look at this in more detail this weekend.
-
I think some of this has to do with how you store the files, because it relates to the file naming scheme for the thumbnail JPEG files that are stored on disk.
If you have a bunch of files in one big "junk" directory, it seems to make the problem worse.
I'm not so sure. I have my TV shows filed like so...
V:\TV\Archive\[Series]\Season [Season]\[Series] - s[Season]e[Episode] - [Name]
Which I would think would keep seasons artwork separate, and it used to kind of work. Meaning that the art used in the tooltips was copied/duplicated/shown for all episodes in a season, but was different for each season; with each season using the most recently obtained art. This also used to show the obtained thumbnail for each episode properly in that view, only the tooltip art was "duplicated" over the episodes, per season.
Since upgrading to .53, all those individual thumbnails were all 'replaced' by the most recently obtained art for the series, regardless of season. All 5 seasons worth of shows of The Big Bang Theory now show the thumbnail for the most recent episode.
In TheaterView, the season images have all shown the most recently obtained art for the series since this tool was first used.
Last night I used 'Get Movie and TV Info' again on a few of those files, and it grabbed the thumbnails again, and has so far left them alone, meaning they still show the correct thumbs in that view, but I only did a few, since I don't want to manually do them all again, especially until I hear that this has been addressed, and that I should test.
-
Since upgrading to .53, all those individual thumbnails were all 'replaced' by the most recently obtained art for the series, regardless of season. All 5 seasons worth of shows of The Big Bang Theory now show the thumbnail for the most recent episode.
This isn't happening to me, as far as I can tell.
I do get different artwork for each episode now. Before I did not, and it worked like you described: Every episode physically stored in the same directory would "get" the thumbnail of whatever episode was tagged most recently.
I figured out why... I've been doing my Get Movie & TV Info commands largely from the HTPC lately, which is a Client copy of MC. It updates the info for the show, but doesn't change the thumbnails. The thumbnails I'm getting are the auto-generated ones, and they DO correctly store/display a separate thumb for each file. So, ignore that.
I just tested it out fairly extensively. This is exactly what I'm seeing:
1. I have Options -> File Location -> Cover Art set to In the same folder as the file (also store in tags is checked).
2. When I import files that have no cover art sidecar (or anything) of their own, MC auto-generates thumbnails and stores different thumbs for each file. However, they are not "physical thumbnail files" and are (presumably) only stored in MC's Thumbnail Cache folder.
3. The [Image File] tag for these files is blank.
4. After I make sure a new file is properly tagged as necessary (either manually or from Carnac), I do Get Movie & TV Info on the file.
Then... If I do #4 on the Server:
5a. A new JPEG file is created in the same folder as the file itself, titled using the format: TV Program - [Series].jpg and the file's [Image File] field is filled with this JPEG's filename. If that JPEG file already exists in the destination directory, it is overwritten.
6a. This image is then used as that file's thumbnail.
7a. If I have a bunch of files from the same [Series] in that same folder on disk, they all point to the same file, so they all get the same thumbnail. However, files in other folders, that have the same [Series] tag, don't get messed up, nor to ones that have a blank [Image File] field.
If, instead, I do #4 on a MC Client:
5b. No new JPEG is created, and the [Image File] field is left blank. All other metadata from the lookup is filled properly.
6b. The files keep their individual thumbnails.
7b. They DON'T use the image file from thetvdb.com, even if I leave that box checked in the Get Movie & TV Info dialog box.
So, in conclusion: I also use a [Series]\[Season]\filename type of folder structure for my files. If I do the metadata lookup on the Server copy of MC, this ends up meaning that all files from a particular season have the same thumbnail as whatever one I "looked up" most recently. Each "season's" folder gets its own copy of the (for example): TV Program - The Big Bang Theory.jpg file.
If I haven't organized the files into their assigned folder structure yet, and they are all just in my T:\recordings\ folder, then any file with a matching [Series] tag gets the same thumbnail (because there is only one TV Program - [Series].jpg file in the folder).
I tested, and I am NOT able to reproduce any issue where getting metadata for a file in one folder affects the thumbnail image for a file in a separate folder. The issue, on my end, appears to be limited to the poorly-named TV Program - [Series] file. The solution, obviously, is that each individual file needs to be able to have their own thumbnail sidecar file, rather than one per [Series] per folder.
HOWEVER... If you change Options -> File Location -> Cover Art to In a Specified Folder, then it will behave as Justin explained above. That's because in that case, there is only one TV Program - [Series].jpg file (continually overwritten) stored in whatever folder you specify for your cover art. In that case, that one cover art file will apply to ANY FILE tagged with a particular [Series] tag, and that has a non-blank [Image File] tag, because there is only possible file MC could have created for that entire Series.
-
Thanks for all the testing, and confirmation :)
HOWEVER... If you change Options -> File Location -> Cover Art to In a Specified Folder, then it will behave as Justin explained above.
I will just add that I currently have the Options -> File Location -> Cover Art set to P:\Cover Art, which confirms your assessment.
I'm not sure what change in v.53 caused the thumbnails to not remain individual, as that worked on v.52.
I can also state that about 2 weeks ago (give or take) I turned off sidecar files, as I became aware that they aren't 'necessary', as I thought they were. Perhaps this is also part of it.
Finally, I'll add that I have the library stored on the unRAID server, and I'm connecting to it from the Desktop directly, not as a client connecting to a library server. I do this mainly so that I can adjust viewschemes and playlists and such and have them stick, since they don't if connected as a client.
TV Images were discussed in another thread, and I made some suggestions as to how I would like to see this handled, and maybe it helps resolve this issue now also, so I'll quote request from there...
I'd prefer if all the Season specific images went into an 'images' or 'metadata' folder, under each Season, instead of them all sitting next to the video files; and the Series specific images in a similar folder under Series; which in my case would be just one more folder next to the Season xx folders. Also...
- Episode Image in a Thumbnail folder => [Episode Name].jpg (I actually don't mind the screengrab for each episode, but "official" images might be nice also)
- Backdrop under Backdrop folder => backdrop.jpg for each Series (not another folder for this one item)
- Artist images under Artist folder as artist.jpg => I'm not sure what "Artist" it would pull for TV shows, so I don't think I'd actually want anything here actually, but perhaps I'm missing the point of this one. (maybe you mean this to be just for music?)
Like this...
V:\TV\Archive\The Big Bang Theory
\Season 01
\The Big Bang Theory - s01e01 - Pilot.mkv
\The Big Bang Theory - s01e02 - The Big Bran Hypothesis.mkv
\The Big Bang Theory - s01e03 - The Fuzzy Boots Corollary.mkv
\metadata
\The Big Bang Theory - s01.jpg
\The Big Bang Theory - s01e01 - Pilot.jpg
\The Big Bang Theory - s01e01 - Pilot_mkv_JRSidecar.xml (if useful)
\The Big Bang Theory - s01e02 - The Big Bran Hypothesis.jpg
\The Big Bang Theory - s01e02 - The Big Bran Hypothesis_mkv_JRSidecar.xml (if useful)
\Season 02
\Season 03
\metadata (I could live without this folder also, if you'd prefer the images just sit next to the season folders)
\series.jpg
\backdrop.jpg
\banner.jpg
\series.xml (if useful)
This would keep only the actual videos together in one folder, and stick all the associated metadata files together in a separate folder; which is 'cleaner' when browsing outside of MC.
-
For the record, I'd much rather them just be stored as sidecar files, right next to the files they correspond with.
So, this structure instead:
M:\Video\TV Show\The Big Bang Theory\05\s05e01 - The Skank Reflex Analysis.ts
M:\Video\TV Show\The Big Bang Theory\05\s05e01 - The Skank Reflex Analysis.jpg
M:\Video\TV Show\The Big Bang Theory\05\s05e01 - The Skank Reflex Analysis_ts-JRSidecar.xml
etc
Using subdirectories can become quite complex, and make file moving operations flaky, for absolutely no benefit in my estimation.
-
I wonder if the issues I reported in http://yabb.jriver.com/interact/index.php?topic=68426.0 are related to all this behavior....
brad
-
This is sort of a deep topic.
Episode artwork stored in the 'Cover Art' folder just isn't supported nicely. All episodes will point to the same file and you'll have trouble.
I'm thinking only supporting sidecar artwork for videos (so no Cover Art folder usage) might be the best solution.
Please speak up (soon) if you disagree.
-
For the record, I'd much rather them just be stored as sidecar files, right next to the files they correspond with.
Using subdirectories can become quite complex, and make file moving operations flaky, for absolutely no benefit in my estimation.
I can understand and appreciate that, but I respectfully disagree :) I'd prefer to have just the media files in a folder, so when I'm navigating outside of MC, I don't have to scroll 3 times as far to see all the media, due to the extra files. However, any solution that resolves this issue is really fine with me, I'm not too adamant about my suggested structure :)
Perhaps the existing option to 'keep sidecar files next to media' could switch between the 2 solutions? If not, no big deal.
-
Episode artwork stored in the 'Cover Art' folder just isn't supported nicely. All episodes will point to the same file and you'll have trouble.
I'm thinking only supporting sidecar artwork for videos (so no Cover Art folder usage) might be the best solution.
Could you elaborate? I'm not sure if I know what you're thinking.
-
Could you elaborate? I'm not sure if I know what you're thinking.
When cover art is stored in the Cover Art folder, we build a name. For television, this has been:
Template: TV Program - [Series Name].jpg
Example: TV Program - The Big Bang.jpg
With that naming profile, all episodes in the series share their image.
We were considering switching to something like:
Template: Shows\[Series Name] S[Season]E[Episode].jpg
Example: Shows\The Big Bang S02E11.jpg
But this is still a problem for a file with sparse metadata since it's hard to make sure the filename is unique.
If instead artwork is only saved next to the file for videos, this problem goes away.
-
The reason I had them going into cover art (along with all my music cover art) was to keep images in the same mapped drive, with the rest of my photos. Not necessary, but before this, it didn't cause any issues.
My reason for wanting them NOT just sitting next the files is really just for cleanliness/ease of finding the actual media files in folders outside of MC (windows explorer mainly).
If everyone prefers to have all these extra files sitting next to their media, I can live with that. I still prefer my separate folder suggestion above :)
It originated from this thread, which you can see begins with disagreement in preferences :P
http://yabb.jriver.com/interact/index.php?topic=67845.0
-
If instead artwork is only saved next to the file for videos, this problem goes away.
This is absolutely my vote, perhaps with an option to store them all in a "metadata" subdirectory like Justin was asking for...
It just makes it easier to track, move, and deal with the files on disk.
-
My reason for wanting them NOT just sitting next the files is really just for cleanliness/ease of finding the actual media files in folders outside of MC (windows explorer mainly).
Stop using Windows Explorer to look at your media files. Problem solved. ;) ;D ;D ;D
I'm kidding, of course, but a bit serious... MC can Locate the files on disk for you if you need to, and you can sort Windows Explorer by Type to hide them if you want, so I don't see it as a huge deal, and it makes EVERYTHING so much simpler.
But, I also wouldn't freak out if they put them in a subfolder. I just don't think it is necessary, and it could lead to trouble. There is a maximum path depth in Windows, for example, so you could hit a point where you actually can't add that folder because it would result in an invalid file name.
-
Stop using Windows Explorer to look at your media files. Problem solved. ;) ;D ;D ;D
It took longer than I thought to elicit that response :)
I do it often after I've ripped, or moved, or changed a file, and just want to check to be sure it's where I expect. MC is often not running at the time, so it's explorer isn't an option, and even if it were, it would show all the files also, so not much better really. I can filter out the other stuff, but just not having to deal with it is often easier/faster.
However, I think we agree, either way which 'fixes' the issue is a good way ;)
-
I've had 7 beers, so I might be a bit more slow than usual. But I still have a problem understanding the problem here.
When a series image is stored it should be used for all files in that series. There should be no need for episode and season in those names. But episodes needs it's own unique image as well of course. I don't know how this is programmed, and I don't really care. The results is what is important.
As I've mentioned before, the only thing I'm concerned about is that the increases in types of images only will increase the complexity unless something is done to standardize this. Some art in app data, some in cover art folder, and some art next to the media is not a great solution. It's confusing, and it can lead to problems. I'm sure this is something you're thinking of with this response, but I'm probably just to tired to see it. If what you are talking about is only dependent on Cover Art folder option, then I have little to add. I've never used it.
Ultimately I think it's important, and rather a must, to enable the users to specify each location of each of the image types available. This because of ease of use for users, as well as integration possibilities with other applications.
Each image type should be be able to be saved in a specific directory with Library fields enabled in paths, for less static directory structures. As well as a JRiver standard position and name. Pretty much like Cover Art options today.
One Example:
TV Show Series Art
- In the same folder as the series (as "TV Show.jpg")
- In a Spesific folder (D:\Art\TV Show\[TV Show])
TV Show Episode Art
- In the same folder as the episode (as "folder.jpg")
- In a Spesific folder (D:\Art\TV Show\Season [Season]\[TV Show] - S[Season]E[Episode])
Movie Cover
- In the same folder as the movie (as "folder.jpg")
- In a Spesific folder (D:\Art\Movie\[Movie] - Cover.jpg)
Movie Banner
- In the same folder as the movie (as "banner.jpg")
- In a Spesific folder (D:\Art\Movie\[Movie] - Banner.jpg)
And so on. Paths would be fully customizable, and you could use what ever library field to populate the correct path.
That's at least what I would like. Then I could put all those covers in season or series specific directories, and clean up my media folders. It would also be much more friendly for backup and maintenance when you decide how the structure is built your self. I support a good default way of storing the art, but this might be a good option for a more "final" solution.
Stop using Windows Explorer to look at your media files. Problem solved. ;) ;D ;D ;D
This is not an option for some people. I'm sharing much of my media, and everyone is NOT using MC. I don't see any reason why the users could not configure this how each and one of them like.
-
My reason for wanting them NOT just sitting next the files is really just for cleanliness/ease of finding the actual media files in folders outside of MC (windows explorer mainly).
This may be a legitimate preference, but not as logical as what most would expect. In a folder structure organizing media by type, ending, for example in \Season [Season]\, all files pertaining to a particular season of a series belong in that folder. There's nothing wrong with then adding further folders for different file types, but it's inconsistent with the preceding structure. More importantly, like applications, most users will prefer to see media files along with whatever files are saved "beside" them. That, in fact, is the very purpose of saving them that way. If I'm looking in such a folder, it may very well be to check the existence or something about a file's sidecars. That's difficult to do if they're hidden in a sub-folder. Also, for those who really care about such things, a real file manager like Directory Opus allows folders to be flattened and/or file types to be restricted (so either way works).
Ultimately I think it's important, and rather a must, to enable the users to specify each location of each of the image types available. This because of ease of use for users, as well as integration possibilities with other applications.
Why? Can you provide an example of another application that is unable to find cover art when saved beside the media file it pertains to? Not only is this simple and foolproof, it doesn't matter what sort of folder structure the media files happen to be in. The media file name is always unique, so the image file name will always be unique. At the same time, there's no difficulty saving a more general image (like a series cover) in the same folder when it's given an appropriate name by the application that puts it there.
My episode files have always been in a Video\Series\[Series]\ structure, and I've never had any problem with MC, Personal Video Database, Sick Beard (and from time to time, other applications) using that. It would make no difference if I added a [Season] folder. Depending on how it works, MC might save a series poster in every [Season] folder instead of just one in a [Series] folder, but that doesn't matter.
-
I've had 7 beers, so
Jealous.
This is not an option for some people. I'm sharing much of my media, and everyone is NOT using MC. I don't see any reason why the users could not configure this how each and one of them like.
I really was kidding.
By the way, we were basically only talking about thumbnails for individual episodes here. I don't think MC supports "series art" in any serious way, currently, but I might have missed it.
If you look at Justin's screenshot above, that's how most of my (older) TV Shows look right now. Every season has identical thumbnails for every episode. I download new ones with a built-in function of MC, and it assigns that new thumbnail not just to the episode I'm tagging, but to all of them in the same folder.
It is broken.
Why? Can you provide an example of another application that is unable to find cover art when saved beside the media file it pertains to? Not only is this simple and foolproof, it doesn't matter what sort of folder structure the media files happen to be in. The media file name is always unique, so the image file name will always be unique. At the same time, there's no difficulty saving a more general image (like a series cover) in the same folder when it's given an appropriate name by the application that puts it there.
This is really what it comes down to, for me... Simple and foolproof.
I'm sure there might be some weird edge-cases where this actually could cause problems, but I sure can't think of any. I suspect, if he's honest, the real reason that Justin wants to save them in a subdirectory has little to do with function, and is mostly about aesthetics. That the listing in Windows Explorer looks ugly to him with those extra XML and JPG files sitting next to his neat, orderly, media files.
That's not to say that there isn't a place for form over function, or that aesthetics aren't important at all (as you might know, I'm typing this on an Apple keyboard right now). I just don't think that Windows Explorer is a place where we really need to care that much, considering the downsides. I mean, is the filesystem really ever aesthetically pleasing?
But, again, I'm really not that picky. It just "makes sense" to me, because of exactly what Rick just said, to just save them as sidecar files. It makes it easier for other applications to use them, not more difficult in most cases, and it solves a bunch of potential problems with file paths and filename uniqueness, and all of that. And, from what Matt said, it would probably be the lowest-friction way to solve the problem.
I'd say we all agree and we're all pretty flexible around the "fiddly bits" at the edges... So, Matt? Do what you think is best.
-
I don't think MC supports "series art" in any serious way, currently, but I might have missed it.
Sure it does.
Pick some television and do Cover Art > Get From Internet.
Or let auto-import get it automatically.
Then browse series or seasons in Theater View (or Standard View) and see the pretty pictures.
-
Sure it does.
Pick some television and do Cover Art > Get From Internet.
Or let auto-import get it automatically.
Then browse series or seasons in Theater View (or Standard View) and see the pretty pictures.
Wow. I must have missed it. Trying now.
EDIT: I'm not seeing any effect. Do I just pick one file from a particular series and do it? Or do I have to select them all and do it at once to see a change? Where should I see this cover art displayed in Standard/Theater View?
EDIT AGAIN: I've always had Auto-Import set to get Cover Art automatically, actually... In fact, when I just tried a particular episode of Boardwalk Empire, the picture it found at the top of the list was listed as "Your File".
I've never seen this cover art displayed anywhere in the MC UI. Do you have to have a View configured in a particular way to see it show up?
-
I've never seen this cover art displayed anywhere in the MC UI. Do you have to have a View configured in a particular way to see it show up?
They're used in Series category views when using thumbnails.
The default Theater View > Video > Series view, for example.
-
When cover art is stored in the Cover Art folder, we build a name. For television, this has been:
Template: TV Program - [Series Name].jpg
With that naming profile, all episodes in the series share their image.
This is what's causing my problems in TheaterView, but until recently, it didn't seem to affect the episode thumbnails, not sure what may have changed?
In a folder structure organizing media by type, ending, for example in \Season [Season]\, all files pertaining to a particular season of a series belong in that folder.
Yes, but if a user doesn't use folder structure, you can get a mess; as the current P:\Cover Art\[Series].jpg has shown. I use a folder structure, and suggest everyone should (for videos), but not everyone will/wants to. Or if they only have \[Series]\files, with no season folder, there's no good way to have a season specific jpg, so this problem remains.
Why? Can you provide an example of another application that is unable to find cover art when saved beside the media file it pertains to? Not only is this simple and foolproof, it doesn't matter what sort of folder structure the media files happen to be in. The media file name is always unique, so the image file name will always be unique. At the same time, there's no difficulty saving a more general image (like a series cover) in the same folder when it's given an appropriate name by the application that puts it there.
I'm not sure anything is foolproof, you give fools too little credit ;) Seriously though, this decision should not be based on what other programs are able to use/recognize/take advantage of. If XMBC or WMC or whatever can't use what MC creates, I don't see that as a 'deal breaker', or really even much to be considered. However, if it can be used by more programs, that's obviously better. Also, Sickbeard, for example, wants to create separate folders for the metadata, so that could easily be leveraged in MC, but again, not to be weighted too heavily IMO. As Matt mentioned also, if the metadata is sparse, the ability to give a unique name may disappear, causing a similar problem as to what we have today.
This is really what it comes down to, for me... Simple and foolproof.
Easier said than done :P
I suspect, if he's honest, the real reason that Justin wants to save them in a subdirectory has little to do with function, and is mostly about aesthetics. That the listing in Windows Explorer looks ugly to him with those extra XML and JPG files sitting next to his neat, orderly, media files.
I actually don't much care how windows explorer looks, honestly. In fact, I'm generally all for LESS folders to deal with/navigate thru.
In this case, however, I don't like the fact that in certain views (detail) in Explorer, it's not easy to differentiate between
M:\Video\TV Show\The Big Bang Theory\05\s05e01 - The Skank Reflex Analysis.mkv
M:\Video\TV Show\The Big Bang Theory\05\s05e01 - The Skank Reflex Analysis.jpg
M:\Video\TV Show\The Big Bang Theory\05\s05e01 - The Skank Reflex Analysis.xml
It's too easy to accidentally click/open the jpg when I really wanted to click/open the mkv
I also hate that in a folder with 22 episodes, I HAVE to scroll in Explorer to get to the end of the list, because there's 3 times as many files as episodes. This is even worse in a thumbnail view, since I have to scroll more, and mkv files don't have thumbnails to help you differentiate between file types.
This very much feels like a "pick your poison" discussion to me. i.e. which issues are likely to bother you the least?
I'd say we all agree and we're all pretty flexible around the "fiddly bits" at the edges...
Agreed.
Sure it does.
Pick some television and do Cover Art > Get From Internet.
I didn't know this was possible, nice.
Anyway, I'm not dead set on "my way", and will be happy with any solution that basically works, I just think it's better to see multiple 'arguments' from all sides before making a decision that isn't likely to be modified in the near future.
Would it make sense to rehash the thread I linked to in the main forums to solicit some more input?
With that said, I would prefer a solution sooner than later :) :)
-
A "half way" solution would be to have MC manage the cover art (ie one folder location) or to store with media. If MC manages things i would suggest using a guid or other unique ID for a file name. I don't see why it should be user readable when dumped all in one directory anyway. Or I'm sure MC stores a unique ID for each piece of media. Why not use that when storing to one directory?
-
Yes, but if a user doesn't use folder structure, you can get a mess; as the current P:\Cover Art\[Series].jpg has shown. I use a folder structure, and suggest everyone should (for videos), but not everyone will/wants to. Or if they only have \[Series]\files, with no season folder, there's no good way to have a season specific jpg, so this problem remains.
I was explaining why saving images beside media should work fine and should be the only option. Is there any good reason to save cover art in a separate common folder? I also pointed out things like series and season cover art is fine saved in any folder—as long as it's appropriately named. [Series].jpg for a series cover, and [Series] [Season].jpg for a season-specific cover (although there's presently no way to use them).
Also, Sickbeard, for example, wants to create separate folders for the metadata, so that could easily be leveraged in MC, but again, not to be weighted too heavily IMO.
True, and I shouldn't have implied there would be no need to recognize files in subfolders. In my set up, MC is using images written beside the media files by PvdImport, and those placed in subfolders by Sick Beard are not used. But I think this suggests a possible need for MC to look also in subfolders for data, not a structure that should be used by MC. Also, let's not forget we're moving towards and integrated system that won't need these third party applications. Not that they shouldn't be supported, but a sensible practice by MC should be the main concern.
-
Yes, but if a user doesn't use folder structure, you can get a mess; as the current P:\Cover Art\[Series].jpg has shown. I use a folder structure, and suggest everyone should (for videos), but not everyone will/wants to. Or if they only have \[Series]\files, with no season folder, there's no good way to have a season specific jpg, so this problem remains.
What? I'm confused...
If the filename of the thumbnail JPEG file always matches the filename of the relevant media file, then it would work, even if the user has literally all of their video dumped into one big holding folder with no subdirectories of any kind. That's my point.
The media filenames (the MKV, TS, MP4, etc) in a particular folder already have to be unique. Otherwise one overwrites the other or becomes a (2) file.
And, it could conceivably work if the user selects a cover art directory too... MC would just have to replicate the full directory structure in the cover art path. That would be uglier, of course, and could hit path-length restrictions.
That doesn't go into the rest of it (for which I think there's no point), but I just wanted to address that part.
-
In this case, however, I don't like the fact that in certain views (detail) in Explorer, it's not easy to differentiate between
M:\Video\TV Show\The Big Bang Theory\05\s05e01 - The Skank Reflex Analysis.mkv
M:\Video\TV Show\The Big Bang Theory\05\s05e01 - The Skank Reflex Analysis.jpg
M:\Video\TV Show\The Big Bang Theory\05\s05e01 - The Skank Reflex Analysis.xml
It's too easy to accidentally click/open the jpg when I really wanted to click/open the mkv
Tip: you're using Details view... so add the details you need to help you differentiate, such as columns for Type, Kind, Dimensions. Move Kind and Dimensions left of Name - you won't have trouble then. Sort on these fields to force xml's to the bottom, images to the top, etc.
(http://i1200.photobucket.com/albums/bb336/Mr__C/MC%20Screenies/Detailsview.jpg)
-
Also, any Windows machine I touch (literally, I do it to other people's machines, without asking in most cases) is to disable the absurd default "hide extensions for known file types" option in Windows Explorer.
I've been thinking about this, and the other Cover Art post. They go together. But I need more time to write up a post and I don't have much time tonight.
-
What would be an easy way to move 10k+ existing cover art files from one folder to a sidecar configuration?
-
What? I'm confused...
If the filename of the thumbnail JPEG file always matches the filename of the relevant media file, then it would work, even if the user has literally all of their video dumped into one big holding folder with no subdirectories of any kind. That's my point.
I was referring to [Series] and/or [Season] artwork. What I meant is that if the standard naming convention decided upon is [Series].jpg for all artwork (for example) and there is no [Season] folder in the user structure, then this will be overwritten for each Season that gets downloaded. rick's post gave a resolution to this, which I had not considered while writing my post
[Series].jpg for a series cover, and [Series] [Season].jpg for a season-specific cover
but this has to be pre-determined and consistent from the beginning, or customizable. One cannot assume all the metadata will be there, nor can one assume the directory structure of everyone, so all variables/possibilities need to be considered. If not, one puts it in the "P:\Cover Art" directory, and issues arise (thus this thread)
it could conceivably work if the user selects a cover art directory too... MC would just have to replicate the full directory structure in the cover art path. That would be uglier, of course, and could hit path-length restrictions.
This seems a bad idea to me also.
add the details you need to help you differentiate, such as columns for Type, Kind, Dimensions. Move Kind and Dimensions left of Name - you won't have trouble then. Sort on these fields to force xml's to the bottom, images to the top, etc.
These changes aren't persistent, so I have to 'customize' the folder each time, and sorting is just an extra step I'd rather not do either. Also, neither suggestion eliminates the need to scroll to get to the bottom of a list caused by the extra files in the media folder, without extra "work" first.
It's not that I can't see the difference in the files with a bit of attention, but I'd rather not *have* to spend the extra attention if it can be avoided. Putting the metadata stuff in a separate location just makes some things easier.
Also, any Windows machine I touch (literally, I do it to other people's machines, without asking in most cases) is to disable the absurd default "hide extensions for known file types" option in Windows Explorer.
Ha, that's funny, I do that also; well, not *every* machine :). I can't understand why someone thought that was a good default; it annoys me greatly.
I appreciate the suggestions, but for me, having the "extra" stuff separated is just better/easier for me and how I work with my media. I'm not saying that there aren't good reasons to keep them all together, there are many good reasons. However, there are some potential issues with that method also, and I feel a good decision can best be reached with good discussion *before* implementation, rather than after. (If you worked where I do, you'd appreciate this much more) :(
Also, I'll reiterate that I'm not insisting my way is best, I'm just trying to point out potential issues I foresee.
-
What would be an easy way to move 10k+ existing cover art files from one folder to a sidecar configuration?
Change the option to "In same folder as file," then try Save Cover Art to external location specified in Options. It seems to me that should work, but mine are there already and I haven't tested.
-
but this has to be pre-determined and consistent from the beginning, or customizable. One cannot assume all the metadata will be there, nor can one assume the directory structure of everyone, so all variables/possibilities need to be considered. If not, one puts it in the "P:\Cover Art" directory, and issues arise (thus this thread)
Not if the images are saved beside the media files. That's the point. The media files are where they are. That fully defines exactly where the images are, perfectly matched to the media. If existing images were not there, they would have to be moved there to be found. Or, as I've acknowledged, it might make sense to support images in subfolders as well. Aside from that possible option, this would be where any images are saved. There would be no option for saving them anywhere else. So far, no good reason for doing so has been identified.
-
These changes aren't persistent, so I have to 'customize' the folder each time, and sorting is just an extra step I'd rather not do either. Also, neither suggestion eliminates the need to scroll to get to the bottom of a list caused by the extra files in the media folder, without extra "work" first.
It's not that I can't see the difference in the files with a bit of attention, but I'd rather not *have* to spend the extra attention if it can be avoided. Putting the metadata stuff in a separate location just makes some things easier.
The changes are persistent here. My Music folder and its sub-directories maintain this layout.
Tip #2. Use the End key.
Tip #3. Use an Explorer replacement such as Directory Opus where you can on a per-folder / hierarchy / type basis filter all the junk you don't want, sort, and group the way you want, etc. This solves the general issue w/meta-data for ALL your programs and folders.
-
Not if the images are saved beside the media files. That's the point. The media files are where they are.
Again, I was referring to the series and seasonal files, not the thumbnails for the individual episodic files. I think I explained some of the possible issues earlier.
"I was referring to [Series] and/or [Season] artwork. What I meant is that if the standard naming convention decided upon is [Series].jpg for all artwork (for example) and there is no [Season] folder in the user structure, then this will be overwritten for each Season that gets downloaded."
Or, as I've acknowledged, it might make sense to support images in subfolders as well.
Which is what I've also been trying to say (very unsuccessfully it seems) :-\
There would be no option for saving them anywhere else.
or...there could be an option; I'm not sure it's been decided yet, although all comments apart from mine seem to indicate otherwise :)
The changes are persistent here...
This solves the general issue w/meta-data for ALL your programs and folders.
Every new folder will need to be modified, even if the changes do persist. it's a bit like taking a pill for the side effects of the other pill. I'd rather not take any pills, and live with the extra files in a separate folder.
Thank you again, but really, these are the minor issues, the extra files being in the folder with my media, and the extra effort required to navigate them are things I'd prefer to avoid, whether or not there are ways around it, I'd still prefer NOT to have to bother.
The reasons I've heard to keep them all together are not super-compelling either, IMO ;)
-
Again, I was referring to the series and seasonal files, not the thumbnails for the individual episodic files. I think I explained some of the possible issues earlier.
"I was referring to [Series] and/or [Season] artwork. What I meant is that if the standard naming convention decided upon is [Series].jpg for all artwork (for example) and there is no [Season] folder in the user structure, then this will be overwritten for each Season that gets downloaded.
Well, I really was going to let this go for tonight, but you know sleeping dogs and all that. ;)
This still doesn't make sense, Justin.. Think about it.
There's no such thing as Season artwork, so there's no point in really discussing that in detail. There isn't support for cover art for any arbitrary tag in the database, and I wouldn't assume they would ever add such a thing. So, if they ever add Season Art as a feature, they'd already be adding something new and special. I think it would be reasonable to assume that whatever filename they choose to have MC use would contain both the Series and the Season names.
But you weren't talking about Season art. You were referring to Series art, but you were acting like it should be Season specific. It isn't a folder.jpg file, it is art that applies to the whole [Series]. If the user sets the series art to something for one file in the series, and then changes a different one to something else, I'd assume that it would change the art for ALL files with the same [Series] tag (a relational field)..
So, overwriting the old JPEG would be the desired behavior in this case. The same would be true for Season art as well, if they ever implemented it.
The Big Bang Theory only has one Series artwork file. To change it, can pick any file tagged with BBT and change it for that file, and the rest automatically update.
That said, I'm certainly not opposed to them providing an option to let people create a catch-all /metadata/ subfolder structure, if they want. I just wouldn't use that option myself, and I wouldn't want it to be that way or nothing.
I actually think that, if you have any choice at all, there should maybe be three options that apply to all cover art and sidecar files in MC:
1. With the media files (Sidecar files)
2. In a Metadata subfolder with the media files.
3. In a specific folder (Automatic)
All three should offer an additional separate option to create folder.jpg files (for Widows Explorer support). And another one to also store images in file tags when possible.
I think #1 should be the default, because it is the most foolproof and cross-compatible.
Number three would work like it does now, sort of. Except that:
1. It would default to a "Media Art" folder in your My Documents folder (rather than buried in the hidden AppData directory). See the other thread for more.
2. MC would take control of the naming structure inside that folder, black box style. JRiver just decides themselves what file and directory structure to use in the specified folder, and it is just designed so the user doesn't have to know they are even there or care, but so that they can all be stored in one spot away from the media files.
If they want to design it so there is no user-option at all, however, then I think the best option is certainly the sidecar method. I agree with Rick, that there aren't many cases where that doesn't work just as well, and I don't see why not to just standardize on that. I know you would rather not though, and you might not be alone.
-
Why? Can you provide an example of another application that is unable to find cover art when saved beside the media file it pertains to? Not only is this simple and foolproof, it doesn't matter what sort of folder structure the media files happen to be in. The media file name is always unique, so the image file name will always be unique. At the same time, there's no difficulty saving a more general image (like a series cover) in the same folder when it's given an appropriate name by the application that puts it there.
Sickbeard and Couchpotato both uses a more non standard naming or placement of art. This can be altered if you have the programming skills, but most don't. I'm not saying that most Programs does not pick up the art, but I'm saying that MC might have problem with importing art from other sources, because of naming and or placement of the art. I don't mind at ALL a default/standard way of saving art next to the files, but I would like a way to save them where ever I like. Some people like folders with 10 media files and 40 art files. I don't. It's a darn mess. I want it in a separate art folder. Add that to the fact that custom paths would solve some integration problems, and you have a VERY legitimate reason why we want to set the location of the art, just like we can with Cover Art today. Just a tad more advanced possibilities if doable.
The only negative aspect of this approach is that move and rename operations in MC might become more complex if you do it this way. You'll need to make changes to all files connected to the media. There is probably methods of doing this today. And if there is not, it could be highlighted that custom folders does NOT support renaming and moving of artwork tied to media files. I would not care one bit. I have my directory structure, and have no reason to move it around.
Thank you again, but really, these are the minor issues, the extra files being in the folder with my media, and the extra effort required to navigate them are things I'd prefer to avoid, whether or not there are ways around it, I'd still prefer NOT to have to bother.
The reasons I've heard to keep them all together are not super-compelling either, IMO ;)
Exactly.
You can't really justify adding 300% more files to a folder, and then commanding all users to make some extra columns in explorer, use third party app to navigate explorer and so on. Let's face it... There is more people out there than me and you. And they might not use MC. They might not want to use other apps. They might not have the expertise or time to fiddle with the explorer file columns to sort things correctly. They just want to see their media files. In households or work situations with more than one user, you might have this problem as well. Not just me.
Let's me make one thing clear. I'm not bitching about Normal episode thumbnails, sidecar files and one Series art. What I'm concerned about is the day that we finally get support for multiple manual backdrops, banners for series, front and back cover art and so on. Some of this art comes in tenfolds! It will become really MESSY. That is why I beg of you to add a image manager to control the positioning, naming and behavior of the art files. I'm trying to think ahead. That's all.
-
What I'm concerned about is the day that we finally get support for multiple manual backdrops, banners for series, front and back cover art and so on. Some of this art comes in tenfolds! It will become really MESSY.
I don't know how likely that is....
I mean, isn't that why Theater View does the background slideshow? But maybe you're right. :-\
-
Well, I really was going to let this go for tonight, but you know sleeping dogs and all that. ;)
I wish you would have. ;) I feel a bit like OJ's lawyer here
This still doesn't make sense, Justin.. Think about it.
There's no such thing as Season artwork, so there's no point in really discussing that in detail.
Season 1
(http://upload.wikimedia.org/wikipedia/en/a/ad/Big_Bang_Theory_1.jpg)
Season 2
(http://upload.wikimedia.org/wikipedia/en/e/e2/Big_Bang_Theory_2.jpg)
Season 3
(http://upload.wikimedia.org/wikipedia/en/a/ae/BigBangTheory_S3_DVD.jpg)
Season 4
(http://upload.wikimedia.org/wikipedia/en/c/c0/The_Big_Bang_Theory_season_4_DVD.jpg)
Plus there are banners, and other photos one might wish to use.
I already pointed out a solution to this particular issue, twice I think, so I really hope we don't continue discussing season art and how I'm wrong about it any longer.
There isn't support for cover art for any arbitrary tag in the database, and I wouldn't assume they would ever add such a thing.
That seems a mistaken assumption to me. They've added all kinds of art lately, and the boards have lots of requests for it. I would actually assume the opposite, and hope they do allow more, even if I don't use it.
So, if they ever add Season Art as a feature, they'd already be adding something new and special. I think it would be reasonable to assume that whatever filename they choose to have MC use would contain both the Series and the Season names.
Again, I disagree with this assumption. They don't do this now, and if it's not considered a possibility in the future, the system they implement now might need to be re-considered again, to allow for this. I'm specifically suggesting some scenarios that *might* come up, and the problems they *might* create, so as to be avoided later.
My point isn't specifically about Season art, necessarily. My point is that it's important to think ahead and plan for things that might come, and make sure that any system created is adaptable to change.
The current system did NOT do that, and because of that lack of pre-consideration, all of the artwork in my database is now "screwed up".
I hope I've finally addressed this issue to everyone's satisfaction, but if not, I give up anyway :)
I have to get to work :D
-
Those are Season images, not Series images. Which, again, you can't do.
I'm not necessarily commenting at all about whether they should add these kinds of features. I'm just saying, it isn't supported now, so discussing it in such great detail that we're making assumptions about what filenames Matt may or may not assign to some hypothetical future feature (and, I guess, assuming he'd do a bad job at it) is a bit absurd and counter-productive.
As I said above...
I actually think that, if you have any choice at all, there should maybe be three options that apply to all cover art and sidecar files in MC:
1. With the media files (Sidecar files)
2. In a Metadata subfolder with the media files.
3. In a specific folder (Automatic)
I agree that they shouldn't hamstring themselves. But I don't see how sidecars hamstring anything. Adding Season and banner and any manner of other image files to the equation would work equally well, so long as the filenames used when those features were added were rationally designed.
Season artwork is a particularly easy one, you name them [Series] - [Season].jpg.
Banners are also easy, [Series] banner.jpg, or maybe you use [Series] banner Counter().jpg if you want to support multiple banner images.
There is no reason that files can't be unique in this system, if these hypothetical future features are rationally designed.
It might make the folder contents increasingly ugly (again, filesystem aesthetics), but it would be perfectly functional. There is nothing about sidecar files that prevents any of that. Ugly, yes. Broken, no.
And that, my friend, was my point and why I was confused.
But, again, to reiterate... I think the best overall solution is to fix the entire Cover Art system with something more comprehensive. Perhaps something like I discussed above. It seems like from the other Cover Art Directory thread (http://yabb.jriver.com/interact/index.php?topic=62266.msg460948#msg460948) that Matt is thinking about it. I have faith. ;)
Now....
Do I think they will add the future features you are looking for? I don't know. Maybe. I wouldn't hold my breath, though. It seems like their system is to automatically grab this stuff for the user (ala the Theater View Slideshow) not rely on a librarian-style OCD user to have their stuff all meticulously organized and tagged with 15 different images for each file.
-
Those are Season images, not Series images. Which, again, you can't do.
Yes, but I was replying to this...
There's no such thing as Season artwork
Perhaps you mis-typed there and meant to say there's no such thing as Series artwork, I'm not sure. However, this is also not correct, and you also already asked about this earlier in the thread, to which Matt replied
Sure it does.
Pick some television and do Cover Art > Get From Internet.
Or let auto-import get it automatically.
Then browse series or seasons in Theater View (or Standard View) and see the pretty pictures.
I don't think we actually disagree on the important points of this discussion. A well-implemented system can/should handle all this without problems. However, the way it's currently handled (all in one folder) does cause problems, so it's not trivial to just say 'sidecar files will work fine for every situation'. It's very likely correct, IF potential issues are considered and addressed up front, which is really all I'm trying to do here.
Also, all the fan art, and background images, etc that are currently being scraped and used in theater view are in a black box right now. I suppose if I wanted to look around I could find where they are stored and make changes, but I don't want to. If those images, and future, potential items were all considered part of ONE, OVERALL system, a solution might be determined that addressed all of these things in one coherent method of handling it all.
Any/all 3 of your suggestions should work, 2 or 3 would be good solutions for me. I prefer to NOT have all the extra stuff sitting next to my files. It might or might not cause issues (likely it will NOT) putting it all in the same folder.
The argument you (I think it was you) made earlier about folders running too deep and causing problems with windows is not something I think should be considered too worrysome though. Adding one more folder to the existing system is unlikely to be the "final straw" so-to-speak. Recreating the same folder structure under a "cover art" folder would also (potentially) only add one more folder than the existing folder structure it's mimicing. I've never run into such a limitation, and have no idea how many levels are allowed. Perhaps users are flirting with this limit, but I'd guess it unlikely.
Anyway, I will conceed that the horse is officially dead, and will not continue to beat him (poor fella) :)
-
Perhaps you mis-typed there and meant to say there's no such thing as Series artwork, I'm not sure.
No, I meant "There is no such thing as Season Artwork in MC." I knew (and thought I didn't have to really say) that there are, obviously, people out there in the world that do create season-specific artwork and that other systems offer this as an option.
Recreating the same folder structure under a "cover art" folder would also (potentially) only add one more folder than the existing folder structure it's mimicing. I've never run into such a limitation, and have no idea how many levels are allowed. Perhaps users are flirting with this limit, but I'd guess it unlikely.
Yeah, that was a bad idea, and I knew it as I was typing it. That's why I suggested the "black-box" Adobe Lightroom style "In a Specified Directory (Automatic)" system. I will say, though, that I've hit the path limit before with deeply nested folder structures. HFS+ doesn't have that limitation, and with it's "package file" system (which are special folders), you can sometimes hit the limits if you try to copy things over to an NTFS volume.
The NTFS path limit is 32,767 characters, with no path component (a filename or folder name) exceeding 255 characters each. You really have to try, but at 129 folders deep, you can hit the limit.
But, agreed, it is probably not something worth worrying about other than a possible error checking condition in the code that manages the folder structures (like Rename, Move, and Copy does).
I don't think we actually disagree on the important points of this discussion.
I completely agree with you about the issues at hand. I'd just pick a different solution. My only point in all of this was:
A) Having an option (preferably using one cover art system for all of MC, nothing specific to these video file issues) would be best.
B) If they just don't have the time/inkling/determination to fix the bigger Cover Art problem and let us configure it with some options (maybe putting it off until MC18 or something), that the best stop-gap choice would be Sidecar files, not a ./metadata/ subdirectory, because it is more cross-compatible with other systems and it is simple.
I totally understand (and this entire discussion has deftly illustrated) that not everyone will be pleased with any one-size-fits-all solution. That's why we have Cover Art settings currently, after all. ;)
-
Also, all the fan art, and background images, etc that are currently being scraped and used in theater view are in a black box right now. I suppose if I wanted to look around I could find where they are stored and make changes, but I don't want to.
By the way, this system is not a complete black box.
You can specify your own images, and even videos, that play in place of the automatically downloaded slideshow. I think on a per-view basis, but it might even be based on an expression, so that you can match based on other fields.
I've never tried it, but I know some other people use it to customize Theater View. It involves dropping image and video files into some special folder in the AppData directory, and naming them in some particular way. If you want to try it, you could certainly search the forum and find stuff about it.
-
What would be an easy way to move 10k+ existing cover art files from one folder to a sidecar configuration?
Once the next build is available:
Select Files > Right-click > Cover Art > Save Cover Art To External Location Specified In Options
-
By the way, this system is not a complete black box.
You can specify your own images, and even videos...
Yeah, I figured one *could* manipulate it; I was just saying that combining all of these separate 'media-related-images systems' into one coherent system would be good overall. Not many users will want to (or even know they can) find obscure locations and use expressions to change this stuff.
-
All this text about someone wanting art to be placed next to the media, and someone want to have it in folders. And still most agree that a more complete system with the option to control this for the user, would be the best. We basically agree, but still disagree. Sigh.... :D
I don't think it's so much to argue about really. Yes, there would probably be less complications if files was added next to the media files. Yes, some people would really like to control the positioning of all art. And this might improve integration with other apps and services. It might also complicate things. We have users on both sides. So, I can not think of any reason what so ever that someone would object to having the art next to the media as a good default, with a sane naming scheme, and a way for the user to customized the location and naming if preferred.
I don't know how likely that is....
I mean, isn't that why Theater View does the background slideshow? But maybe you're right. :-\
Yes, that is what the background slideshow is for. But IF the art system had been working like it really should, then we would have the ability to add our own backdrop images. And THEN we could have many of them. Just like it's done automatically today, to rotate the images. The reason why we would have backdrops on disk, is that it would be possible to get backdrops immediately when you select an item. Not having to wait several seconds for the background to change. That is of about zero use to me as it is today. Unless viewing on the file level. I browse much, much faster than the images update in the category views. I guess there are plenty more like me out there.
I'm not saying that we should drop the online slideshow at all. I love the convenience of having rather good backdrops pop up automatically. I just know that manual backdrops would increase eye candy. One option is to let users add backdrops manually. Another way, that preferably should be in addition to manual backdrops, is to let the online media slideshow download the first image. So this can be used for instant background change when browsing Artists, Series or Movies later on.
I'm not saying that we HAVE to do this now either. But what I'm saying is that we should think of this things, so it all fit later on. Some of my movies have 25+ backdrops.
-
All this text about someone wanting art to be placed next to the media, and someone want to have it in folders. And still most agree that a more complete system with the option to control this for the user, would be the best. We basically agree, but still disagree. Sigh.... :D
Hah! Yes...
But sometimes, that's just what we do here. It is cool, I like discussing this sort of thing. Before it started, I didn't have fully formed ideas about the system or what needed to be done. Now, we know a lot more about how it could work, what to think about for the future, and a lot of those edge-case details.
It is useful, so long as it isn't confrontational, which this thread wasn't. :D
-
Hah! Yes...
But sometimes, that's just what we do here. It is cool, I like discussing this sort of thing. Before it started, I didn't have fully formed ideas about the system or what needed to be done. Now, we know a lot more about how it could work, what to think about for the future, and a lot of those edge-case details.
It is useful, so long as it isn't confrontational, which this thread wasn't. :D
I totally agree!! ;D
-
True. But I still would prefer if you all would just agree with me in the first place though :P ;)
-
Changes in tonight's build described here:
http://yabb.jriver.com/interact/index.php?topic=68476.0
-
But sometimes, that's just what we do here. It is cool, I like discussing this sort of thing...
I might say the same, now that the others see the light and agree with us. But I think this went way beyond what could possibly be of any use to the developers. At reply #10...
I'm thinking only supporting sidecar artwork for videos (so no Cover Art folder usage) might be the best solution.
One could only hope he had the good sense to do something productive instead of read replies #11 to 48.
This was, essentially about where to save meta data. The program already supports, more or less, media files in any folder structure we care to use. It follows that options for meta data include (1) using the same folders (i.e., saving meta data "sidecar" files "beside" their media files, (2) replicating that same structure in a different location, or (3) creating some other folder structure. Aside from those choices, we arguing about how the program saves it's own data in the file system. Suggesting the developers can't figure out how to name a file or that the results will be "messy" is ludicrous. It's data. Being saved to a file system.
The first priority is that it works. The next (but probably not separate) priority is that it be straightforward, not confuse users and possibly not frustrate the use of the same data by other applications. The first option seems to be the obvious choice, but it seems Matt already knew that. At the same time, there are related questions that have gone unanswered...
Do we need options for other schemes, or would that just create unnecessary issues? The current options for saving cover art in different ways seems to have created more confusion and problems than it's worth. This discussion has failed to identify any good reasons for allowing more than one location.
On the question of whether meta data should be saved in subfolders, we identified one case where another application (Sick Beard) does so (AFAICT, for episode thumbnails only). That's been used as grounds for saving meta data in subfolders generally—when there are many good reasons not to. The first priority for this scheme should be effective support for MC's own meta data system (most of which is not yet implemented), not third party applications. The first question should be whether or not Sick Beard even needs to be supported. It gets data from TVDb, as will MC integrated system. Why would anyone continue to use Sick Beard (for getting meta data) once that's implemented? If it's a matter of supporting Sick Beard (or anything else saving meta data in subfolders), the sensible solution is to have MC look in subfolders for existing meta data, just as it does the root. The meta data it actually uses (whether obtained from a subfolder or downloaded) would be saved in the root.
I'm not completely against the use of subfolders. They might be appropriate for some things that might be supported in the future (e.g., when a meta data retrieval system is in place and the data is readily available). Things like posters and fan art where there can be a number of images (more than a few) pertaining to each item (movie or series). That might work as I suggested above—downloaded series posters, for example, would be saved in a subfolder and the one used saved in the root. Or a subfolder might be the only location—downloaded banners, for example, that are cycled or chosen at random for a particular view. But there's no point discussing this here, as there are no existing features that require subfolders.
True. But I still would prefer if you all would just agree with me in the first place though :P ;)
Some of us don't drink as much beer as you. ;)
-
But there's no point discussing this here, as there are no existing features that require subfolders.
You should work where I do, they don't think about the future when making decisions about how to do things either ;)
-
You should work where I do, they don't think about the future when making decisions about how to do things either ;)
Are you suggesting you're employer would benefit from discussions like this? There's nothing wrong with considering the impact of features that might be added in the future to changes being considered now. But that's not what happened. The discussion was sidetracked by vague references to future possible features. Proper consideration of those possibilities would have found they make absolutely no difference to the matter at hand. As a result, relevant issues were missed. Worse, probably none of this was of any use to the developers. As usual, however, they seem to have done some good work while ignoring us. ;D
-
Are you suggesting you're employer would benefit from discussions like this?
ABSOLUTELY!!!!
They do things without thinking at all, then implement changes poorly, then re-do them a day or a week or a month later. Consistently. All the while, the important things don't get done, because everyone chases their tail trying to recover from the last bad decision. It's terrible!!
I don't mean to imply that happens at JRiver, not consistently, I don't believe that.
I just know all-too-well what happens when these kinds of discussions don't take place.
For example, the possibilities of how this system may or may not work properly don't seem to have been fully flushed out at JRiver prior to the situation that existed with the cover art being duplicated, which led to this thread in the first place. Stuff got overwritten, and it caused an issue. That's not to say it wasn't considered, but the issue wasn't avoided, so something got overlooked it seems. i.e. the discussion seems to have not been thorough enough to have caught this problem before it occurred.
My point is/was that a thorough discussion taking place PRIOR to changes can often times flush out potential issues, and they can be dealt with in the planning stages, not in the firefighting stage after the problem shows itself in real-world use.
The fact that you think nothing good came from this discussion, because the same decision was reached after the discussion, is inaccurate. It shows that many possibilities were considered, and the potential issues were addressed (if any) and confirmed the initial decision was likely a good one. This results in a new system that has a high likelihood of success. This is, of course, no guarantee that something new won't come up and force a change, but it lets the process move forward with a sense of confidence that the topic won't need to be revisited again soon; because of a problem that could have been avoided.
For example, had this all happened before the change prior to this change, all of this discussion would have been avoided, or at least pulled forward to have happened prior to the first change; which would have at least saved me several hours of having to 'Get Movie & TV Info' on a couple hundred files a second time.
The Season artwork could have been an issue if it had not been discussed, if they had decided to just go with [Season].jpg in conjunction with having all episodes of all seasons in one folder. That you suggested [Series]-[Season].jpg may have saved that mistake from happening. Hard to say, but these kinds of discussions DO lead to good ideas, and expanded viewpoints of the process/system as a whole, and generally help avoid unnecessary problems/issues.
There's nothing wrong with considering the impact of features that might be added in the future to changes being considered now. But that's not what happened. The discussion was sidetracked by vague references to future possible features
"There's nothing wrong with considering the impact of features that might be added in the future...discussion was sidetracked by vague references to future possible features."
i.e. considering...features..in the future...was sidetracked by...references to future possible features ?
Proper consideration of those possibilities would have found they make absolutely no difference to the matter at hand
No, proper consideration DID find they (likely) make no difference, in this case. If the discussion did lead to discovery of a problem, that problem would then have been avoided, and the cleanup of the fallout would also have been avoided. I consider this a success, and a good use of time. I spent less time in this discussion than I will spend cleaning up the thumbnail issue the lack of this discussion caused because it wasn't held before the change prior to this one.
As a result, relevant issues were missed
Wait, what?!? As a result of a lengthy discussion that didn't turn up any serious 'relevant issues', "relevant issues were missed"?!? What relevant issues were missed, and why didn't you bring them up during the discussion intended to find them?
Worse, probably none of this was of any use to the developers
I'm not so sure about that. Perhaps not, but if it avoids problems, I would say it was of use to them, even if not readily apparent.
As usual, however, they seem to have done some good work while ignoring us. ;D
Finally; we agree :) :)
-
Some of us don't drink as much beer as you. ;)
I'm in there trying.
Of course, I'm pretty sure you meant to exclude me from the "some of us". ;)
-
Wait, what?!? As a result of a lengthy discussion that didn't turn up any serious 'relevant issues', "relevant issues were missed"?!? What relevant issues were missed, and why didn't you bring them up during the discussion intended to find them?
This is a perfect example of how to make what should be a simple and productive discussion draining and unproductive. Ignore what others are taking care to explain, or assume their comments are for the sole purpose of disagreeing. In this case, I even went to the trouble of providing examples of issues we missed. Fortunately, Matt did not miss one major one—providing an alternate location to support meta data for external media. I've now made some comments on use of subfolders and support of other applications. You've ignored them.
All of my comments have been on the question introduced by Matt. As for the issue that started this topic, it's still unclear to me exactly what is happening, or what bearing the meta data storage location might have on it. The handling of series is something under development and obviously incomplete. Category cover art for series was introduced, and this caused some unexpected (at least by users) behaviour. It's difficult to say whether comments on and discussions about such things are of any use or not. They're probably worth mentioning, in case they're an unintended consequence the developers are unaware of. Otherwise, in the absence of any comments or questions from the developers, it might be best to defer discussion until development has progressed further.
Of course, I'm pretty sure you meant to exclude me from the "some of us". ;)
No. I was hoping beyond hope someone else was sober. ;)
-
This is a perfect example of how to make what should be a simple and productive discussion draining and unproductive. Ignore what others are taking care to explain, or assume their comments are for the sole purpose of disagreeing. In this case, I even went to the trouble of providing examples of issues we missed.
I was hoping we were done, but it seems not :( :(
First, why do you expect this should be "simple"? Thousands of individuals using a brand new tool, with more expected to follow, in the most customizable software, all wanting different things, and you think it will be "simple"?
How was it instead "unproductive" (excepting these last posts)?
I read every word printed here, and have not ignored anything. I cannot claim to have understood everything you have written, but not for lack of intelligence, nor trying. some of it is simply incomprehensible, or just 'rambling' and opinion presented as fact. I don't say that to be mean, or to "attack" you, it just doesn't make any sense. here is but one, of many, example(s).
In a folder structure organizing media by type, ending, for example in \Season [Season]\, all files pertaining to a particular season of a series belong in that folder. There's nothing wrong with then adding further folders for different file types, but it's inconsistent with the preceding structure. More importantly, like applications, most users will prefer to see media files along with whatever files are saved "beside" them. That, in fact, is the very purpose of saving them that way.
Why is adding an extra folder to keep related, but different use-case-type files separate from files I will actually use "inconsistent with the preceding structure"? I see it as a natural extension of that structure, as do others. All of the files still relate to the \Season [Season]\, but if my normal usage is to locate video files I can play by double-clicking, keeping files I can't play separated makes perfect sense, for my usage needs. It's not inconsistent at all; for my needs.
Then you go on to state that "most users will prefer"... yet, that's simply your opinion, and I disagree with it, as have many others in various, related threads.
Saving files of different usage/purposes in the same folder is NOT, in fact, the purpose of this structure. The purpose in my usage is to keep files related to a particular season grouped together to make them easy for me to find, but not to clutter the files I actually intend to use, thus the separation into a separate folder.
In my comments, I have provided several examples of potential pitfalls, and solutions or reasons they turned out to not be pitfalls. I pointed to your comment as a solution as well, 2 or 3 times actually. Saying you provided examples of issues we missed is not the same as providing examples. Where are these examples of things we missed?
I am not the one that appears to assume "comments are for the sole purpose of disagreeing". If I disagree, I will say so, and if I agree, I will say that also. If you care to see some examples of this, please re-read this thread, there are plenty to choose from, including some pictures.
I've now made some comments on use of subfolders and support of other applications. You've ignored them.
I addressed them at least twice, previously. I don't see the point in repeating myself.
All of my comments have been on the question introduced by Matt.
Sticking to one topic, and not thinking about potential issues related to it is not something to brag about, not to me anyway. Especially in a thread started to discuss another topic.
As for the issue that started this topic, it's still unclear to me exactly what is happening, or what bearing the meta data storage location might have on it
Really? After all your comments to me about not understanding, and ignoring you, you now tell me you don't understand the topic in question? Wow. Maybe that's why your comments don't really address the topic, you don't understand it. Perhaps that will be a good reason not to hit reply in the future?
The handling of series is something under development and obviously incomplete. Category cover art for series was introduced, and this caused some unexpected (at least by users) behaviour.
As I said, it caused some unexpected behavior exactly because it (seemingly) wasn't thoroughly thought out and discussed prior to implementation. Thus the reason I tried to include discussion about possible issues that might be introduced in the future, so as to avoid this unexpected behavior in the future.
It's difficult to say whether comments on and discussions about such things are of any use or not. They're probably worth mentioning, in case they're an unintended consequence the developers are unaware of.
NO, not "in case", BECAUSE the developers might be unaware of unintended consequences.
It's clear to me you are not actually reading and understanding what I'm writing, so please, seriously, don't reply. I'm certain that no one here wishes to see this continue; I certainly don't.
**Sorry Jim, I appreciate all that you folks do, and the complexities of this wonderful software. I know these last posts haven't been "your cup of tea", but I do think the topic warranted the extra discussion, or I wouldn't have bothered.
I'm going to bed now, and won't be responding to any more comments unless they specifically relate to 'Get Movie & TV Info' issues.
-
It's hard not to take a side here, but I'll try not to. There IS a lot of assumptions in the last replays though. Let's try to be a little more open minded and not assume to much. I think most contributers here read all replays carefully and write their thoughts because it might help MC17 improve in a direction most users would like. This should be the goal. Not convincing people that your way is what everyone else likes the best.
Let's just leave it at this, take a beer and chill before this thread is locked as well? :)
-
I'm trying to find where this "screengrab" option is so I can manually select an image from the video file, but I can't find it. Anyone help?
-
First, make sure you're using Red October Standard (not RO HQ, because it uses MadVR, which doesn't allow for screen grabs.)
Then, play a video, pause when you see the image you want for your cover, while playing, right-click on the playing video, select Window > Use Screen Grab for Thumbnail...
If you want to use the image for something else, you can right-click on the playing video, select Window > Screen Grab to file... to copy it to your clipboard.
Done
-
First, make sure you're using Red October Standard (not RO HQ, because it uses MadVR, which doesn't allow for screen grabs.)
madVR added screenshot functionality in version 0.84.0 (2012-10-06)
Media Center should be able to support this.