We have a cleanup function that runs after a media library scan which prunes entries to files that no longer exist, which is good, but it leaves the entries in the related tables AUDIOTRACKS and SUBTRACKS. We should extend its functionality to include those and it might fix issues users have where their database keeps growing too big over time
@SubJunk While it should be obvious that the related tables should have the corresponding entries deleted, I doubt it will make much of a difference.
The only thing I can think off that can use any amount of "real size" in the database is the thumbnails.
Yeah the thumbnails are sometimes huge. We have reports on the forum of 6GB+ databases. Mine grew by 1.5GB when I added music folders to UMS which seems a bit excessive
Until this and possibly other bugs with database bloat are addressed, I think we should stop writing database migrations and just do it like we always did in the past - when the version gets bumped, start the database from scratch again. The "fully played" data will still remain, and the startup scan will repopulate the database nicely. @UniversalMediaServer/developers any objections?
I don't have any objections since there are so many other problems with the database structure. Ideally I'd say that for a user with a 6 GB database, having to recreate it should be a bad option as well, but I haven't really looked into what leads to the out of memory errors.
Cool. Yeah it's also high on my priority list to investigate and ideally reproduce the database bloating. I saw there was a database refactoring branch merged to DMS, would that be good to bring over here?
It might be, you should look closer at what it does. It doesn't really change much related to the "old" tables though (FILES, AUDIOTRACKS etc) so I doubt it would change the "bloat". What it does is to expand and improve the "Tables framework" and initialization.
@SubJunk There would also be some issues integrating this code, as it builds on other stuff that hasn't been merged in UMS. It would absolutely be possible to solve this, but it would take some coding. DMS for example has something called Services that handles "background stuff", and the new TableManager implemented in that PR runs as a Service under Services.
This has been implemented in https://github.com/UniversalMediaServer/UniversalMediaServer/pull/1528