Favourites.uhe-fav saves relative path, but changing absolute path loses favourite status

[AtomOfScent]

It's pretty frustrating that if you re-organize your preset directory structure any moved presets irreparably lose their favourite status which may have taken significant time to curate.

The Favourites.uhe-fav file saves the relative path i.e. /Local/, and as none the preset metadata has been changed there's no reason it should lose favourite designation. Same filename, same author, same bank name etc. so why not the same status?

Restoring to the previous location doesn't fix the favourite status. Even using external drag & drop which the manual acknowledges as "more comfortable" has the same result, but this very important drawback doesn't appear to be mentioned.

I can't imagine any situation where this is desirable.
At least with Favourites.db.txt this could be manually fixed with simple find & replace in a text editor.

[Fannon]

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).

[tasmaniandevil]

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.

Exporting the favourites and then importing the .uhe-fav file after rearranging the presets won't help here, as presets are referenced by preset name AND relative preset location. If the location doesn't match anymore, the favourite cannot be assigned.

That's because 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.

[AtomOfScent]

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.

Code: Select all

"db_path": "/Local/Howard Scarr Performer Soundset",
"extension": ".h2p",
"name": "HS Amnesia Poly2"

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.

Code: Select all

"db_path": "/Local/Howard Scarr Performer Soundset",
"extension": ".h2p",
"name": "HS Amnesia Poly2"
"modified": "xx/xx/xxxx [store full timestamp if necessary]"

[tasmaniandevil]

... and support importing it on other computers, without the same absolute path ....

That's already possible, you can easily migrate your favourites from Mac to Win to Linux, as long as the relative paths are identical on each machine.

[AtomOfScent]

... and support importing it on other computers, without the same absolute path ....

That's already possible, you can easily migrate your favourites from Mac to Win to Linux, as long as the relative paths are identical on each machine.

Glad to hear that. I haven't tried, I just assumed with issues I've been having that identical locations in the manual referred to fsPath not dbPath.

Note: Importing .uhe-fav files from another computer will only work 100% correctly if all preset names and locations are identical on both computers!

My plan to try restoring my favourites is to edit the old uhe-fav file so that the db_path entries match the current dbPath in the database.

Can you clarify what will happen after I try to import that? How will it affect my existing favourites? Will they be retained and new entries added, or completely wiped and replaced by the entries in the uhe-fav file I'm importing?

Aside from hoping not to worsen things, I'd like to get a scope of the task and whether I will need merge my current and old uhe-fav files...

Thanks in advance!

[tasmaniandevil]

When you import the favourites, the plugin will ask you if you want to merge them or replace the existing favourites with the new favourites.

But in any case, maybe first export the currently existing favourites before attempting to merge them with your manually edited favourites file. Just so you have a backup in case things don't work out as planned.

[AtomOfScent]

When you import the favourites, the plugin will ask you if you want to merge them or replace the existing favourites with the new favourites.

But in any case, maybe first export the currently existing favourites before attempting to merge them with your manually edited favourites file. Just so you have a backup in case things don't work out as planned.

Good to know. I'll definitely be sure to back them up.

I was going to try a fully automated approach but parsing and extracting SQL was giving me some trouble. Instead I just extracted every unique path from the fav file and will use old school replace all with the current db paths.

Before importing I'll split in into individual files for fav 1-8 to more easily troubleshoot any issues.

Since I only exported a uhe-fave file for Diva, I guess my only hope is using my online backup history to find a copy of the db before the favourites were deleted, restore my old file structure, replace the current db, and pray the faves are restored.

[tasmaniandevil]

Before importing I'll split in into individual files for fav 1-8 to more easily troubleshoot any issues.

Btw, for the future, you can also export and import individual favourites.
Just Shift-drag and drop the individual favourite smart folder (the numbered ones) instead of the main favourites smart folder.