Print

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

[6233638]

Is there any way to move all those DVD covers into a specific library folder? Right now they're just being placed inside my .iso folder, which means that they're clogging up my windows libraries and search results.

For example:


I used to be able to just type a film title, hit enter, and have it play.

[glynor]

I know you can't change it to a specific location, because there were all sorts of problems with that and keeping the files unique.  The problem was that cover art from new stuff would continually overwrite old stuff if the filenames weren't kept completely unique.

Keeping them completely unique, without adding something like a GUID "key" to the filenames, is more challenging than you might expect.  Take just TV Shows.  You have to name them in an episode-specific way, or else you can't have different art for each episode.  But, what about shows that have dates but no Episode and Season numbers, for example (the news or The Daily Show)?  So, you can't just use [Series] - s[Season]e[Episode].jpg for those, as they'll all be "The Daily Show - s0e0.jpg" and overwrite each other with each airing.  But, you can't just use the [Name] because episodes of shows can have the same names.  That's probably rare, but it could happen, and what about people who didn't actually bother to name them so they're just some kind of default value in the [Name] field?  And then people have all kinds of weird file types aside from just movies and TV Shows (concert videos, stock videos, trailers, music videos, home videos, technical videos and screencasts, and on and on), each of which would need their own naming scheme to keep them unique.

Plus, then where do you put them?  If you use a complex folder-based naming scheme, but the user buries it in C:\Users\<USERNAME>\Documents\JRiver\Media Center 18\Cover Art\ then Windows will have one set of path-length restrictions to deal with, and if they put it at M:\Extras\Cover Art\ they'll have much more "play".  But what if you move an already-established scheme?  It was all discussed by a bunch of people in great detail, and the best we could all collectively come up with to fix the (then completely broken) cover art system was to just store them with the files.  If the files are already there, and you store it next to them with the same filename, you are guaranteed to have a "valid" filename and path to use, and each one is already guaranteed to be unique (unless you have identically named files with different extensions in the same folder, but it would stand to reason that these would share cover art anyway, so the point is moot).

