Re: [Rhythmbox-devel] thoughts on 0.5.2

[Colin Walters <walters verbum org>]

On Tue, 2003-09-02 at 19:38, Zack Weinberg wrote:
> thought I'd give rhythmbox a try, and here are some suggestions for
> improvements, in rough decreasing order of importance.
> 
> 1) I have a lot of music: the little indicator in the lower right hand
>    corner of the library says "6.0 days (2184 songs)".  This is mostly
>    Ogg Vorbis format, with some MP3s.  There is roughly 8.8GB of data.

Scalability is my #1 concern right now.  I have an arch branch
walters@rhythmbox.org--2003/rhythmbox--rhythmdb--1.0 where I've been
working on a new database backend, which is starting to pass some
initial tests now.

>    Loading all this into the library took about ten minutes.  Then I
>    discovered that I needed to put track number tags on all the oggs,
>    which took about five minutes with a shell one-liner, and then I
>    restarted rhythmbox so it would notice ... which took an hour and a
>    half, with the CPU pegged the whole time.  At once point I applied
>    strace to one of the threads that was madly thrashing away, and saw
>    it issuing one-character read() system calls over one of the music
>    files.

Woah, interesting.  I knew about this bug (refreshing changed files),
but I didn't know it was possibly caused by such small reads.  This is a
very important bug to fix though - I want the UI to always be very
responsive.

>    In ordinary use the program is just slow enough to be irritating,
>    without being too slow to be unusable.  Scrolling the library, for
>    instance, flickers noticeably.  Sometimes, if the window has been
>    hidden, it will take a few seconds to repaint.  The search facility
>    _is_ unusably slow, presumably due to the cost of updating the
>    giant treeview pane on every keystroke.  Dragging things from the
>    library to a playlist also causes half-second or so UI pauses.
>    Impressively, none of this makes the music skip.

Are you using 0.5.2?  There is a bug where it saves the library every
minute or so, but this blocks the main thread, which can cause it to
feel much less responsive.  That's fixed in the upcoming 0.5.3.

And again the new backend in progress should hopefully speed up stuff a
lot more.

> 2) There appears to be no way to reorder the entries in a playlist
>    arbitrarily.  One may sort them, but that's all.  This makes it
>    difficult to design 'mixtapes.'

This is what I'm going to do right after the new backend.

> 3) My two cents on the panel icon: I would prefer an applet to a
>    notification area entry, simply because I would then be able to get
>    rid of the notification area, which I have no other use for.

Ok.  The discussion about this is still ongoing.  I'm not very happy
with how the notification area works.

>    Having the icon change to indicate whether music was playing or not
>    would be nice.  

Yeah - that should be easy enough to implement, if someone could
contribute a bit of art for it...

> Displaying the current track on hover is the right
>    thing.  Maybe it could show time remaining too?

Yeah, that's a good idea.  Unfortunately right now we're in a string
freeze, so I can't do this on the mainline.  I've created a
rhythmbox--post-0-5-3--1.0 branch, where this is now implemented.

> 4) Replay Gain support would be nice.  This is partially a gstreamer
>    feature, but the controls need to be visible in the rhythmbox UI.
>    See http://replaygain.hydrogenaudio.org/player.html for details
>    (their suggested dialog box is kind of cluttered, but gives you
>    the idea).  Current xmms has this for ogg files and it's addictive.

Yeah, there's an open bug about this:

http://bugzilla.gnome.org/show_bug.cgi?id=107786

I can't say it's high priority for me.

> 5) Some playlist-control features I would really like to have: "play
>    this track next", "stop at the end of this track", and "never play
>    this track again" (which should leave the track in the library,
>    just marked specially, so I can get it back if I change my mind).
>    "Stop at the end of this track" would be useful to have on the
>    applet menu.

Hmmm.  I think I would rather have a better ability to manipulate
playlists.  So you could easily manipulate a queue of songs to play.
"play this track next" => drag it to be next in the playlist
"stop at the end of this track" => drag it to the end of the playlist
"never play this track again" => delete from library, you can always
re-add it later if you change your mind

> 6) I miss the ability to sort the library on multiple columns.  I'd
>    like to tell it to sort first by artist, then by album, then by
>    track.  Sorting by artist seems to do this but only by accident.
>    I would also find sort-ignoring-leading-articles (a, an, the) useful.

What would a UI for this look like?  Currently it does have hardcoded
priorities for the different sort columns.

> 7) I'd like to be able to reorder the columns in the library/playlist view.

Yeah, on the todo list.

> 8) Why does it spawn a new playback thread (and kill the old one) for
>    every track?

GStreamer bugs, essentially.

> 9) Any way it can avoid loading gstreamer plugins it's not using?

Hm...I think they're all mapped into memory so it can do typefinding for
spider. Probably GStreamer should unload those that haven't been used
after doing typefinding.

Thanks for your comments, Zack!