Print

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

[mwillems]

Not sure if this is a bug or if this is functioning as intended, but I wanted to ask.

When you use the "Rename" subfunction of "Rename, Move, & Copy Files" on a video file, JRiver renames or moves the video file and any other associated files in the directory (i.e. the sidecar and the associated image).  This is ideal (from my perspective) as it keeps the tags with the file, leaves no orphans, etc.

However, when you use the "Copy and Update Database to Point to a New Location" subfunction on a video file, JRiver copies the video file, but does not appear to be copying any associated files.  

This seems anomalous to me: this specific sub-function points the library to the newly copied file, so you'd expect that the sidecar or other library created files would also be copied. There may be some reason I'm not thinking of why this behavior would be undesirable?

I'm attempting to use the function as part of a workflow that creates fully redundant data, so my ideal behavior would be:
1) All ancillary files copy over with the main file, and
2) Are not removed from their original location.
(i.e. full copy of the main file and any helper files).

[Matt]

The issue is that the copy is just a copy, but the move is a database move which also looks at sidecars.

I suppose the copy could be expanded using the same code that's in the database, but it's pretty complicated.

[mwillems]

The issue is that the copy is just a copy, but the move is a database move which also looks at sidecars.

I suppose the copy could be expanded using the same code that's in the database, but it's pretty complicated.

I think it makes sense not to copy everything for the regular copy function (as you say, it's just a copy), but the "copy and update" function not only copies, but also does a database change.  

"Copy and update the database" changes the library to point at the new copy, but the sidecar doesn't follow, which seems odd because as far as the library is concerned the file now "lives" in the new location, but has lost its sidecar.  When I tried the function, the files in the new location lost all metadata because the sidecar didn't follow, so the library treated them as newly imported files (although not always immediately, I think autoimport may have a role in that).  

It's not a major issue for me, I can definitely work around it now that I know about it.  I just wanted to mention it because it seems like unexpected behavior that might catch someone by surprise.

[fitbrit]

I think it makes sense not to copy everything for the regular copy function (as you say, it's just a copy), but the "copy and update" function not only copies, but also does a database change.  

+1

[glynor]

There are some other problems buried in here too.

Right now, when MC does copy over sidecar files, if there are already existing sidecar files in the way (which sometimes, such as with cover art, just happens even if the destination directory is completely empty at the start) you get repeated OS "are you sure" dialogs... Over, and over, and over.  I've personally clicked through HUNDREDS of these, just to tell it to overwrite Sidecar XML files that it was creating itself.

And, the fact that (if you hit one of these issues) there's no way to cancel out or say "overwrite all".  You have to do them one-at-a-time.