[Sesshoumaru]

Hi @ all

I migrated my old mediacenter to a new system and took the liberty to also centralize the DB to mySQL on that occation.
So I exported the video library on the source system and imported it on the target system, which had been configured to use mySQL. I could watch the database filling up slowly (250MB in the end).

However, the fanart is not showing up on the new system and for some shows the "watched" status is lost.
Upon inspection of the SQL database I saw the URL for the art work as follows (also inside the local texture.db):
==> D:\Backup\vdb\kodi_videodb_2023-05-26\movies

This seems bogus to me. Thats the path from where the backup came (USB drive) which obviously is going to be removed after the backup.
That yields several questions. Where is the fanart supposed to be on a system using mySQL, which folder path would be expected? And how to fix this problem?
Side note: I have some files which are not scanned into the DB (some anime seasons) which still had a watch status, they seem to be all culled. I would have thought this is stored in the files table and independent from the actual scaned the data into the library. Am I wrong?

Best Regards, insightful help would be appreciated.

[izprtxqkft]

when decentralizing kodi, most people will setup kodi with a sharing path either nfs or smb instead of like you did with a local path "D:\"

that way kodi is actually decentralized and not just migrated to a different database


when scanning in your library from D:\ it found artwork in your movie path on D:\ and thats what got added to the database

as far as textures/thumbnails - these can be treated as temporary and deleted without impact - see here https://kodi.wiki/view/Artwork/Cache


you should be able to locate a search/replace operation for your new database to replace your current paths in their respective places for the entries outside of textures
this is a little more advanced than i wish to get in to here as modifying the database directly is generally frowned on and should only be attempted by experienced users

[Sesshoumaru]

Yes, I used my maniac SQL skills to correct the paths in both, the remote SQL Table and in Texture13.db - artwork is back.
The artwork folder is synced to a next-cloud local storage - my library is to big to have troubles. But I think I get it ... it would have been expected to put the backup on a central location on a SMB/NFS share and import from there, so that everybody would have the same path. Gotch'a.

One last stupid question. Texture13.db and the 'art' table in the centralized SQL database seem totaly redundant. Double data management seems a bad idea. Or is the local one not used?

[izprtxqkft]

Yes, I used my maniac SQL skills to correct the paths in both, the remote SQL Table and in Texture13.db - artwork is back.

right on
 

The artwork folder is synced to a next-cloud local storage - my library is to big to have troubles. But I think I get it ... it would have been expected to put the backup on a central location on a SMB/NFS share and import from there, so that everybody would have the same path. Gotch'a.

precisely
 

One last stupid question. Texture13.db and the 'art' table in the centralized SQL database seem totaly redundant. Double data management seems a bad idea. Or is the local one not used?

textures tracks the thumbnail cache, if an image is requested to display in kodi it will check artwork and textures, in the event it is not cached it will create a new cached copy from artwork in myvideos and then link that new copy to the textures db

yes its redundant and i personally dont prefer it but i think its grandfathered in from a time when devices were slow with low memory - only speculation on the last part

[Sesshoumaru]

Thanks for the insights.
Yes, I see now that the Texture13.db connects the artwork path to the hashed thumbnail. Now I understand what it does.

Yep, I guess the centralized SQL has not yet a big fanbase. Ideally the Texture13.db should not use the artwork path but have a reference to the art_id here which is managed by the central SQL database.
Now it get plausible why you have to delete the thumb cache AND the Texture DB if something goes wrong. Probably a remenant of olden times.

I hope the central database will get some love in the future. I did setup a MariaDB on my Proxmox Cluster to run it.
I mean why not getting rid of the redundant code and use the database approach all the time. The install process would "just" install SQLite as part of Kodi Setup and done deal. Multiple code paths to do things are not good. And I say that as somebody who sometimes codes like this as well