Database file size

[adrian]

Hello,
I'm using Mezzmo for a few months now, mainly because it was one of the few apps able to stream external SRT files to playback devices. However I have a huge complaint to file for the developers of this UPnP server: the database file that it creates and uses, Mezzmo.db, grows to unhuman proprotions uselessly.
Let me illustrate what I'm trying to say:
With a library of just 400 video files, the library is taking up 3.5 GIGAbytes. That's around 3500 megabytes of space, for just a few hundred movies. Now imagine having 3000 movies, and maybe some 20.000 songs. I would need to have a dedicated HDD just for the database file Mezzmo is using, it would easily reach 1 TB or more.

Now, being a programmer myself, I decided to take some actions about this ever since I was suspicious when it hit 1 GB in size for just 50 media files. So I did what any developer would do: started digging through the database using a SQLite database manager, so here's what I immediately detected:

- THUMBNAILS are being cloned into the thumbnails table for each playlist that contains a file for that thumbnail, and also for any other file that has the same thumbnail. So, for example, if we have movie which has a thumbnail image that takes 300 kilobytes, and that movie is the thumbnail of 30 playlists (including automatically generated playlists), then it will eat 10 MB of space, instead of just 300 kB. This takes like 95% of the DB space.
- ALL playlists are being stored in the database. This includes automatic playlists. This is stupid, since those are dynamic and should be created on-the-fly, in-memory, at runtime. Also these consume thumbnail storage since they require thumbnails...
- dead entries for a lot of stuff, including playlists. I observed this in the GUI too: when I delete a playlist, I sometimes end-up with ghost entries, or sub-items that no longer have a node parent.

So, what I did after this: wrote myself a nice PHP script to "clean" this database in the following way:

- redundant thumbnails are being completely deleted and only the unique ones are kept (since they have a hash anyway, this is a fast operation). Ofcourse, deleted items referenced by other files and playlists will get the ID of the one and only kept thumbnail's id;
- deleted thumbnails of inexistent or dead entries (as I said, this is a bug in Mezzmo, ghost entries remain many times after deleting stuff)
- removed oprhaned playlists (there were A LOT of those!). Recursively doing this until no entries with inexistent parents remain.
- vacuum - to compact the database file

Final results: after running this cleanup script, my DB file shrank from 3.5 GB to 67 MB. That's 50 times smaller in size, with absolutely the same DB content.

Unofrtunately, I have to run this script after each time Mezzmo starts or I add any new files, because on startup/adding files, it WILL re-duplicate all those thumbnails for the playlist entries again and again, ending up back to gigabytes in size.

So, my request to your DEV team is: please, please, PLEASE, figure this out for your next release. My system drive is not a black-hole storage space for the Mezzmo server. DO NOT DUPLICATE thumbnails over and over again, DO NOT keep in the DB thousands and thousands of dynamic playlists (they're called dynamic for a reason), FIX those dead entries that remain after editing the library, and you'll have happier users.

Thanks.

[Paul]

Many thanks for the detailed post, Adrian. We've addressed several of these issues in the next release. Email us at support [at] conceiva [dot] com and please send us your script. We'll check that our fixes matches what you are doing.

[JohnM]

I feel cheated. My db is only 995KB and I have 1958 video files and about 20000 songs. It is like I am not getting the bang for my buck.

Oh wait, it might just be the way I have my system set up. Never mind you guys are doing great keep up the good work.

[jeauxbleaux]

Wow! I just looked at my database and was chagrined to see that it is just under 2G for about 600 movies and 4000 songs.

I suspect that there is a balance to be struck here. Making the database fully relational will dramatically reduce its size, but may reduce performance in some cases, like multiple users browsing menus on endpoint devices. Replication may shorten menu response time but balloons the database size, especially with all the duplicated bitmaps. It also slows down the Mezzmo application; adding files and editing entries can sometimes be a frustratingly slow process.

All that said, I think there has got to be a way to eliminate most if not all of this replicated data, particularly the thumbnails, without an excessive performance hit. At least now I know why my Mezzmo application runs so much slower than it used to. I know for a fact that MEZZMO.DB was about 65Mb with v2.x.

Please add my voice to the chorus to clean this up. Thanks.

[Paul]

Thanks for the feedback.

[JMC]

My DB is 7GB - and database maintenance in the new verions didn't help shrinking that. Would adrian please publish the script or you guys please fix this? The DB growed more than 5GB in the last 2 versions...

[Paul]

We're looking into this for the next major version of Mezzmo.

[Lifferds]

Mine is 406 mB but I found the MezzmoTranscode.db was 97 mB with only a single entry, even after compacting. I ran vacuum on it in SQLLite and it shrank to 15 kB. Looks like the compact feature does not compact all db's.

[JMC]

Holy crap... As mentioned in another thread regarding the permanent task changing playlists... I just opened the database with a SQLite browser - MGOPlaylist has 102341 elements in my database. From the HUGE number of thumbnails inside the database (108533!): Am I right, that for a TV Show for example every episode gets an own thumbnail of the same picture used for the whole show? Now wonder this database is growing all over again...

Edit:
Deleting the dynamic video playlists for file type, actor and director followed by a compact compacted it from more than 7GB to 3,4GB. Compacted it before this to make sure it's the playlists... So you are telling me more more than 3GB inside the database is because of the dynamic playlists????

[Paul]

The storing of artwork is not optimal at the moment, and this will be fixed for the next version.