That said, I thought there was a way to just disable their creation entirely (which wouldn't help you with what is already there, but would stop it from getting worse, and then you could just use MC to find/delete all of those files), but now I can't find it.  Someone else might need to chime in.

I'm pretty sure there's still a way.  Maybe disable the Cover Art "getting" in Auto-Import?  But that would also disable it for Audio, which you might not want.

[glynor]

I will say...  At the time of the discussions, I'd suggested that they provide an option with three choices:

1. The current behavior (store them with files) - default
2. Automatic in a specified location
3. Off.

If you choose the first, it would work like it does now.
If you choose the second, you'd give it a folder to use (default would be in with the Library Backups), and then MC would manage it using GUID keys.  The filenames would all be unintelligible and ugly things like 15c9d182-6ddf-44cb-98e4-80ae124ba9e7.jpg, but the database could find them so it wouldn't matter.
If you chose the third, then MC wouldn't display, or store, cover art for any video whatsoever.

I still think that would be the best solution, and it would keep everyone happy.  As it is, though, they didn't want to implement #2 for whatever reason (it is a pain in the butt, and I don't see why you can't just keep them with the files, I do).

[6233638]

I know you can't change it to a specific location, because there were all sorts of problems with that and keeping the files unique.  The problem was that cover art from new stuff would continually overwrite old stuff if the filenames weren't kept completely unique.

I assumed that MC18 had its own internal database; is that not the case? Is it just scanning folders for content every time you start it up?

Plus, then where do you put them?  If you use a complex folder-based naming scheme, but the user buries it in C:\Users\<USERNAME>\Documents\JRiver\Media Center 18\Cover Art\ then Windows will have one set of path-length restrictions to deal with, and if they put it at M:\Extras\Cover Art\ they'll have much more "play".

I seriously doubt there would be an issue with people going over 32,767 characters.

But what if you move an already-established scheme?  It was all discussed by a bunch of people in great detail, and the best we could all collectively come up with to fix the (then completely broken) cover art system was to just store them with the files.  If the files are already there, and you store it next to them with the same filename, you are guaranteed to have a "valid" filename and path to use, and each one is already guaranteed to be unique (unless you have identically named files with different extensions in the same folder, but it would stand to reason that these would share cover art anyway, so the point is moot).

It makes sense for the sake of simplicity, but I am approaching 1000 films in my library, and they display just fine in MC18, but file management is now a serious pain.

I have them spread out over a number of drives, and they are simply located in
root:\Films\

Films I have seen, go in
root:\Films\Watched\

I then have Windows Libraries that pull together all the files into "All Films", "New Films", "Watched Films" which are simply A-Z listings of all titles, that are searchable via the start menu. (type the name, hit enter, film starts)

Now all of those views, and my search results, are cluttered up with cover images.


Similarly, I am also having problems moving files from "New" to "Watched". Previously all had to do, was drag the iso to the "Watched" subdirectory, but now MC18 complains that the original file is missing and picks up a duplicate in the new location. Moving files inside MC18 is a real hassle and has to be done with the "rename" tool. I can't just drag from one library view to another, and have it move the file for example, and there's no way I can find to actually locate the files on my hard drive from within MC18. (e.g. right-click and "Show in Windows Explorer" in iTunes)

That said, I thought there was a way to just disable their creation entirely (which wouldn't help you with what is already there, but would stop it from getting worse, and then you could just use MC to find/delete all of those files), but now I can't find it.  Someone else might need to chime in.

That doesn't really help - one of the main reasons I purchased MC18 was the nice cover-based view of my film library for when I want to watch a film, but haven't actually decided what yet. Browsing the cover art is a lot nicer for that, and it's a lot better for guests.

[glynor]

I assumed that MC18 had its own internal database; is that not the case? Is it just scanning folders for content every time you start it up?

It does, certainly, have its own database, but the image files the database references (the image data) have to be stored on disk somewhere.  With the current architecture, this is not stored inside the database files themselves (which would be terrible, it would make the database size balloon uncontrollably, and would cause problems with remotely connected clients).

Keep in mind, when you connect to a remote Library Server, MC has to download the entire database first, and then pushes delta changes back up to the Server.   You don't want to be pushing all that cover art across the Internet unnecessarily.

The current system allows each client to cache its own copy of the displayed thumbnails, and the cover art itself is stored with the files (the sources used to build the thumbnails).

I seriously doubt there would be an issue with people going over 32,767 characters.

You'd be wrong.

There are actually two issues.  There is the total NTFS path limit (32k characters, as you mentioned).  This is known as the "extended path limit" and it applies to many, but not all, Windows API functions if you use their extended (unicode) versions.  The official Windows API MAXPATH is actually a much more trim 260 characters (commonly limited in practice to 255 characters), so some of the underlying Windows functionality is unavailable for those "extended" path names.

From the MSDN BCL Blog:

Let’s start by looking at one of the more interesting exception messages in the BCL, the PathTooLongException:

    [PathTooLongException]: The specified path, file name, or both are too long. The fully qualified file name must be less than 260 characters, and the directory name must be less than 248 characters.

"260 characters? That’s ridiculous; increase the limit", say our customer bug reports. To everyone who got their bug resolved as "won’t fix", we’d like to explain this problem more completely and describe current efforts to address it.

To avoid confusion, let’s get some terminology out of the way:

    Path: a fully-qualified file name or directory name. In other words, if you have a file C:\temp\fileA.txt, the file name is often called fileA.txt, but the path or fully-qualified file name is C:\temp\fileA.txt
    MAX_PATH: This is the maximum length of a path according to the Windows API, defined as 260 characters.
    Long path: a path that can be longer than MAX_PATH characters.
    Long file name: not the same as a long path. This term is used in contrast to short file names – those 8.3 names you may remember using long ago.

There are ways around this (using the "extended path" prefix of "\\?\") but that has other implications as the Windows API then provides the path directly to the filesystem, and doesn't do any further handling.  This can be problematic, and those paths are not guaranteed to work with all applications in all cases.  In most cases, it is still bad practice to enforce any naming scheme that forces paths longer than 255-260 characters.  Plus, you know, they still probably need to support Windows XP (the limit is a hard 255 characters there), so they can't necessarily count on all of the API changes in Vista/7/8 being available.

I also believe I remember from those old discussions, but don't have time to search, that there was some other limitation on folder depth that became problematic with deep directory structures, even if the system was fully "extended path" compliant.  I don't remember the details though, and brief searches didn't bring it up.

And remember, people can (and do) store things like thumbnails and media on network locations, so that path could start with something like:

\\myserver.mydomain.com\share\path\to\my\database\folder\path\to\my\thumbnails\folder\<START MEDIA SPECIFIC SUBSTRUCTURE HERE>

For each and every single file.

Like I said before... If you look back through the forum, there were monumental discussions of this very fact.  People actually posted concrete examples of filenames (using the old system) that were already hitting the length caps, or would be easily if they were moved to something like the default <my documents> directory structure.

It makes sense for the sake of simplicity, but I am approaching 1000 films in my library, and they display just fine in MC18, but file management is now a serious pain.

I have an order-of magnitude more (around 3k movies and 8k total videos in my home Library right this second, and around 35k in my work library).  Folder structure and using MC's database solves it.  I never even look at the files on disk, and if I need to, the Rename, Move, and Copy tool makes short work of any file-organization I need done, automatically, based on file tags.

The Views in MC, of course, can filter anything in and out you want.

I then have Windows Libraries that pull together all the files into "All Films", "New Films", "Watched Films" which are simply A-Z listings of all titles, that are searchable via the start menu. (type the name, hit enter, film starts)

I can see how this workflow would be problematic.

I admit, I don't use Windows Explorer for ANY file browsing at all, because it can't access any of my file metadata (the Description, Actors, Watched Status, Rating, Last Played, Year, etc, etc, etc).  For example, you're end-running the fact that Windows Explorer doesn't have (robust) file metadata to add a "watched status" to your movies by moving them into a particular folder.  I don't need to do anything like that, because MC tracks it automatically.  I just have an "Unwatched Movies" view in Theater View that lists only the movies I haven't yet watched (no matter where on disk they live).

To me, that is the point of MC.  It makes it so I never have to search for video files on disk through Windows Explorer, because that's impossible, because mine are spread across 16TB of disks across the network (including some that are on only-sometimes-attached removable drives).  File management in Windows Explorer is a bag-of-hurt that forces me to deal with things one at a time, and that's a dealbreaker with a large library.

Still, though, like I said... I think there is a way to turn this off, I just don't remember how.  Matt, jmone, rjm, or someone else who knows this system better (and actually cares about where the cover art is stored)... Can you comment?

I know how you could use MC to delete/eliminate the cover art JPEGs that are already there in one fell swoop (and I'm happy to help 6233638 do this when we get there), but the first step is to disable the creation of the files in the first place, so that it doesn't keep happening to him.

If there isn't currently a way to turn this off, then that should be fixed.  I can see how it might be too much work for them to craft an "automatic storage" system, but you should be able to turn the cover art system "off" entirely for video files so that these JPGs don't get littered all over the place.

[6233638]

It does, certainly, have its own database, but the image files the database references (the image data) have to be stored on disk somewhere.  With the current architecture, this is not stored inside the database files themselves (which would be terrible, it would make the database size balloon uncontrollably, and would cause problems with remotely connected clients).

I didn't mean that it should store the files inside its database, just that it seems like you could have a specific MC18 "Cover Art" folder to store all the files with a structure under 260 characters, and reference them, rather than storing them with the files themselves.

There are actually two issues.  There is the total NTFS path limit (32k characters, as you mentioned).  This is known as the "extended path limit" and it applies to many, but not all, Windows API functions if you use their extended (unicode) versions.  The official Windows API MAXPATH is actually a much more trim 260 characters (commonly limited in practice to 255 characters), so some of the underlying Windows functionality is unavailable for those "extended" path names.

Right, this was unclear to me. I can see how it might be an issue if the limit is 260 characters if it is simply trying to store the files with the same name as the film title, rather than something referenced in a database.

I have an order-of magnitude more (around 3k movies and 8k total videos in my home Library right this second, and around 35k in my work library).  Folder structure and using MC's database solves it.  I never even look at the files on disk, and if I need to, the Rename, Move, and Copy tool makes short work of any file-organization I need done, automatically, based on file tags.

The Views in MC, of course, can filter anything in and out you want.

While it would be nice to stay 100% inside MC for some people, it still doesn't seem as quick as simply hitting the windows key and typing the filename in, if I know what I want. MC might not be running, it might be in a different view etc. And I don't really like relying on metadata that is only stored inside a proprietary database, because maybe I will want to move away from JRiver if something better comes along in the future. The file structure I have keeps it really simple to know whether a film has been watched or not.

I admit, I don't use Windows Explorer for ANY file browsing at all, because it can't access any of my file metadata (the Description, Actors, Watched Status, Rating, Last Played, Year, etc, etc, etc).  For example, you're end-running the fact that Windows Explorer doesn't have (robust) file metadata to add a "watched status" to your movies by moving them into a particular folder.  I don't need to do anything like that, because MC tracks it automatically.  I just have an "Unwatched Movies" view in Theater View that lists only the movies I haven't yet watched (no matter where on disk they live).

To me, that is the point of MC.  It makes it so I never have to search for video files on disk through Windows Explorer, because that's impossible, because mine are spread across 16TB of disks across the network (including some that are on only-sometimes-attached removable drives).  File management in Windows Explorer is a bag-of-hurt that forces me to deal with things one at a time, and that's a dealbreaker with a large library.

Well that's why I use Windows' libraries feature. I don't have to know where the files are, but I do know whether it's a film that I have watched or not.

As an example, I can't see a way to bring up a big list showing most of my titles at once in MC. I can shrink down the thumbnail view really small, but then I can't make out what the covers are, or even read the full title.
Details view shows me a list of 48 titles vertically. In Explorer's list view, I can see eight columns with 41 titles in each, or 328 films. (well, half that, now that each has a JPG of the same name in with it)

I do prefer MC18 for just scanning through my library - whether it's the full library or my "unwatched" library, if I want to see a film by a specific director, or starring a particular actor. But there are times where being able to bring up a big list like that, and actually rely on the file structure itself to know whether I've seen something yet, rather than a database, can be beneficial.

To look at it another way, if I just had all my films on a single drive, dumped into a single folder, relying on metadata and then wanted to import that library into MC18, I would then have to go through and manually mark each title which had already been viewed.

I know how you could use MC to delete/eliminate the cover art JPEGs that are already there in one fell swoop (and I'm happy to help 6233638 do this when we get there), but the first step is to disable the creation of the files in the first place, so that it doesn't keep happening to him.

It would be easy enough to delete them - I would just have to set my "All Films" library to group by type and delete them all, but then I won't have any covers inside MC18?

It's not that I don't want the covers to be there, it's that I want them to be inside their own "Cover Art" folder hidden away somewhere, rather than kept in with the files themselves, clogging up the Windows Library views and search results.

[datdude]

I would like to see the option to store cover art in a specified folder for another reason.

I have numerous external hard drives that can take a bit of time to spin up, after my pc wakes, and this causes MC to not see the video cover art and intsead displays a low res version of the cover art (particularly noticeable in Theater View), until that drive is fully spun up and recognized. 

Right now I have to go through  the tedious task of taking every new movie I import, exporting them to a playlist, editing the playlist file with a text editor, replace the cover art paths to point to my SSD, reimport the playlist and also manually move the cover art. Not ideal at all.