Couple of days ago, the second beta to the second version of the immensely popular and fantastic audio player Amarok was released by the Amarok team.
The second beta brings in some drastic changes, the main one being SQLite no longer being the default backend, and PostgreSQL support being dropped, in favour of a single backend, that being MySQL-Embedded platform. Other notable changes include improved scripting support, the return of lyric fetching and incremental scanner support.
Amarok 2.0 Beta will also not be on the same level, feature-wise, with Amarok 1.4 as the developers are rewriting most of Amarok codebase meaning that most of Amarok 1.4 scripts will not be compatible with Amarok 2.0 ones (and the list of Amarok 1.4 scripts is pretty huge, you might want to have a look at Some of the coolest Amarok scripts)
(Pic taken from Amarok blog)
In subsequent blog posts Mark Kretschmann has mentioned, which features Amarok 2.0 feature, such as
- USB mass storage devices support
- Stop after this track
- Queue feature
- Dynamic Collection
- Cue file support
- Collection statistics
- Playlist sorting
- Showing new tracks in collection
And the following features have been dropped in Amarok 2.0
- Old style playlist, “Excel Look“
- Support for Amarok 1 scripts
- Multiple databases (SQLite and PostgreSQL)
- Player Window
While Player window going missing might seem like a huge WTF, the developers plan to bring it in as a Plasmoid.
Jeff Mitchell explains in his blog post as to why SQLite and PostgreSQL was dropped:
Since I mentioned Nepomuk, it’s time to discuss another common question/demand/complaint: KDE has this nice Strigi-Nepomuk thing going on…why aren’t we using it for scanning music and storing information? There are a couple main reasons. The first is that Strigi and Nepomuk are optional, not required. We can’t rely on the user installing them, and even if they are installed, we can’t rely on the user to configure them properly.
The second reason is speed: Amarok’s custom collection scanner is extremely fast and pulls out specific pieces of information with TagLib. Strigi is, by comparison, very slow.
Now we had to choose the type. At first, SQLite seemed like a good choice, it’s decently fast. It’s pretty stable.The first problem is performance, Although for people with small collections it performs fairly well, people with large collections that switched to the MySQL or PostgreSQL backends in A1 would report enormous speed gains when operations performing complex or many queries were performed.
However, just as we can’t rely on the user to set up Strigi/Nepomuk correctly, we can’t rely on them to get their tables set up in MySQL or PostgreSQL. So we needed the database to be embeddable, PostgreSQL, does not have any such thing, leaving us with MySQL.
Amarok 2.0 is shaping up to be an impressive and total overhaul of Amarok, will have a preview of Amarok 2.0 soon.