On Sat, 2005-12-17 at 19:46 +0000, Peter Robinson wrote: > - Not sure if its because I've now got a rpm for libgpod and hence my > ipod support back or something else (am yet to actually plug it in :-) > but it seems to lock up regularly unless its started straight after > login with large cpu usage. I removed my ~/.gnome2/rhythmbox dir. This > seems to improve once you've added something to the library with it > working at least one out of two. What exactly do you mean by "lock up"? Does RB crash, hang, work but use 100% cpu? > - if there's no net connectivity it lables an Audio CD something like > Unknown Title whereas if it has net access it calls it Audio CD while > looking up the name and then the Title. In the former it should call > it Audio CD as I think it looks cleaner. My guess is that the musicbrainz library returns "Unknown Title" if it can't contact the server. Removable media (which includes audio cds) have their initial name set to whatever gnome-vfs reports, which is Audio CD in this case. We could probably check if there is no actual results returned, and not change the name in that case. > - It doesn't seem to cache this info. If I re-insert it later with out > a net connection it comes up the same. It'd be cool to query/use > ~/.cddb too like some other apps use. The best things would be to have a library which is a combination of Sound Juicer's musicbrainz lookup and the gnome cddbslave stuff. Potentially you could tell it whether you prefer MusicBrainz or FreeDB and have it use the other one if the first fails, and all sorts of crack. As Charles mentioned in his mail, having the title and track names be editable would be good too. > - audio cd detection doesn't always seem to work. Its fine if the cd > is in on startup of the app but if I eject it and push it back in its > not detected. This could actually be the OS/hal though as it doesn't > always run the default player at the same time. RB uses three methods to detect CDs. First, if you have a HAL-enabled gnome-vfs, the cd should show up/disappear when we get told about it. Second, if you have libnautilusburn 2.11.4 or later and a drive with door state (i.e. not slot loading) it will check when the drive door opens/closes. Finally there is a "Rescan removable media" menu items for when everything else fails. If it doesn't automagically detect CDs, but using the menu item works, then something is wrong with HAL/gnome-vfs. FC4 only has Gnome 2.10, so the second method is out. > - sometimes when moving between sources you need to double click to > get it to play (when another source is playing) sometimes its triple > click. That sounds odd, I don't suppose you've noticed any pattern to it? > There's a couple of other things that I haven't worked out exactly > what causes it, as I play more I'll let you know. It is looking very > nice though. Is it planned to get the next stable version out in time > for gnome 2.14? Unfortunately the first thing on the plan, is to write the plan. If we want to aim to do 0.10/1.0 sometime in the not-too-distant future, coinciding with Gnome 2.14 is probably a good plan. Cheers, James "Doc" Livingston -- +-------------------------------------------------------------------+ |-- SELF-ASSEMBLY MOEBIUS-STRIP - SEE OTHER SIDE FOR INSTRUCTIONS --| +-------------------------------------------------------------------+
Attachment:
signature.asc
Description: This is a digitally signed message part