Kodi Community Forum

Full Version: Keeping Playcount Data Between Kodi Upgrades
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
While Kodi will upgrade older music libraries when a new version is installed, it does not rescan the music files. Hence it will not take notice of music file tags that have already been in the files but not processed by earlier versions of Kodi. Library update first checks that the files have changed (timesamp or size) before trying to rescan.

This leaves two ways to get Kodi to notice those tags
a) "touch" all your music files in some way so Kodi does rescan then on "update library".
b) Drop the music source and add in again.

Approach b) is simple, but it wipes all your playcount data, and any additional artist or album info and artwork scraped from online sources. You can rescrape of course, but that takes time and hits the servers with extra traffic.

Then there is using import/export to/from xml as a single file. This can be used to avoid rescraping, but not so sure what it does with playcounts.

So anyone got any strategies they would like to share for keeping the playcounts?

It may seem strange for me of all people to be asking this, but I don't update my family seutp very often and in testing, where I wipe library often, the persistence of playcount doesn't matter to me much. Also because of testing I have often "touched" my music files in some way.

But with v17 release getting closer, and the lots of new tag processing it has, I am looking for a way to make accessing those new features as pianless for users as possible.
I don't think the export database for music does playcount, and more importantly I think export is only at the album level, so not good for people who primarily listen to songs or playlists rather than albums.

I'm afraid I don't have a painless strategy. I do have a painful one, which is quicker to do than to explain, though I imagine it breaks every rule of Kodi. My work around for these things is:
1. Open old database in sqlitebroswser
2. Export song table as a csv
3. Open new style database and export song table as a csv
4. Using your spreadsheet program open Do a vlookup on a unique field to populate the new table's Times Played and Date Played columns from the old table.
5. Import the new table csv as song_new to the database
6. Rename the existing song table in the database to song_old and rename your newly imported song_new to just song
7. Delete song_old and write changes to database.
Now who could possibly not follow that? Some Kodi programmers are probably screaming not to do this as well.
I'm sure someone else has a better idea, but for accountants the above method is quite easy.
Manipulating the database directly is possibly the only way to keep play-counts and date played because as WelshPaul says, the export (certainly to a single file) does not contain that information.
Thanks for input guys, you are of course quite right about import/export - what was I thinking!

Direct data manipulation is the route I could take, but way beyond many users.

I haven't tried it, but emptying the strHash field of the Path table should also cause Kodi to rescan all the music files on library update, gathering all tag data but not overwriting the playcount.

Of course what we need is a nice user friendly way to get Kodi on special ocassions to recscan tags from music file even when the hash values match.

Longer term persistence of user data e.g. playcount, lastplayed etc. could be addressed in a variety of ways, as well as holding these values per user profile rather than per song. But that is not for v17,
Possibly a role for metadata sites to store that info in the cloud...

But personally when I upgrade versions, I always do a rescan.
My only interest in playcount/lastplayed is to spot those items in my large collection that I have forgotten about Smile
Like all my personal data I have no desire to put that on the cloud (old dog and control freak - not trust this modern cloud stuff!)

The difficulty is how best to let users see the new version of Kodi using the tag data that has been in their files all along. It will only do this if the tags are actually scanned (not just a hash check).

We have
c) manipulate data manually....

I can confirm that emptying the strHash field of the Path table causes Kodi to rescan all the music files on library update, gathering all tag data but not overwriting the playcount or last played data. That is a change that can be done with a single SQL statement, but it is stil not nice to expect users to be able to do that.

But I am left wondering if Kodi already has a hidden but more elegant way to do this. I guess I just need to do some more digging.

Edit:
It seems that we can force it to rescan given an earlier database version using SetMusicNeedsUpdate and GetMusicNeedsUpdate https://github.com/xbmc/xbmc/blob/master....cpp#L1307

Any reason not to do that? Somehow, for those with big libraries, I would prefer that it was at the user's bidding than automatic the first time they use after upgrade.