Posted Dec 10, 2008 21:11 UTC (Wed) by kev009 (subscriber, #43906)
Parent article: Amarok 2.0 released
I think the core media player looks nice and should get better over time.
Yet the MySQL/e switch is a pain. I never had these supposed performance problems with the SQLite backend and have a 30GB library. I think choice between at least SQLite, MySQL/e, and MySQL is the only way to make everyone happy.
Posted Dec 10, 2008 21:23 UTC (Wed) by kragil (subscriber, #34373)
[Link]
There are users with 1TB+ and SQlite did not work for them.
And I also think most Amarok users have more than 30 GB. That is just a few discographies in great quality.
Most of the music lovers I know have 100 GB or more.
Amarok 2.0 released
Posted Dec 11, 2008 21:41 UTC (Thu) by oever (subscriber, #987)
[Link]
Are you talking about a database of 1 TB to go with your music? That's quite a bit. The music is not stored in the database. Metadata is. At what size does the sqlite database break down? If it does, it may be due to mixing data and search columns in one large table. For efficient querying, it's better to split up tables in some cases.
Amarok 2.0 released
Posted Dec 12, 2008 17:06 UTC (Fri) by rvfh (subscriber, #31018)
[Link]
I thought SQLite was the best DB when writing little and reading often, so what's the advantage of MySQL here? Only at DB creation might it be better, and even then, you're usually _only_ writing, and I suppose with only one process (I suspect disk access will be the blocking point, not CPU, so no point in MT), so it should be ust as quick...
Anybody with a link to the rationale behind the switch?
Amarok 2.0 released
Posted Dec 12, 2008 19:16 UTC (Fri) by nix (subscriber, #2304)
[Link]
Yeah, running a large extra daemon solely for the sake of one music player
just isn't going to fly for me at least, nice though Amarok is.
Amarok 2.0 released
Posted Dec 11, 2008 21:44 UTC (Thu) by vmole (guest, #111)
[Link]
But they're only storing metadata, right? So it's not the size of the files, but the number and tagging that matter.