More > JRiver Media Center 21 for Windows

Video files missing after large tag update

<< < (5/7) > >>

cncb:

--- Quote from: glynor on November 17, 2015, 07:56:09 pm ---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.

--- End quote ---

I say disabled because I had a situation a while ago where this presented a problem.  I had a complicated calculated expression field in the Tag Window that would parse the Keywords field with several list operations.  When I would open a view with several thousand files, MC would appear locked up for several seconds because presumably it was calculating the expression for every file.

glynor:
I don't think you can disable it because of that kind of edge case. It is a valuable display. I keep it open often for expressly this purpose (to look for Varies in a field that should have a value, for example).

Read-only makes sense. Disabled breaks things.

glynor:

--- Quote from: RoderickGI on November 17, 2015, 06:45:35 pm ---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.

--- End quote ---

I don't think you can do this.

First off, I've used direct editing the [Filename] tag more than once to solve problems. In fact, that's exactly how RMCF works. In Rename mode, it is basically just a specialized tool for mass-editing the [Filename] tag.

The expression engine can't really distinguish between plain-text entry and an "expression".  They both output a plain text string.  An "expression" is just some text that happens to contain special function() identifiers that are parsed out and replaced inline with the resulting text. Everything you enter is an "expression". Just some of them don't contain any functions (and so are then passed through verbatim). And, by the time the "tagging" step happens, the expression has already been parsed, and it just gets plain text.

So... Not that, but I agree something should be done to protect [Filename] changes from invalid changes. At the very least, check to see if the entry was only whitespace. That's obviously bad and deletes the files!  Better would be to also do some basic sanity checks to see if it can resolve to a filesystem location. For example, the result must begin with one of:

* <letter>:\
* \\
* / (on POSIX platforms)

I don't know if MC for Mac can resolve smb:// style names, but maybe include those too if so.

glynor:
Well, I discovered more. It isn't just whitespace, and they aren't actually deleted (it is still a calamity though).

If you edit [Filename] and type any "invalid" filename, it goes kablooie. I just tested this:

1. Select a MP3 file (after making a backup copy).
2. Edit the [Filename] tag, and typed: cheetos.mp3
3. Hit enter.

The file vanished and went to nowhere. But, then I found it.

I ran search on the whole computer for cheetos.mp3 and low and behold, after a long time, it found it. Here:
C:\Users\glynor\AppData\Local\Temp\7zSE4D2.tmp

And, inside that folder? I had the cheetos.mp3 file. And, the album I previously "deleted" (earlier tonight) by clearing the [Filename] tag! Those files were there too! They still had their original filenames, but, of course, they'd lost their folder structure. So if you did it to a big swath of files, you'd be deeply and seriously hosed. But, they aren't gone, just moved to temp.

Of course, then your temp folder can get cleared out. MC doesn't seem to clear those itself (or not right away) as I closed and re-opened MC and they're still sitting there. But, maintenance processes certainly will clean them out eventually.

You might want to check through your AppData temp folder, to see if you have a bunch of "deleted" video files in there sucking up space. That would be a telltale sign too, of this issue.

crisnee:
I checked my Appdata folder and everywhere else and was not able to come up with any errant video files.

Chris

Navigation

[0] Message Index

[#] Next page

[*] Previous page