More > JRiver Media Center 21 for Windows

Video files missing after large tag update

<< < (4/7) > >>

RoderickGI:
The blank [Filename] field with multiple, or all, files selected sounds like a plausible cause.

Maybe a user shouldn't be allowed to edit the [Filename] tag if more than one file is selected, unless an expression is being used, and that expression is validated in some way to provide unique results.

I have edited the [Filename] field directly a few times, carefully, and was surprised at how powerful doing just that can be, since it renames the actual file.

Perhaps all of the [Filename], [Filename (name)], and [Filename (path)] fields should have an extra warning popup when they are edited directly. Except of course;

--- Quote from: crisnee on November 17, 2015, 12:45:53 am ---All these annoying safety questions that can't be turned off every time I do some little thing, but when it really counts MC just irrevocably deletes many giga bytes of updated files in a split second with no notice or safeguard at all.
--- End quote ---

glynor:
I think a more likely cause for the OP's issue is that the files were deleted somehow externally (by something outside of and unrelated to MC) and then when MC opened and tried to use the files, Auto-Import with Fix Broken Links would immediately remove all the files.

That would explain the instantaneous nature of the issue. Auto-Import would eventually have found the files missing, and removed them, but trying to update all of the tags would "cause it to notice" (because otherwise it only responds to changes it sees happen on the filesystem, and scans periodically).  Removing broken liks from the database is lickety-split quick, even for 10s of thousands.

But, perhaps not... If somehow you edited the [Filename] tag with all files selected, and made it blank, and didn't watch (or waited for the changes to finish) you could cause havoc.

crisnee:
In my case, the only thing I did with this particular batch of files (all my video files scattered across several directories--sidecar files and jpgs in directory concerned were also deleted) was rebuild thumbnails. I'd done something to some of the files but not all earlier, but all were deleted.

Chris

crisnee:
Well, thank-you. Simultaneous changes I think.

Chris

glynor:
In another unrelated thread, cncb brought this up:


--- Quote from: cncb on November 17, 2015, 07:42:41 pm ---Another strange thing I found while testing this is that when you edit a field in the Tag Window with no files selected, the change is applied to all files in the list?  This does not seem right to me at all.  In my opinion, if nothing is selected then the Tag Window should be disabled.

--- End quote ---

I replied...


--- Quote from: glynor on November 17, 2015, 07:56:09 pm ---This is correct.  I think it is to allow you to speedily mass-edit tags. So, for example, to apply a tag to an entire artist worth of files, you can just select the pane in question (then all files are, in effect, selected) and change something in the Tag AW.

But, I agree, it is dangerous, and probably not worth the tradeoff if it is that way on purpose (and it has been that way a long, long time, as long as I can remember).  In fact, it could be related to this:
https://yabb.jriver.com/interact/index.php?topic=101408.0

--- End quote ---

Back when I deleted everything (or started, but caught it and stopped it before it finished), it may have been related to the everything is selected when nothing is selected functionality of the Tag AW. Like this:

1. Accidentally get focus on the [Filename] field, not understanding where the cursor is...
2. Hit the spacebar trying to start playback...
3. And then (confused when spacebar doesn't work) maybe hit the Enter key...

And whammo, your whole Library, deleted.

I agree, the Tag AW should be read-only until at least one file is actually selected. Not disabled, mind you (because it is useful for informational purposes), just read-only. This would match the behavior of the tagging checkboxes in the panes, and is much, much safer.

Navigation

[0] Message Index

[#] Next page

[*] Previous page