Re: [Rhythmbox-devel] Evolution of the album cover support in rhythmbox

> My opinion: Go with 2.  A tiny album cover isn't any better than no
> album cover. Yes, there will be two places with song info, but who
> would this confuse?  I think a tiny image has more potential to be
> confusing to the user than placement does here.

I don't get the reasoning at all here... "A tiny album cover isn't any
better than no album cover"? "A tiny image has more potential to be
confusing than placement"?

> Storage:
> 2) Per directory
>    pros:
>         - done elsewhere (xmms plugins, Rb gdesklet, albumcover, etc.)
>         - easy to implement
>         - stores 1 cover image per album
>     cons:
>         - requires the user to maintain a directory heirarchy

killer (unless I misunderstood what you mean by "per directory"):
    - nothing guarantees that you have write access to a directory, thus
a fallback mode is needed
(this is also a killer for 1) actually)

> And given Rb's metadata reading problems (which we can't pretend will just go
> away)

Yep, they surely won't go away without bug reports. Bad tag reading
issues (ie crashes or hangs) are generally fixed in the next gst-plugins
release when they are reported in bugzilla... Imo when the next version
of gst-plugins is out, there shouldn't have many issues with tag reading
left. The only big issue I can remember atm in the current gst-plugins
release is a hang when reading small image files.

> So let's just for the sake of discussion here say we're filing all of
> these images with unique filenames in ~/.rbcovers/.  You can't name
> them after just the album name since multiple artists have albums with
> the same name.  You can't name them artist-album.png because the
> compilation album case-scenario would cause problems.  So we could
> generate a unique ID for each album somehow in Rhythmbox and store it
> in rhythmdb, but then it becomes too difficult to edit by hand. 

I think people on freedesktop designing a spec for .Trash had the same
kind of issues and solved it somehow, might be worth looking at what
they came up with. I'd probably go with a simple naming scheme like
"artist-album" or "album" and append a magic number to the end. Then you
add a "cover-path" tag in rhythmdb and you are done. Anyway, this is an
implementation detail ;)



Attachment: signature.asc
Description: Ceci est une partie de message =?ISO-8859-1?Q?num=E9riquement?= =?ISO-8859-1?Q?_sign=E9e?=

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