Networked drive > bulk field remove > odd freeze up and more

First off, thanks for building this little gem!!

I just installed v 3.11 on Win10

I have media files on a NAS drive which I have created a mapped volume on the desktop.

I have been running quick actions to remove fields from MP4 and MKV files. It appears to me that the app thinks it's clearing out the fields but every now and then it gets stuck sitting at "Removing tag data....x of xx".

It eventually moves to the next one but sometimes gets stuck there too. Right now I have 27 files selected and it got stuck on 3, 12 and 13 for about 1-2 minutes per tag. It eventually completes but the display still shows all the tag entries for all the files shown and that were selected.

It's as if it cannot edit the files for some reason and simply times out. But oddly enough, not all tags being removed show the delay/lag issue. Tags 1, 2, 4-11 were all almost immediately processed.

I have run the app both under my user account (admin level) as well as 'run as admin' in Win10. The NAS has the same user/password account on it and I can manage all files in WinExplorer without any issues.

Any ideas? I didn't find anything similar on this forum nor in the FAQ area.

A.

It's probably the size of the files that's the issue. Mp3tag needs to rewrite the whole file in some cases, which can take some time when the files are on a NAS.

In the cases where it's almost instant, some reserved space inside of the file (padding) can be used to perform the change — this is why subsequent changes are often quite fast.

Does this sound plausible for your case?

Wow, so the entire file needs to be re-written?

Is that something specific about MP4/MKV files?

I've used MediaMonkey for MP3s for years (before I knew of this app) and it is pretty much instantaneous mind you, they are MP3 files so maybe I never noticed.

I thought meta data was simply header fields that apps could modify as needed

thx,

A.

Yes, it depends on the tag format. Even for MP3 with ID3v2 you might end up with a rewritten file — because it's in the header. If you store a 500KB cover there, and only 4KB are available as padding, the file needs to be rewritten.

This is naturally faster for smaller files, in your case it seems you're working with video files which are often quite large.

What I am trying to do is clear out all metadata from the video files. Some media management (Plex) will take the metadata info and ignore downloaded meta for titles etc. It's a pain in the butt.

Should removing the data be faster? I understand your example, adding a cover would increase the total file size, which makes sense.

Do you know of any other way to achieve this without the re-write step?

If you're unsure about if Mp3tag is doing something at all during those perceived freeze ups, you could use the task manager (or Process Explorer from Sysinternals) to inspect what's going on.

If I'd undergo such a one-time task of reworking all those files, I'd probably copy them to a fast external SDD and perform the changes there.