Print

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

[Amleth]

Why is it audio files have to option to store metadata in the library folder if you don't want to write it into the audio file tags directly, but downloaded stubs and images related to video files are always placed in the folder with the particular media file?

Why can't downloaded box art and metadata stubs for video files go into the Library folder like the data from the audio files that isn't written into file tags directly? I don't understand why audio metadata is segregated like this but the video stuff is spread around my file system. A lot of my video folders I'd prefer not to clutter with all the extra files that make it take three times as long to scroll through.

Is there some technical limitation involved here, or is it possible we could have an option for this in a later version?

[Matt]

Audio has artist / album / name, but video often has nothing unique.

This means there's no reliable human-readable way to name the files if you don't store them next to the video itself.  We could use not human readable names like a library key or hash of the filename, but both create a bunch of new problems.

[connersw]

Thanks Matt--that explains a lot.  I've read quite a few threads on this topic, but they all usually relate to what they do and why they are there.  This is the first explanation I've read from JRiver's team on why they are saved where they are.  Maybe I just missed it before, but I appreciate it. 

Is this the reason there is no "Audio Mode" for video files with an option to save Cover Art as Folder.jpg?  To avoid multiple files in the same folder with the same name?

Also, what is the reasoning around not making the sidecar files hidden?  I've read from you that it is not possible:  http://yabb.jriver.com/interact/index.php?topic=69797.0  But a month later you posted about using the file system hidden attribute:  http://yabb.jriver.com/interact/index.php?topic=70666.0  Would it not be possible for MC to do the latter by default?  Or have an option to turn it on? 

[glynor]

Is this the reason there is no "Audio Mode" for video files with an option to save Cover Art as Folder.jpg?  To avoid multiple files in the same folder with the same name?

This is why:
http://yabb.jriver.com/interact/index.php?topic=68447.0

Here's the discussion after the fact:
http://yabb.jriver.com/interact/index.php?topic=68476.0

The basic answer is that you can't make a lot of assumptions about how videos are stored, and folder.jpg wouldn't work for the vast majority of them (how often do you have each file saved in its own folder?).

[connersw]

The first link does not work.

how often do you have each file saved in its own folder?

For movies, always.

[glynor]

The first link does not work.

It does here.  I'll pasta it again.

http://yabb.jriver.com/interact/index.php?topic=68447.0

That was just one thread about it, but it had some of the most useful discussion of the issue (with screenshots and stuff).  I'm not suggesting it couldn't be improved, but the system would have to be complex.  As Matt pointed out:

This means there's no reliable human-readable way to name the files if you don't store them next to the video itself.  We could use not human readable names like a library key or hash of the filename, but both create a bunch of new problems.

He knows, because that's how it used to be, and it was a disaster.

EDIT:  Oh, crud.  I see.  The first link was to a thread on the Beta board.  That's why it doesn't work for you.  Sorry.  Matt, can you move that thread so people can see the horrorshow?  For now, I can leave you with this screenshot:

[glynor]

Jim moved it, so you should be able to see the thread in the first link now.

Thanks, Jim.

[6233638]

I'm happy to have some randomly generated unique identifier for any video added to Media Center's Library, if it means that the cover art could all go into a single directory in %APPDATA%\J River\Media Center 19\Cover Art to load instantly off my SSD and avoid spinning up every hard drive in the system when certain library views are accessed.
 
I would prefer not to have the sidecars, but they should be useful as a "safety feature" and I would like to see them implemented with other files that Media Center cannot write metadata to. (e.g. SACD ISO or DSF files)
It would be nice if the sidecar attributes were set to be hidden by default as well.

[flac.rules]

Sidecar-files are fine, but MC seem to also use sidecar-files on video-files with tagging support, why?

[InflatableMouse]

One issue with MC generated files stored next to the media files is that MC doesn't move its own files when you move the media files with library tools/move, rename tool.

