You are here: Home » Topic » song.db is four time bigger that song.gdb

song.db is four time bigger that song.gdb

This topic contains 2 replies, has 2 voices, and was last updated by  zapzap 12 years, 3 months ago.

Viewing 3 posts - 1 through 3 (of 3 total)
  • Author
    Posts
  • #79

    zapzap
    Participant

    hi,

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

    thanks.

    #3512

    rpedde
    Participant

    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

    #3513

    zapzap
    Participant

    Nice to know
    thanks Ron

Viewing 3 posts - 1 through 3 (of 3 total)

You must be logged in to reply to this topic.