Hello everyone,
I'm using pytone for more thant 6 months now and I'm quite happy using it. Really a neat ogg player.
Today I had some time in front of me and I decided that I would hack a service for audioscrobbler¹. The audioscrobbler is quite idiot at this time since there is nothing like offline batching of entries and so on, but it's a first draft (of a worst case scenario as might say Tom Barman).
So I'd like to know, is this piece of code interesting enough to enter in pytone and if it is how can I upload it ? CVS/SVN ? mail the patch ? anything else ?
[1] : http://www.audioscrobbler.com/, is a site that builds a profile of your musical taste and propose you new artists/album you might like.
Hi Nicolas,
On 17.11.04, Nicolas Évrard wrote:
I'm using pytone for more thant 6 months now and I'm quite happy using it. Really a neat ogg player.
Thanks.
Today I had some time in front of me and I decided that I would hack a service for audioscrobbler¹. The audioscrobbler is quite idiot at this time since there is nothing like offline batching of entries and so on, but it's a first draft (of a worst case scenario as might say Tom Barman).
So I'd like to know, is this piece of code interesting enough to enter in pytone and if it is how can I upload it ? CVS/SVN ? mail the patch ? anything else ?
Whether integration makes sense, depends on how intrusive it is. Isn't there a command-line application for submitting audioscrobbler information. If yes, one could just call that when the playback of a new song starts (there is already support for this). Still, if you have already have implemented this feature, just send the patch to me or to the list and I'll have a look on it.
Jörg
* Joerg Lehmann [20:59 18/11/04 CET]:
Hi Nicolas,
Hi,
I'm using pytone for more thant 6 months now and I'm quite happy using it. Really a neat ogg player.
Thanks.
No, thank you.
Today I had some time in front of me and I decided that I would hack a service for audioscrobbler¹. The audioscrobbler is quite idiot at this time since there is nothing like offline batching of entries and so on, but it's a first draft (of a worst case scenario as might say Tom Barman).
So I'd like to know, is this piece of code interesting enough to enter in pytone and if it is how can I upload it ? CVS/SVN ? mail the patch ? anything else ?
Whether integration makes sense, depends on how intrusive it is.
Not intrusive at all. You just define you're login name and password in pytonerc and there is nothing else to do.
Isn't there a command-line application for submitting audioscrobbler information. If yes, one could just call that when the playback of a new song starts (there is already support for this).
In fact, I'm using the playbackinfochanged event since the information is be sent after 240 seconds or when the track reached its middle. Correct me if I'm wrong but the playbackinfochanged event is the only one that send information about where we are in the song.
Still, if you have already have implemented this feature, just send the patch to me or to the list and I'll have a look on it.
Ok, I'm using it for 2 days now and it works.
Here is the patch, the scrobber service module and the audioscrobber module (I plan on using it elsewhere that's why I separated them).
Hi,
On 18.11.04, Nicolas Évrard wrote:
Not intrusive at all. You just define you're login name and password in pytonerc and there is nothing else to do.
Actually, I don't like username and password as configuration options in the general section too much. Maybe one should create a different section for audioscrobbler. But see below.
Isn't there a command-line application for submitting audioscrobbler information. If yes, one could just call that when the playback of a new song starts (there is already support for this).
In fact, I'm using the playbackinfochanged event since the information is be sent after 240 seconds or when the track reached its middle. Correct me if I'm wrong but the playbackinfochanged event is the only one that send information about where we are in the song.
Yes, that's true.
Still, if you have already have implemented this feature, just send the patch to me or to the list and I'll have a look on it.
Ok, I'm using it for 2 days now and it works.
Here is the patch, the scrobber service module and the audioscrobber module (I plan on using it elsewhere that's why I separated them).
The separation is fine. But we should only start the scrobbler service if it is used. But...
... this all brings me to the point that it would actually be very nice, if we could make the audioscrobbler service the first PyTone plugin. The user should then be able to specify a list of plugins to be loaded in the configuration file. These plugins then probably could handle their configuration files separately.
What do you think? It should not be too difficult to implement. Maybe, we have to make some iterations with the interface but in the end I think it would be useful for others as well. We could also provide a generic plugin class, which already does the setup of the threading stuff, etc.
Jörg
* Joerg Lehmann [22:13 18/11/04 CET]:
Not intrusive at all. You just define you're login name and password in pytonerc and there is nothing else to do.
Actually, I don't like username and password as configuration options in the general section too much. Maybe one should create a different section for audioscrobbler. But see below.
Yep, I also think this is a problem it is just a quick hack to make it usable.
Still, if you have already have implemented this feature, just send the patch to me or to the list and I'll have a look on it.
Ok, I'm using it for 2 days now and it works.
Here is the patch, the scrobber service module and the audioscrobber module (I plan on using it elsewhere that's why I separated them).
The separation is fine. But we should only start the scrobbler service if it is used.
Indeed, this think is always triggered and that's not really the ideal behavior, I suppose there is plenty of people that don't want a site to know they are listening to the next unreleased big hit they just got via p2p.
But this all brings me to the point that it would actually be very nice, if we could make the audioscrobbler service the first PyTone plugin. These plugins then probably could handle their configuration files separately.
Would be a nice feature.
What do you think? It should not be too difficult to implement. Maybe, we have to make some iterations with the interface but in the end I think it would be useful for others as well. We could also provide a generic plugin class, which already does the setup of the threading stuff, etc.
Seems like a great idea.
We could have a directory in .pytonerc that stores all plugins. We prepend this directory to sys.path, query the conffile for the list of plugin to load. Then we call the start method of all the plugins (or anything else) and it's ok.
I've got the felling this schema is good for plugins that gets informations, but if you want to provide pieces of information (retagging, ...) they will also need to send them. Maybe the hub should also be able to manage 'information providers' and 'information requesters'
Well, I'll try all these ideas tomorrow, please make comments about all this where you see fit.
Hi Nicolas,
On 19.11.04, Nicolas Évrard wrote: [snip]
The separation is fine. But we should only start the scrobbler service if it is used.
Indeed, this think is always triggered and that's not really the ideal behavior, I suppose there is plenty of people that don't want a site to know they are listening to the next unreleased big hit they just got via p2p.
Exactly.
But this all brings me to the point that it would actually be very nice, if we could make the audioscrobbler service the first PyTone plugin. These plugins then probably could handle their configuration files separately.
Would be a nice feature.
What do you think? It should not be too difficult to implement. Maybe, we have to make some iterations with the interface but in the end I think it would be useful for others as well. We could also provide a generic plugin class, which already does the setup of the threading stuff, etc.
Seems like a great idea.
We could have a directory in .pytonerc that stores all plugins. We prepend this directory to sys.path, query the conffile for the list of plugin to load. Then we call the start method of all the plugins (or anything else) and it's ok.
That's what I had in mind except for that we also need to have a global plugin directory.
I've got the felling this schema is good for plugins that gets informations, but if you want to provide pieces of information (retagging, ...) they will also need to send them. Maybe the hub should also be able to manage 'information providers' and 'information requesters'
You can already send information via the hub, for instance about changes in the song metadata. The only thing I want to do before we make this interface more publically availbale is to get rid of the ugly hub.hub.notify by adding a notify method to the hub module which uses the default hub. But these are minor issues.
Well, I'll try all these ideas tomorrow, please make comments about all this where you see fit.
Go ahead!
Jörg
On Thu, 18 Nov 2004 22:13:17 +0100 Joerg Lehmann joerg@luga.de wrote: [...audioscrobbler integration discussion...]
... this all brings me to the point that it would actually be very nice, if we could make the audioscrobbler service the first PyTone plugin. The user should then be able to specify a list of plugins to be loaded in the configuration file. These plugins then probably could handle their configuration files separately.
I'd like to make a suggestion for the second PyTone plugin: A tag editor. Editing ogg vorbis comments would be sufficient for me, but, there might be some mp3 users out there, too :-)
Uwe
-
Joerg Lehmann -
Nicolas Évrard -
U. Bielz