You are here
The best feature of Amarok...
It seems in every version of Amarok 2 we have released there is at least one comment that sounds something like:
"But, the best feature of amarok 1.4 is still missing! Without --Insert one of the zillion and a half features Amarok 1.4 had-- Amarok 2.0 is useless!"
It is interesting for me to observe just how many "best features" Amarok 1.4 had, and also to observe exactly how many different ways Amarok was used. One of the issues with Amarok 1 development was that Amarok was trying to be a jack of all trades, and not really mastering any of them. This was well and good for the average Linux user, many of whom, when Amarok 1 was originally created, had no problem digging into the source to add their own little tweaks, features, or bug fixes. However, it is a problem for people that just want to listen to music, and leave the text editors and compilers at the door. With Amarok 2, our goal was not just to have features, but to perfect them.
To perfect features, we needed to limit our scope. Amarok 1 included a lot of dump-and-run code, where a large feature was submitted by an interested user, the code was committed and shipped, and then we never heard from the author again. This was the case with many of the media devices, and many of the engine backends.
We rely on phonon in amarok 2, so the engine issue is no longer one we have control over, although we are suffering from the results of incomplete phonon engines. While it is all sorts of nice to get backends for windows and mac for free, they come with many issues still, and we are constantly closing bugs reported by users that use the gstreamer phonon backend, as it is extremely buggy and incomplete. Unfortunately, many distributions ship this by default (due to patent issues) and as a result Amarok gets a reputation as being a lot less stable than it actually is on these distributions. Hopefully this issue is resolved in the future.
With regards to portable media devices, the ball is still in our park. Alejandro (xevix) had a summer of code project for portable media device support, and is working now on generalizing the code so that it will be fairly simple to add new devices. The shared infrastructure that Amarok 2 is built on (The Meta/Collection architecture) provides a familiar interface, so that even if Alejandro runs out of time (or interest) in the future, the code will be clear and understandable to whoever might pick up the pieces. The next step will be to readd additional media devices to Amarok 2 using this infrastructure. This should happen for 2.1 or 2.2, depending on various factors.
As we are constantly being reminded, perfection is not a fire and forget process. Code constantly improves (we hope) and mistakes we made in previous versions influence the next iteration that comes. This is quite visually apparent with the playlist. The Amarok 1.4 playlist was incredible to many people. It had a a lot of functionality and all sorts of nifty features, but at the same time, it was entirely unmaintainable by the time Amarok 1.4 ended. See this file if you don't believe me. For Amarok 2 we knew the playlist was important, but we wanted to start over, using the new model/view features in Qt4, and make it look more visually appealing. Ian's adventures are well documented. Nikolaj's adventures leading up to 2.0 were also well documented. The system that was created for 2.0 was a far cry from perfect, (the various paint methods made me cry on more than one occasion) but it was an important step on the road to this whole perfection thing. As Nikolaj more recent blogged, Amarok 2.1 is moving a lot closer to the ideal. I'm sure it will have issues, but with testing and use it will hopefully evolve into what we originally intended, a kick-ass feature that puts the Amarok 1.4 playlist to shame.
This has wandered pretty far afield from the point I didn't start with, but I suppose what I'm getting at is the same thing that we keep saying, and because I like to hit dead horses, I'll say it again. Amarok 2 is going to have many of the best features that Amarok 1 had. It will not have all of them. Our goal is to make a music player that is fun and enjoyable to use for a majority of the people. If this means omitting some esoteric features, then so be it. We also want a product that is fun and enjoyable for developers to work on, and that also provides incentive to not include the "fire-and-forget" code that composed many of the less-central features of Amarok 1.
Odpowiedzi
Or see the database code in this file...
http://websvn.kde.org/*checkout*/tags/amarok/1.4.9/multimedia/amarok/src...
"and we are constantly
"and we are constantly closing bugs reported by users that use the gstreamer phonon backend, as it is extremely buggy and incomplete. Unfortunately, many distributions ship this by default..."
Hey, at least Gstreamer sort of WORKS...xine doesn't play anything and none of the devs even cares to reply!!!
http://amarok.kde.org/forum/index.php/topic,16340.0.html
now you know how plasma feels
now you know how plasma feels ;) hope it's not getting you down. doing it Right will pay off in the long term - you know that, I know that, but not everyone does (and many never will, that being the nature of the internet).
I do hope none of *my* favourite features are missing, though ;)
Looking back at some of the
Looking back at some of the 1.4.x code makes it _really_ clear to me why I kept to working on the Magnatune stuff and rarely ventured beyond that until 2.0 development started. The horror, the horror....
Not so many features, still happy
I've been using amarok for a long time now and amarok 2, even without all the "must have" features, is to me, still much better then any other mediaplayer I've used.
Take your time. I've been using amarok 2 since beta and it's getting better every release
Being focused is the Right Thing. But let users go mad.
Even if you decide to not include $MY_FAVORITE_FEATURE, at least you sound like you have a clear picture of what you want, and that's a good thing in itself. But for $MY_CRAZY_FEATURE to exist nevertheless, please make sure that script support is kick-ass quality : hooks for just about anything, auto-update, easy browsing, etc. Extension is arguably the best thing about Firefox, I'm sure it could work the same way for Amarok.
Music Analogy
I don't know about you guys, but that post reminded me of some artists who say that they compose to please themselves and not the public.
A lot of my friends (and myself) were die-hard Amarok1 fans, and when they first saw Amarok2's interface they went: "WTF?!?! Amarok1 interface was fantastic! How come they didn't replicate it using Qt4?"
I was willing to accept the new interface (barely), but then I started to notice that it took forever to scan my collection, that no matter which backend I used, the thing crashed very often, that it wouldn't show some songs within the collection, and many other not-so-important quirks.
I can understand the rationale behind the decisions to prioritize code maintainability over features, but the average user doesn't give a rat's ass about how pretty the new code is and how easy is to add new features. People will always choose projects that get features in time over projects that get them over time.
Although my Amarok2 experience has been ugly so far, I really appreciate the work you've done.
I do not agree
I set out to write a long constructive comment but in stead turned it into a blogpost. Sorry for spam, but it can be read here:
http://gnufied.org/2009/01/23/amarok2-and-redefinition-of-awesomeness/
I just downgraded
I've been an amarok user since 1.4.2 or 1.4.3, I really forget. I've been watching the development of Amarok2 since it was announced - running up to 2.0.1.1 I built nightly and tested (never submitted bugs because I could never figure out where or how). After 2.0.1.1 was released, I stop bothering. Why? There were several reasons.
1) I'm a PHP/MySQL developer by trade and have quite a bit - thousands of lines of DRY code - written for remote management of my amarok library: downloading, (working on) an in-browser javascript playback engine, etc. After the 2.0 stable release, having no access to the raw SQL library itself due to MySQL-E being used, I went to the IRC channel and asked if this was possible. I was told "use the plugin system" which is poorly documented and doesn't offer the full slew of features dbus/dcop + MySQL direct access does. This seems to be just another example of the attitude the development team seems to have regarding other developers: "we do what we want and you'll like it!" However unfair this sounds, it's the impression I've gotten regarding the rejection of ideas, loss of features, etc.
2) Stability, stability, stability! Stable release or SVN nightly build, there have been exactly 0 times that the collection scanner has found my complete collection. While large (~15000 songs) it's nowhere near the top tier of music collectors that you hope to appeal to. Furthermore, more than a few albums of mine appeared twice, or three times, or only partially. If I only wanted to see tracks 1, 4, and 10-12, I'd only have those on my hard drive; if I wanted to listen to tracks 2 and 3 three times apiece, I'd playlist them like that, too. The hinge of amarok's success relies on the ability to accurately play music back, and when I can't do that, I might as well not listen to music at all. The "improved handling of large libraries and playlists" that I heard so much about in the weeks leading up to the release of 2.0 was all a myth - it takes longer to scan (and less accurately too, I might add), playlist control is slower and all in all, it's the same to worse regarding large playlists.
3) Where the hell is my searching? Like I said before, I'm an SQL developer and access to and manipulation of data gives me wood. In 1.4.10, I can search for tracks however the hell I want to - if I want to listen to my 96khz releases, I can do that - but in 2.0 we're given an incredibly restrictive set of search fields, which means either the data is no longer being tracked (but detected on playback every time?) or that it's a case of lazy developing. I'm not buying the "features will return" mantra regarding search fields - it'd no heavy code to implement the full searching functionality, just an extra few case statements and SQL parsing, nothing that isn't already done.
4) Community support? Hello? The strength of any good FOSS project is the strength of the community. And, like I said before, the development thought behind 2.0 seems to have been "we'll do what we want and you'll like it." Sure amarok1.4 was a smorgasbord of obscure and mostly useless features, but completely rejecting the community's input offhand seems inane. Had the people who have already been using amarok for years been polled, asked, or otherwise looked to for input on the development of 2.0, these nonstop "Where are my features?" blog posts would never have had to exist.
5) It's enormous. I can't, no matter what I do, make Amarok 2 look and work correctly scaled less than 1/2 of my 1600x1200 resolution. It's an audio player, not a code editor or a web browser, and my computing experience does not hinge on the prettiness of its interface. Like as been said before, most people keep amarok minimized in the tray the vast majority of time, so when it's out of the tray, it should be fast, and simple, to use and setup a playlist. A little perspective here would have been nice - sure the lyrics, album art, etc. are nice but they're by no means the most important thing that amarok does (which, my I remind you, is play my library, which it doesn't do accurately) and the focus of the UI seems to have be these extraneous features that are cool, sure, but still mostly useless.
These reasons, and several other smaller and less significant quirks, are why I migrated back to 1.4, and outside of breaking the uniformity of my kde 4.2 UI (which isn't really an issue as amarok lives in the tray most of the time), I have no regrets. Because Amarok 1.4 was far and away the best music application I have used, I'll continue to watch the development of the 2 series, but with a lot less interest. I hope that 2.1 lives up to the promises and addresses at least some of the issues that I hear about, or I'll be just another user disenchanted with amarok and looking for something new.
I just downgraded
I've been an amarok user since 1.4.2 or 1.4.3, I really forget. I've been watching the development of Amarok2 since it was announced - running up to 2.0.1.1 I built nightly and tested (never submitted bugs because I could never figure out where or how). After 2.0.1.1 was released, I stop bothering. Why? There were several reasons.
1) I'm a PHP/MySQL developer by trade and have quite a bit - thousands of lines of DRY code - written for remote management of my amarok library: downloading, (working on) an in-browser javascript playback engine, etc. After the 2.0 stable release, having no access to the raw SQL library itself due to MySQL-E being used, I went to the IRC channel and asked if this was possible. I was told "use the plugin system" which is poorly documented and doesn't offer the full slew of features dbus/dcop + MySQL direct access does. This seems to be just another example of the attitude the development team seems to have regarding other developers: "we do what we want and you'll like it!" However unfair this sounds, it's the impression I've gotten regarding the rejection of ideas, loss of features, etc.
2) Stability, stability, stability! Stable release or SVN nightly build, there have been exactly 0 times that the collection scanner has found my complete collection. While large (~15000 songs) it's nowhere near the top tier of music collectors that you hope to appeal to. Furthermore, more than a few albums of mine appeared twice, or three times, or only partially. If I only wanted to see tracks 1, 4, and 10-12, I'd only have those on my hard drive; if I wanted to listen to tracks 2 and 3 three times apiece, I'd playlist them like that, too. The hinge of amarok's success relies on the ability to accurately play music back, and when I can't do that, I might as well not listen to music at all. The "improved handling of large libraries and playlists" that I heard so much about in the weeks leading up to the release of 2.0 was all a myth - it takes longer to scan (and less accurately too, I might add), playlist control is slower and all in all, it's the same to worse regarding large playlists.
3) Where the hell is my searching? Like I said before, I'm an SQL developer and access to and manipulation of data gives me wood. In 1.4.10, I can search for tracks however the hell I want to - if I want to listen to my 96khz releases, I can do that - but in 2.0 we're given an incredibly restrictive set of search fields, which means either the data is no longer being tracked (but detected on playback every time?) or that it's a case of lazy developing. I'm not buying the "features will return" mantra regarding search fields - it'd no heavy code to implement the full searching functionality, just an extra few case statements and SQL parsing, nothing that isn't already done.
4) Community support? Hello? The strength of any good FOSS project is the strength of the community. And, like I said before, the development thought behind 2.0 seems to have been "we'll do what we want and you'll like it." Sure amarok1.4 was a smorgasbord of obscure and mostly useless features, but completely rejecting the community's input offhand seems inane. Had the people who have already been using amarok for years been polled, asked, or otherwise looked to for input on the development of 2.0, these nonstop "Where are my features?" blog posts would never have had to exist.
5) It's enormous. I can't, no matter what I do, make Amarok 2 look and work correctly scaled less than 1/2 of my 1600x1200 resolution. It's an audio player, not a code editor or a web browser, and my computing experience does not hinge on the prettiness of its interface. Like as been said before, most people keep amarok minimized in the tray the vast majority of time, so when it's out of the tray, it should be fast, and simple, to use and setup a playlist. A little perspective here would have been nice - sure the lyrics, album art, etc. are nice but they're by no means the most important thing that amarok does (which, my I remind you, is play my library, which it doesn't do accurately) and the focus of the UI seems to have be these extraneous features that are cool, sure, but still mostly useless.
These reasons, and several other smaller and less significant quirks, are why I migrated back to 1.4, and outside of breaking the uniformity of my kde 4.2 UI (which isn't really an issue as amarok lives in the tray most of the time), I have no regrets. Because Amarok 1.4 was far and away the best music application I have used, I'll continue to watch the development of the 2 series, but with a lot less interest. I hope that 2.1 lives up to the promises and addresses at least some of the issues that I hear about, or I'll be just another user disenchanted with amarok and looking for something new.