u-he • Re: Favourites.uhe-fav saves relative path, but changing absolute path loses favourite status

The favorite status in the DB should be kept, right? It's just that the paths in the uhe-fav files doesn't match anymore.
I think you can also fix those with a text editor, as it's just JSON. Each entry consists of a "db_path" and a "name". If you move, the name stays the same, but you can have multiple presets with the same name in different folders.
So you need to know how to search & replace the db_path correctly.

In theory, a script could try to figure it out by filename only, but that may not always work out (as it can give you several results).

Thanks for the tips. Favourite status in the db is deleted by the sound of it.
I installed an SQL extension for VSCode so I can read the db, but I can't see where the status is indicated. Theres a favDump table, but it's empty.

The best solution would likely be modifying the uhe-fav file local paths to match those in the db and import. I'd expect it to ADD entries it finds, but I'm not confident it won't just wipe and replace the rest of my current entries so I'd want to backup the current one first, and possibly have to merge the 2 carefully with a script if importing removes existing favourites..

If you move presets around directly inside the preset browser by using drag and drop, then they retain their favourite status.

If you however use your operating system's file system to move presets around, then the database won't be able to keep those. It checks for changes, finds that some presets are no longer where they were, so it removes the reference to the favourite status in order to avoid getting bloated over time.

I appreciate the clarification.
This should really be mentioned in the manual. The preset browser doesn't support simple tasks like selecting multiple folders so using the OS is much easier.

After folders are moved the last part(s) of both the dbPath and fsPath will often be unchanged, and the existing entries could be modified. If in doubt ask during the re-scan "Attempt to repair db paths for relocated folders?" Even if none of the path matches, the filename and any other metadata will.

This doesn't need to be done for every file, it only needs to be done for ones which would otherwise have their favourite or junk status deleted.

Immediately removing the favourite status with no db backup or other way to recover the status even if the original path is restored seems like the worst option. The size of a db backup even with 50K presets would still be smaller than an individual preset for some other synths (not to mention 50GB Kontakt libraries etc.)

I'd rather manually de-bloat the database (Remove 736 orphaned favourites from the db? OK/Cancel), or be asked to do it every x weeks. Any computer powerful enough to run Diva should be able to handle reading a relatively small database, especially when there will already be huge differences in db size between users.

...you could theoretically have identically named presets in multiple folders, and the plugin then cannot know which of these it should assign the favourite status to.

In this circumstance the direct parent folder(s) never changed. If someone has 2 presets named "HS Amnesia Poly2", using the one in "*/Howard Scarr Performer Soundset" seems like the obvious choice.

Even without using pattern matching, a few extra files with duplicate names gaining status is much preferable to losing favourite status for potentially many hundreds of presets.

Storing the modified date as a field in uhe-fav could largely address the duplicate issue, and support importing it on other computers, without the same absolute path as the file modification dates would still match.

The chances of different (non-duplicate) presets having the identical file name and identical file modified date is basically zero and none of those things change when the parent folder is renamed or moved.

i.e.

Statistics: Posted by AtomOfScent — Wed May 22, 2024 2:41 am

---