Kodi does the automatic migration of the previous database into the new format that it currently supports, generating new tables and copying the data. If my understanding is correct, this process is triggered by the absence of the new tables in the database.
My question is, can this process be force-triggered manually in any way, e.g. is there an API function for it? If there was, I could maintain the database for multiple versions of Kodi (can't upgrade some players) in my network relatively painlessly.
What should always work is removing/dropping the "higher" database tables and then run the newer version of Kodi but (to me) this is not so easy doing it remotely and automatically so maybe some of you experts here now of a more direct way to accomplish this, only using Kodi.
(2020-10-19, 17:31)hello_world.c Wrote: [ -> ]If my understanding is correct, this process is triggered by the absence of the new tables in the database.
Yes, by checking on the latest numbering Kodi will upgrade the old database if necessary.
(2020-10-19, 17:31)hello_world.c Wrote: [ -> ]My question is, can this process be force-triggered manually in any way, e.g. is there an API function for it?
Not really, because any new functionality in the database is to be used by the corresponding Kodi version. You would get a "chicken vs egg" situation. Older Kodi versions don't know what the new schemas will be, and vice versa, the new database functionality cannot work with the old Kodi version. So what is the point of triggering an "update"? Not to mention that changing the layout of the database while Kodi is running is also not recommended.
(2020-10-19, 17:31)hello_world.c Wrote: [ -> ]What should always work is removing/dropping the "higher" database tables and then run the newer version of Kodi
Kodi always starts with a version check of the databases. Should it be necessary, an upgrade will follow.
(2020-10-19, 17:31)hello_world.c Wrote: [ -> ]but (to me) this is not so easy doing it remotely and automatically so maybe some of you experts here now of a more direct way to accomplish this, only using Kodi.
The only question remains then: why would you manually/remotely have to remove the newest database while Kodi is already using it?
(2020-10-19, 17:59)Klojum Wrote: [ -> ]
(2020-10-19, 17:31)hello_world.c Wrote: [ -> ]My question is, can this process be force-triggered manually in any way, e.g. is there an API function for it?
Not really, because any new functionality in the database is to be used by the corresponding Kodi version. You would get a "chicken vs egg" situation. Older Kodi versions don't know what the new schemas will be, and vice versa, the new database functionality cannot work with the old Kodi version. So what is the point of triggering an "update"? Not to mention that changing the layout of the database while Kodi is running is also not recommended.
This is for - slowly - migrating the network to new Kodi versions, so device-by-device, and not having to do it for all devices at once. Assume that I have two database versions that I need to maintain for two groups of devices, old and new. This is how this would work:
- The old database is the "master". New content is scanned into the database by devices running the old Kodi version exclusively. So all devices running the old version of Kodi are always covered.
- The new database is re-generated from the old database manually from time to time, using the upgrade procedure. No new Kodi is allowed to scan for new content and if they did, it would be discarded by the next manual re-generation. That way, new versions of Kodi get an updated database, too, eventually. I can control or at least verify which boxes are currently running, so pulling the database from running new version Kodi instances wouldn't be a problem in my case.
- When all instances of Kodi have been eventually upgraded, this procedure can go away and all new content is then scanned into the new database by new Kodi.
(2020-10-19, 17:59)Klojum Wrote: [ -> ] (2020-10-19, 17:31)hello_world.c Wrote: [ -> ]but (to me) this is not so easy doing it remotely and automatically so maybe some of you experts here now of a more direct way to accomplish this, only using Kodi.
The only question remains then: why would you manually/remotely have to remove the newest database while Kodi is already using it?
See above. If there really is no other way triggering this procedure than removing the new database tables followed by starting new Kodi to re-generate it, I may have to bite the bullet and just do that.
Or, do you know where in the source code of Kodi I can find the code that does it? It is likely to change for each version, but perhaps isolating that code and generating a tool or script to replicate that functionality may still be easier than messing with remotely manipulating the database.
It sounds like a problem waiting to happen, when you keep different Kodi versions in your network and in the shared database.
I'd suggest that you stick to the latest stable release for now, and upgrade only when the next stable release is available for all devices.
Older and newer database versions are not compatible, forward or backward.
Manually removing new databases so that they can be rebuild from the older database is not impossible. SQL commands can be executed from the command line. But there will be no smooth transition, it's a yes or no situation.
It's not something I would do, and I have several Kodi clients in my household. Some of which are starting to run Kodi 19 Matrix for testing only, not as a "production machine". My Kodi 18 setup will remain the basis for now.
(2020-10-19, 18:55)Klojum Wrote: [ -> ]It sounds like a problem waiting to happen, when you keep different Kodi versions in your network and in the shared database.
I'd suggest that you stick to the latest stable release for now, and upgrade only when the next stable release is available for all devices.
Older and newer database versions are not compatible, forward or backward.
Manually removing new databases so that they can be rebuild from the older database is not impossible. SQL commands can be executed from the command line. But there will be no smooth transition, it's a yes or no situation.
It's not something I would do, and I have several Kodi clients in my household. Some of which are starting to run Kodi 19 Matrix for testing only, not as a "production machine". My Kodi 18 setup will remain the basis for now.
Latest stable? I wish - most devices are still on Krypton and at least for two it is very unlikely that they can ever be upgraded, they just work too damn well under Kodi17 to be decomimssioned, though.
Yes, no smooth transition, I know, just something workable is what I am shooting at. There is also a lot more than just the library data that goes into the database that'll be lost on each rebuild for the new-Kodi devices, such as in-progress information, player settings for individual media etc. Still, having the new media show up on all devices is more important than that.