Local Provider, App Data, ect

Discussion
1

Had a few questions about the local Provider and the app data.

  1. let’s say i have a file named (x), and i delete it, would i regain the data again if i get a different file with the same name? do i need to back up first & restore after?

  2. so all my files are in a certain big folder, if i move my files to a new folder, would i lose my app data?

  3. what are the things not to do to not lose the app data? because recently i batch renamed all my files and lost all the data i had which was unfortunate, so i want to be as secure as possible. i would highly be appreciated.

and sorry if my questions were obvious :folded_hands:t4:

2

For local provider the key is the filepath.

So if you rename or move the file the data is lost.

You can backup the data, edit the user_data.json with search and replace and restore the data if you move all to another folder.

3

I’ve an issue with user_data.json, which is unfortunately heavily incomplete for me, exposing not even 1/100 of my library, since it only exports tracks with any of playCount|lastSkipped|resumePoint|etc > 0 or not null.
Is it currently possible with Symfonium to export the entire music database from all providers?

4

Hi, I have a follow-up question about editing user_data.json after file paths change.

After moving files and rescanning, the tracks already exist in Symfonium at their new paths, but some play counts and last-played values were reset. If I edit a fresh post-rescan backup to restore those values and update the old paths in listening history, then restore it, will Symfonium overwrite the user data of those already existing tracks? Does the same apply to album and artist play counts?

A previous backup import did not appear to update data for tracks already present. Is there a restore option or recommended procedure that updates these entries without replacing unrelated, newer listening activity? I have not attempted the restore in this case yet.

5

I am not the dev so take my answer with a grain of salt. It was easy enough to test, so here’s my findings:

Yes, anything with data stored in the backup will be overwritten by said data. So if…

  • a track is currently scanned at location /path/to/track
    • this track currently has Play Count = 2
  • your backup includes a matching /path/to/track
    • the backup says this track has Play Count = 1

Then restoring the backup will overwrite the existing data, and set that track back to Play Count = 1, as per the backup

Album and Artist play counts don’t seem to be stored in the backup. They are calculated directly from the relevant track counts when the library is scanned.

Note that there are settings to control how this is calculated at:

Settings → Advanced → Database →

  • Only update play counts for track artists
  • Album play count mode

This means the /path/to/track in the backup did not match the path for the currently existing file.

Note that any tracks without user data (i.e. zero for all of play count, skip count, etc.) are not included in the backup by default, and thus will not reset those values to zero.

If you enabled the “All media entries” sub-option when backing up your user data, then those zero-valued tracks will be saved in the backup and thus will overwrite values for existing tracks with zeroes.

The simplest thing I can think of is to make sure the user data that you are restoring includes only data for tracks that you want to update.

Since you are editing the paths in the old backup, remember that only paths which match your new files will have any effect.

So if /new/path/track2 has data you don’t want to overwrite, you can either:

  • delete the section in the backup for /new/path/track2
  • or simply don’t update the path for that entry.
    Since the current data is for /new/path/track2 it will be unaffected by restoring /old/path/track2

Now if you want a sure-fire way of affecting only the tracks you want, I can think of a more complicated way of doing it:

Expand

Make sure to have a backup of your present data.

Basically you want to remove any tracks from your library that you don’t want to edit values for, restore the edited old backup, make a new backup which will contain only the present tracks, then restore that new backup over your present data.

Step by step:

  • make a backup of your current user data
    • this is our “present backup”
  • copy all of the files that you do want to edit values for to a separate location
    • this is our “work folder”
    • you could also remove all of the files that you aren’t updating, whichever is easier
  • edit your “Local device” media provider to contain only the “work folder” and let the app scan the library
    • this will remove user data for all tracks that are no longer present in the library! Make sure you have your backup from Step 1!
  • edit your old backup so that the paths match our “work folder”
  • restore this edited backup to update the values
  • make a new backup of this user data
    • this is our “trimmed backup”
  • return all media to the desired final location
  • restore the “present backup”
    • at this point, your user data should be exactly like it was before we started
  • if needed, edit the “trimmed backup” to match your new paths
  • restore user data from the “trimmed backup”

Since the trimmed backup contains only user data for files that you intended to update, only values for those tracks can be affected. Everything else keeps the values from your “present backup”.

Goes without saying, but be sure to make a new backup before restoring your edited one. If something didn’t work right, you can always restore the newest one to restore the current values and try again.

6

Thanks, @Celorien, for taking the time to test this. I followed up with a series of backups and restores on my own library. My provider is WebDAV, so these are observations from that setup rather than a guarantee for the Local device provider.

After renaming files and rescanning, some tracks existed at their new paths but had lost their play counts and last-played values. I edited a fresh post-rescan backup and restored only User data. Targeted entries whose paths matched the existing tracks were updated. I also found song, album and artist user-data entries, including play counts, in my backup; targeted restores updated those values in my case. Unrelated user-data rows remained unchanged in the subsequent exports.

Detailed playback history behaved differently: importing a corrected event added it rather than replacing the event at its old path. A one-event test left the old event in place and created a duplicate at the corrected path. So editing history paths and simply restoring the backup was not sufficient.

To repair the history, I made and retained a full backup, prepared a history-only backup with the old paths mapped to current tracks, and checked its contents before using it. In Symfonium I used Settings → Advanced → Clear detailed playback history, whose description says it keeps play and skip counts. A full backup immediately afterward confirmed that detailed history was empty while song, album, artist and genre user data were unchanged. I then restored the prepared backup with only User data selected.

The final export contained my expected 11,476 distinct listening events, with no missing or extra events, no duplicate events and no references to the retired paths. Symfonium assigned new event IDs, so I compared the events by track path, time, played/skipped status and duration instead. The other user-data rows still matched the pre-clear backup.

This was a carefully checked recovery, not a general recommendation to clear history as a first step. In particular, an ordinary backup restore did not remove the duplicate history event in my test. I kept the original full backups and avoided new playback between the backup, clear and restore steps.

Thanks again. Your answer helped us find the working route, and I hope these observations help someone facing the same path-change problem.

1 Like