First of all, to check to make sure you did everything you could... Did you select the files in MC and do a manual Update Library From Tags? Or did you just try re-importing them with the Update for External Changes enabled? Because the former could work, while the latter might not.
The reason for the "safety" feature is actually quite sound (I remember the discussion with Matt MrC talked about in the other thread). Basically, there are two easy-to-think-of situations where this could lead to trouble:
1. Imagine a user has some other third-party application that creates MPL files on disk (for playlists, or metadata export, or whatever purpose). This application is lazy and spits out blank fields (rather than omitting the tag entirely) for fields which contain data it doesn't understand (maybe custom fields, or who knows what). If I remember right, Matt knew of such tools. Maybe it was something like tools that didn't support Unicode strings in fields, and would output blank values in MPLs for anything where it found unicode? Or some such nonsense (or perhaps I dreamed this part).
In any case, these dumb MPL files are sitting on disk in a user's auto-imported directories, and update for External Changes is enabled. MC happily obliterates metadata that should actually be there, because the MPL told them it should be blanked.
2. A user imports all of their tag-based metadata into MC. Then, because they are a minimalist crazy person, they intentionally "strip" all of their files of all of the metadata (removing all of the tags on purpose). Update for External Changes is on (as, I believe, it is by default) and Auto-Import is enabled, and whamo, they lose everything. Also, very bad.
I think this could be designed around, and that's part of the reason that I think maybe doing Update Library (from Tags) might work, where the Importing option might not. It is an explicit user-action, rather than an implicit one.
Anyhow, if that doesn't work, and you have a bunch of manually constructed Playlists you need to retain, I'm not sure what to suggest (other than to do the stripping in MC next time)... But, if you don't care about the playlists, and just want to preserve [Date Imported] and playstats, then I have a solution for you.
1. Find all of the affected files in MC, and add them to a particular Playlist.
2. Then intentionally break the links to these files inside MC (so that the MC record no longer points to the actual files on disk, and points elsewhere). The easiest way to do this will be to use
Rename, Move, and Copy tool in
Update Database Only mode.
If it happens that ALL of the files are of a particular type (say FLAC) then just change the extensions of the files using the Find & Replace feature of Rename, Move, and Copy to some "fake" extension (replace .flac with .broken or something). This will make the next step a bit easier.
3.
Get MCFileIngester and install it.
4.
If you were able to use my extension changing "trick" above, then do this version of Step 4. Open MCFileIngester and choose the following settings:
Source Type: Playlist
Source Playlist: Whatever playlist you made in step 1.
Mode: Change Extension
New File Extension: flac (or whatever file type the files actually are on disk, the real, pre-broken type)
Type: Clone
Only clone playstats: Enabled
Then run the ingester. This will import the real flac versions (which actually exist on disk, since they have matching filenames and are still called .flac instead of .broken) fresh into MC, and then clone over the Playstats, Date Imported, Rating, and other similar "generated by MC" fields. Regular fields and any custom fields will be left alone (you can look at
my MCFileIngester instruction post for the full list of which fields are included in that mode).
4.
If your original files were of a variety of different extensions, you can't do that clever trick. In this case, you'll have to import the original files yourself. You can still break the links by changing them somehow generic like inserting a fake /Broken/ directory into the filename with Rename, Move, and Copy in Update Database Only mode. But then you need to:
a. Import the "real" files still remaining on disk. These will import fresh, because MC doesn't consider the files removed, but still ingested and yet broken.
b. Add all of these files to a different Playlist.
It is essential that the order of the files in both playlists match exactly. You might want to try this with just a few before you do a bunch, to see how it works. And make a Library Backup first, please.
c. Open MCFileIngester and use the following settings
Source Type: Playlist
Source Playlist: the "old files" list you made in Step 1 above.
New Playlist: the list containing the newly reimported files you made in step 4b.
Mode: Standard
Type: Clone
Only clone playstats: Enabled
See the other Step 4 above for a description of the Only clone playstats feature. This method will systematically go through and match File #1 in the Source Playlist, and clone the playstats over to the newly imported files in the New playlist, then File #2, then File #3, and so on and so forth. That's why it is absolutely essential that the order of files matches identically between the Source and New Playlists (and that no files are omitted or mismatched). Otherwise it'll happily clone to whatever item happens to match on the "other side".
This works. I tested with my Test Library just now. If you try to use MCFileIngester in single-file mode, it checks that both paths exist. But in Playlist Mode, it just trusts MC's Playlist and uses those (it makes sure the MC File Record in question exists, but doesn't care if the file itself exists in Playlist mode).
This won't preserve Playlists though, so it may be useless to you.