Page 1 of 1

Subsonic Database Is Enormous!

PostPosted: Thu Jul 20, 2017 8:21 am
by sunspot42
Hey, was trying to figure out why it was taking so long to copy my C:\subsonic folder from my old server to my new machine I'm going to run Subsonic on going forward (this appears to be the way to migrate Subsonic from one PC to another on Windows), when I realized the database is close to 400MB in size.

What the heck is in the database file and why would it be 400MB in size? Is there some way to compress this thing? Maybe a standard utility that can scan and repair these Java databases?

Re: Subsonic Database Is Enormous!

PostPosted: Thu Jul 20, 2017 1:37 pm
by Tak-MK
285MB in my case, yep, maybe it's too big? I don't know what's stored inside.

Re: Subsonic Database Is Enormous!

PostPosted: Thu Aug 31, 2017 9:47 pm
by sunspot42
Just curious if anybody knows why the database grows to be so ginormous?

Re: Subsonic Database Is Enormous!

PostPosted: Mon Oct 23, 2017 9:19 pm
by sunspot42
Database is still YUGE. Wondering if there's a solution for this. Thanks!

Re: Subsonic Database Is Enormous!

PostPosted: Tue Oct 24, 2017 8:22 pm
by G8DHE
Have you tried Settings ?
Clean-up database

Subsonic stores information about all media files ever encountered. By cleaning up the database, information about files that are no longer in your media collection is permanently removed.

Re: Subsonic Database Is Enormous!

PostPosted: Wed Nov 01, 2017 3:57 am
by tyral
sunspot42 wrote:Database is still YUGE. Wondering if there's a solution for this. Thanks!


The 'Clean up Database' link mentioned in the reply will likely work unless you haven't removed a lot of files from your subsonic setup. From your explanation I'm assuming that you're using the built-in DB and not MySQL. There's a pretty good chance that the built-in DB system (sqlite I think?) stores not only the data, but schema data for the database among other things normally stored in a separate 'schema' database with a true DB software (mariaDB, MySQL, etc.)

Unfortunately outside of scrapping the DB and rebuilding it to see if the size is different, there's no -easy- way to investigate why the DB is so large. You could jump into a software that can read and manipulate the DB, but you may end up breaking the DB itself if you make the wrong changes.