Re: [Rhythmbox-devel] autoqueue plugin for rhythmbox

[Jonathan Matthew <notverysmart gmail com>]

On Mon, Aug 25, 2008 at 11:51:39PM +0200, eric casteleijn wrote:
> Hi all,
>
> I've ported my autoqueue plugin (originally written for quod libet):
>
> http://code.google.com/p/autoqueue/
>
> to rhythmbox, as a sort of proof of concept project after factoring out  
> all player specific stuff from the original.
>
> It's sort of early days, in that it doesn't support all the features  
> that the original does yet, and it's not configurable at all for now,  
> but it does seem to work, so I thought I'd start asking for feedback.
>
> What it does is look up similar tracks and artists to what's playing on  
> last.fm and puts them in the queue. It is similar to Alexandre  
> Rosenfeld's 'Last.fm Dynamic Tracks' plugin, but (potentially as  
> mentioned above) has some more features (but also takes more resources  
> and is less simple/elegant).

I haven't tried it out yet, but it certainly looks interesting.  I've been
thinking for a while that we should have the basics you need for a constructed
playlist sort of thing in rhythmbox itself, so people could play around with
techniques for generating playlists without so much overhead.

> What it does differently right now is:
>
> - it remembers played artists, and doesn't queue them again for a period  
> of time (now set to 1 day, will be configurable)
>
> - it also looks up similar artists, if none of the similar tracks are in  
> your local library. (The original also looks up by your personal last.fm  
> tags, I don't know if this can be ported. See below.)
>
> - it stores all the similarity data locally in a sqlite database, so it  
> should work (after a fashion) even when you or last.fm are not online.  
> This also means fewer queries to the last.fm webservice.
>
> What I will be able to figure out myself but have yet been too lazy to  
> do, is:
>
> - hooking up the configurable variables to some UI, so that they can be  
> easily changed by the end user.

> - porting the other restrictions, so that the same songs don't come by  
> too often.
>
> The features I would like to port, but might need rhythmbox specific  
> help with:
>
> - I would like to take the 'version' id3 tag into account when looking  
> up songs, since it often makes quite a difference to the actual  
> similarity of songs if you have a remix or live version or  
> original/album version of a song. I know the version is often just  
> appended to the title between parentheses (in fact last.fm does this),  
> but I'm anal about this kind of tagging, so I have them split off into  
> the version tag. There currently seems no way to get at that tag from  
> the python API, correct?

Correct.  Rhythmbox doesn't pay any attention to this tag, so it's not stored
in the database at all, because..

> - I synchronize my last.fm 'tags' (in the web 2.0/folksonomy/tag cloud  
> sense of the word, not the id3 sense) between my local collection and  
> last.fm. I put these in a custom id3 tag, unhelpfully and  
> unimaginatively named 'tag'. I would like to get at these too from the  
> python API, so I can do similarity lookups on them, when the other  
> lookups fail, and use them to restrict and relax the searches in smart  
> ways. In general, is there a reason the actual tags are all hardcoded  
> into the API? Couldn't an api method be added that takes the tagname as  
> an extra argument? (I guess that there probably *is* a very good reason,  
> I just don't know what it is ;)

The main reason is that song information is stored in a fixed structure in
memory (RhythmDBEntry), for memory and speed reasons.  As a result, we're
pretty reluctant to add new fields, as it increases memory usage by a fixed
amount, regardless of how sparsely the field is used.  I've got a vague plan to
fix this without compromising too much on speed or memory use, but it's still
some way off.

Rhythmbox does have the ability to store this type of tag directly in its
database, though.  You could grab existing tags from last.fm or extract them
from local files using GStreamer or mutagen or something, store them in the
database, and work from there.  I'm not sure if the functions you'd need are
available in python yet, but it wouldn't be hard to fix that.

> Anyhow: for now, checking out the trunk, and putting the following files  
> in your plugins directory:
>
> autoqueue.py
> rhythmbox_autoqueue.py
> rhythmbox_autoqueue.rb-plugin
>
> will work. If you want to see under the hood a little, while it's  
> running, run rhythmbox from the command line with:
>
> rhythmbox -D autoqueue
>
> Any feedback is greatly appreciated (if it's not rhythmbox specific,  
> please send it to me directly, or join the plugin mailing list on the  
> project page), and if anyone would like checkin rights just drop me a 
> line.
>
> cheers,
>
> -- 
> - eric casteleijn
> http://thisfred.blogspot.com
> _______________________________________________
> rhythmbox-devel mailing list
> rhythmbox-devel gnome org
> http://mail.gnome.org/mailman/listinfo/rhythmbox-devel