First of all, thanks for releasing this plugin. I've been developing a
plugin for integrating EchoNest myself, but with a rather different
approach (focusing on catalog radio playlists, and using taste profiles
as seeds), so it will be interesting to compare the results.
Heh... where's the code? :-)
I actually planned to add something like that at some point (eg. a
recommendation mix, playing new music from an online service, based on
your collection). But I haven't gotten there yet. Spare time is very
limited...
- On both of the exports I ran (one with 0.94, the other 0.96), I got
this error at the end:
That's from the server.log, not the scanner.log, isn't it? It's some
postprocessing which is not part of the actual scan (though it is run
after the scan).
[13-01-03 20:14:22.7114] Plugins::SmartMix::API::_call (216) Async API
call: GET
http://developer.echonest.com/api/v4/catalog/read?id=XXXX&results=100&start=53400&api_key=*
[13-01-03 20:14:22.9586] Plugins::SmartMix::API::__ANON__ (225) do {
my $a = bless([
sub { "???" },
'fix',
{ params => {}, timeout => 15 },
"GET",
"http://developer.echonest.com/api/v4/catalog/read?id=XXXX&results=100&start=53400&api_key=*";,
"400 Bad Request",
Unfortunately the async HTTP code doesn't even read the response's body,
thus we don't get the full error message. And I haven't found a way around
it yet. If you send me your catalog ID (mherger ät logitech dott com) I
could probably see what is causing the failure.
But in any case this isn't a critical issue. What is failing here is
removal of tracks which might have been removed from your library.
Since my collection is > 60000 tracks, I'm not sure if this was finished
sucessfully - maybe the same issue reported by slartibartfast.
Check scanner.log for scanning issues.
- When trying a mix on a song which is not known to EN, you simply get a
"Failed to create playlist"
...
Maybe you could add a more specific message for the user - the
underlying issue is probably hard to fix.
Indeed. The whole UX has a lot of potential for improvement.
- API call restrictions / call rate: This is rather annoying (although
It definitely is. And it is one of the main reasons why I don't use the
steer command much. I don't want to put the overall experience at risk.
There already are >100 users of this plugin who share the 120 calls/min
limit...
it has gotten a lot better in the past months). One way to improve this
would be to let users optionally use their own API key (which is free to
get providing only minimal information to EchoNest), then the
This has been suggested before. And it is explicitely forbidden by TEN.
restriction (i.e. 120 calls/min) is for each installation, not for all
of them. Additionally, it seems there is a limit of 1000 taste profiles/
non-commercial key, so the 1001st user of the plugin will be out of
luck...
One of the TEN employees mentioned that his limit might go away soon.
- Steering the playlist using dynamic/feedback also lets you
ban/favorite songs/artists - quite a nice feature
I know :-/. But reporting playing items with hundreds of users could
easily cause issues with the tight rate limit.
- For my collection, the recognition rate is about 30%, even though it's
quite well tagged (it contains mainly non-mainstream music, though). One
thing I noticed when experimenting with my plugin was that the
recognition rate of songs really suffers from spelling differences for
artists (is it A Silver Mount Zion/A Silver Mt Zion/A Silver Mt.
Zion/Thee Silver Mt. Zion Memorial Orchestra ? what about
PJ.Harvey/P.J.Harvey/P.J. Harvey?). In order to improve this, one could
add an option to rename artists before the information is sent to EN.
Rename based on what rule?
Thanks for the input! I'm definitely a bit worried about the rate limit
(and spare time :-)) and plan to add more changes to reduce the overall
query rate.
--
Michael
_______________________________________________
plugins mailing list
[email protected]
http://lists.slimdevices.com/mailman/listinfo/plugins