(unless this has been fixed I haven't tested it in a while)

[Matt]

One issue with MC generated files stored next to the media files is that MC doesn't move its own files when you move the media files with library tools/move, rename tool.

(unless this has been fixed I haven't tested it in a while)

I think you're a bit out of date on that

17.0.152 (5/14/2012)
Changed: When moving a data file with a sidecar image, the sidecar image will move along with the data file.

17.0.59 (12/21/2011)
Changed: Using Rename, Move, & Copy for a video file will also move sidecar edl, srt, smi, idx, sub.

In other words, if you move files inside MC, the video sidecar and artwork will also be moved.

[connersw]

Glynor:  I read and understand what Matt wrote.  What I am asking about is Movie Cover Art saved next to the video itself as folder.jpg.  Every Movie video file has it's own folder with the video file, the sidecar, and the Cover Art.  In order to view the Cover Art in Windows Explorer as part of the folder, I have to manually make a copy of the Cover Art and rename it folder.jpg.  I would prefer if I could set MC to do this for me automatically, and then I don't need to have two copies of the same file with different names. 

My assumption is that since not everyone has their folder structure set up this way, MC does not allow it to protect users from creating a mess.  I could see that as a default, but what about an option to turn it on for those that know what they are doing?


Matt:  The artwork does not get moved unless it is imported into your library and tagged.  Please see this thread:  http://yabb.jriver.com/interact/index.php?topic=85295.0  You said you were listening; curious if anything will change?

Also still curious about the possibility of MC making sidecars hidden. 

[glynor]

Matt:  The artwork does not get moved unless it is imported into your library and tagged.  Please see this thread:  http://yabb.jriver.com/interact/index.php?topic=85295.0

It isn't quite so simple.

MC does move the artwork if it created the files (regardless of import status or tagging).
MC does NOT move the artwork if they pre-existed (it doesn't touch things it didn't make without explicit user instructions).

Or, at least, that's the way it is supposed to work.  I haven't done extensive testing on it, but that's the way it should be.  Is that not what you're seeing?

[connersw]

As I wrote in the previous thread, it does not work that way.  Maybe it is supposed to and there is a bug?

I just tested it again.  Deleted the artwork, and had MC go get it.  Folder.jpg and the old folder stay.

Edit:  So I had been testing it with Audio files.  It does not work with Audio files.  However, I just tested it with Video files, and it does move the Cover Art with Video files if MC gets it for you (and it is named [Name] [[Year]].jpg).

[Matt]

Edit:  So I had been testing it with Audio files.  It does not work with Audio files.  However, I just tested it with Video files, and it does move the Cover Art with Video files if MC gets it for you (and it is named [Name] [[Year]].jpg).

Audio files are a bit tougher because lots of files can share one image file.

I agree we should try to solve the problem.  I'm just not sure the best way.

[MrC]

17.0.152 (5/14/2012)
Changed: When moving a data file with a sidecar image, the sidecar image will move along with the data file.

17.0.59 (12/21/2011)
Changed: Using Rename, Move, & Copy for a video file will also move sidecar edl, srt, smi, idx, sub.

In other words, if you move files inside MC, the video sidecar and artwork will also be moved.

Except when it fails:

Bug alert ahead...

When I rename over an existing file (not in the MC library), I get a confirmation dialog asking about overwriting.  Its the standard Explorer confirmation asking to Replace, Don't Replace, or Copy.  I've found that if I deny overwriting, MC has already moved sidecar and artwork files, so has broken the "atomicity" of a library entry (hence losing cover art, sidecar data).  This seems a bug.

[connersw]

Thanks Matt.  I appreciate the feedback that it is at least getting discussed.  I believe MrC had some good ideas in the previous thread.

So...about those hidden sidecar files?

<---lashes non-moving horse repeatedly. 

[Matt]

Thanks Matt.  I appreciate the feedback that it is at least getting discussed.  I believe MrC had some good ideas in the previous thread.

So...about those hidden sidecar files?

<---lashes non-moving horse repeatedly. 

Should sidecars always be hidden?

I'm not a big fan of hidden files (I tell my file browser to show them), but don't feel strongly about it.

[connersw]

I'm not sure about always.  Some may object to MC creating a bunch of files that they don't see.  Perhaps a check box option in General -> Importing & Tagging?

[flac.rules]

Again, why not use tagging on the files that support it? Many of the most normal video-files actually support tagging. I don't see any big point of hiding the sidecar-files.