slimscrobbler 0.27 bug/design feature

[Jack Coates]

As noted by the presence of a off-line/on-line option, slimscrobbler
will hang up slimserver for a nice long time if it's not able to agree
with the audioscrobbler server about what's going on. I've had a couple
today (thanks to the audioscrobbler guys for making this so easy to see):

Your plugin reported a submission error: Plugin bug: Submitted length
out of bounds. Songs less than 30 seconds in duration are not accepted.

The other was also a submission error, which I failed to copy-n-paste,
about dates being wrong.

The big issue here is that it hangs up when something is going wrong...
I've done some simple fork() work with Perl that has proved to work
pretty well cross-platform, but there's obviously big issues with doing
that in something as complex as Slimserver plus a bunch of plugins
(especially since DBI isn't threadsafe). What about putting plugins into
their own execution space? But then this sucks for the plugins that are
supposed to execute in the main line, like AlienBBC.

So I guess I don't have any good ideas, but would welcome discussion
from those who know more.

--
Jack at Monkeynoodle dot Org: It's a Scientific Venture...
Riding the Emergency Third Rail Power Trip since 1996!

[kdf]

Re: slimscrobbler 0.27 bug/design feature

Quoting Jack Coates <jack (AT) monkeynoodle (DOT) org>:

> As noted by the presence of a off-line/on-line option, slimscrobbler
> will hang up slimserver for a nice long time if it's not able to agree
> with the audioscrobbler server about what's going on. I've had a couple
> today (thanks to the audioscrobbler guys for making this so easy to see):
>
> Your plugin reported a submission error: Plugin bug: Submitted length
> out of bounds. Songs less than 30 seconds in duration are not accepted.
>
> The other was also a submission error, which I failed to copy-n-paste,
> about dates being wrong.
>
> The big issue here is that it hangs up when something is going wrong...
> I've done some simple fork() work with Perl that has proved to work
> pretty well cross-platform, but there's obviously big issues with doing
> that in something as complex as Slimserver plus a bunch of plugins
> (especially since DBI isn't threadsafe). What about putting plugins into
> their own execution space? But then this sucks for the plugins that are
> supposed to execute in the main line, like AlienBBC.
>
> So I guess I don't have any good ideas, but would welcome discussion
> from those who know more.

6.0 has a non-blocking API that might be useful here. it is cross platform,
simple, and doesn't require that someone currently working on other important
tasks stop everything to implement it Of course, the reponses from
scrobbler could be optimised a bit too. Either way, using
Source:penRemoteStream should help a bit, and is the place to start
regardless of any future desires for forking/threading/launching virtual
copmuters with uniquely allocated rources, etc.

-kdf

[Jack Coates]

Re: slimscrobbler 0.27 bug/design feature

kdf wrote:
> Quoting Jack Coates <jack (AT) monkeynoodle (DOT) org>:
>

Turns out this plugin needs a decent amount of overhaul, I think I'm
going to take a swing at it after I finish my wife's mail processing
utility... One big thing is that unchecking it in the server settings >
plugins UI doesn't actually deactivate it -- not sure if this is
Slimserver or Slimscrobbler's problem.

>
>>As noted by the presence of a off-line/on-line option, slimscrobbler
>>will hang up slimserver for a nice long time if it's not able to agree
>>with the audioscrobbler server about what's going on. I've had a couple
>>today (thanks to the audioscrobbler guys for making this so easy to see):
>>
>>Your plugin reported a submission error: Plugin bug: Submitted length
>>out of bounds. Songs less than 30 seconds in duration are not accepted.
>>
>>The other was also a submission error, which I failed to copy-n-paste,
>>about dates being wrong.
>>

turns out these were "spam protection messages", and I get a lot of
them, which cause the majority of the slimserver hangs.

http://www.audioscrobbler.com/forum/28/_/7082

>>The big issue here is that it hangs up when something is going wrong...
>>I've done some simple fork() work with Perl that has proved to work
>>pretty well cross-platform, but there's obviously big issues with doing
>>that in something as complex as Slimserver plus a bunch of plugins
>>(especially since DBI isn't threadsafe). What about putting plugins into
>>their own execution space? But then this sucks for the plugins that are
>>supposed to execute in the main line, like AlienBBC.
>>
>>So I guess I don't have any good ideas, but would welcome discussion
>>from those who know more.
>
>
> 6.0 has a non-blocking API that might be useful here. it is cross platform,
> simple, and doesn't require that someone currently working on other important
> tasks stop everything to implement it Of course, the reponses from
> scrobbler could be optimised a bit too. Either way, using
> Source:penRemoteStream should help a bit, and is the place to start
> regardless of any future desires for forking/threading/launching virtual
> copmuters with uniquely allocated rources, etc.
>
> -kdf

the more I think about this, the more I think that AudioScrobbler has
made a mistake in implementing the service as an HTTP daemon at all...
why does this data need to be updated that quickly? Using HTTP instead
of a non-real-time protocol like SMTP or NNTP just means that their
server-side resource requirements are huge, and consequently their site
is slow. Just like the stupid forums vs. email discussion, I suppose.

So, since they're not going to change that, I'll take a look at two ideas:

5.4.0, I'll just move the "submit to AudioScrobbler" function into an
external script and kill any instances that are left hanging around
after 90 seconds or so.

I'm not ready to go to 6.0 yet, but when I am I'll check out the
Source:penRemoteStream functionality. That said, I still think
spawning an external is the Right Thing To Do(TM) for such an
unimportant function... honestly, Slimserver could care less whether the
submission was successful or not.

--
Jack at Monkeynoodle dot Org: It's a Scientific Venture...
Riding the Emergency Third Rail Power Trip since 1996!