v1.3.0 vha file corruption

[cal2195]

I've actually just found that my v1.3.0 vha file has become corrupted some how - the image id's are wrong for quite a few files, resulting in incorrect thumbnails and files matched to file names. I am not sure why this has happened, although I did do a lot of rescanning with the same folder and using different devices.

Possibly has to do with saving the last thumbnail id, and reading it back in, or when saving out the vha file again. More investigation is needed, but this may impact #10.

[whyboris]

Just to be clear -- this is while working with the new codebase that involves file hashes to identify the files - not by using the 1.3.0 app normally, right? 🙆‍♂️

I'll keep an eye out on this, though I suspect the best recommendation during the upgrade for end users would be to just offer them a notification that says "this is an old format file, you'll have to re-scan everything".

Just so you're aware, one bit of functionality is that if you ever rename a file from within the app, or add/remove a "tag", on app exit, the app re-saves the entire .vha file. Could this have been one of the actions you tried?

[cal2195]

Nope, this is using v1.3.0 as it should be!

I did try out those actions, so possibly some combination messes up the mapping from files to IDs and then saves them incorrectly?

[whyboris]

Well -- good thing that you've upgraded the internal file identification system 😅

[whyboris]

Oh yeah -- if you switch from one hub to another (open another vha file) after having changed tags or renamed a file, the re-saving of the vha should happen as well 👌

[whyboris]

I think it's safe to close -- the new master and the upcoming version 2.0.0 will have hashes (thank you Cal for implementing those 🥇 !) - it should certainly fix the underlying problem.