song.db is four time bigger that song.gdb

[zapzap]

hi,

do we have choice of DB backend ?
and why change the DB ?

thanks.

[rpedde]

The backend was changed for several reasons:

1. With a SQL-type backend, it makes it easier to write custom front-ends for it. Like, a web page that shows the top most played songs (using php with sqlite support). Or any other things that people might think of. It helps to make the database more open, so other people can do neat things with it. I hope that someone will tackle a php based playlist editor, for example. Or a php-based system to edit song ratings.

2. Scales better. The gdbm backend didn’t scale well on large databases (too much memory utilization for small devices like the NSLU2 or linkstation). This one should scale to arbitrarily large databases.

3. Can decouple the front-end and backend — so the database could eventually live on a mysql database on another machine.

4. And also means you could potentially use mt-daapd as a front-end for an existing mysql web jukebox (like netjuke).

Anyway, that’s why.

I thought I was factoring the database stuff right, but it turns out I wasn’t, so it needs to be fixed again. Once I get done with that reorganization, I might try to put back a gdbm backend so people with small music libraries can enjoy the size and speed benefits of the gdbm database.

— Ron

[zapzap]

Nice to know
thanks Ron

[Author]

Posts