Re: [Rhythmbox-devel] some feedback for current cvs



On 12/20/05, James Livingston <doclivingston gmail com> wrote:
> 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?

It hangs at 100% CPU and never seems to come back. If I go away and
leave it and come back later its the same... just sits there at 100%

> > - 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.

Charles' reponse about the 'Untitled CD' inidicating that you could
lable it made sense.

> > - 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.

Both gnome-cd and grip (which I use for ripping CDs as it supports
VBR) use the .cddb (which I guess is the cddbslave stuff) which means
when there's an entry in there for the CD it uses that (so if you've
changed some details that are different from the online stuff it uses
that first and keeps it nice and orderly. Also means we're not
doubling up info with other apps.

> > - 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.

I think it is gnome-vfs as when I insert a cd that's detected its
launched in gnome-cd (the default app) and picked up by rb too where
as if its not seen by rb its not launched by the cd player either.

> > - 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?

I did but can't remeber, I'll have more of a play with it tonight and
see if I can work it out exactly.

> > 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.

:-)

I think a new release for 2.14 would be good, whether its a 0.10 or a
1.0. I think we'll need something  either way as we'd need to port 0.8
to the new gst 0.10 that's going into G2.14 (I think).

Also, one other query. Is the new play queue only for music in the
Library or can you add other ones too. I tried adding a couple of
tracks from a CD and it wouldn't, tried my ipod which either locked
the app at 100% or crashed it entirely (and locked up the ipod too)
but it sort of seemed that you could add them.

Pete


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]