last.fm-related bug when starting 0.4.0

[trygvis]

$ mopidy
INFO     Starting Mopidy 0.4.0 on Linux-2.6.35-28-generic-x86_64-with-Ubuntu-10.10-maverick CPython 2.6.6
** Message: pygobject_register_sinkfunc is deprecated (GstObject)
INFO     Mopidy uses SPOTIFY(R) CORE
INFO     Last.fm scrobbler not started
INFO     MPD server running at [::]:6600
Exception in thread Thread-8:
Traceback (most recent call last):
  File "/usr/lib/python2.6/threading.py", line 532, in __bootstrap_inner
    self.run()
  File "/usr/lib/pymodules/python2.6/pykka/actor.py", line 331, in run
    return Actor._run(self)
  File "/usr/lib/pymodules/python2.6/pykka/actor.py", line 162, in _run
    self.on_start()
  File "/usr/lib/pymodules/python2.6/mopidy/frontends/lastfm.py", line 54, in on_start
    self.stop()
  File "/usr/lib/pymodules/python2.6/pykka/actor.py", line 147, in stop
    _ActorRegistry.unregister(self.actor_ref)
  File "/usr/lib/pymodules/python2.6/pykka/registry.py", line 114, in unregister
    cls._actor_refs.remove(actor_ref)
ValueError: list.remove(x): x not in list

INFO     Connected to Spotify
INFO     MPD client connection from [::ffff:127.0.0.1]:42454

[jodal]

Looks like clean shutdown of the Last.fm scrobbler when it isn't configured fails. Second time we got a bug on this. The bug has reappeared because of the Pykka rewrite.

Punish me if I don't write a test to confirm that this works properly.

[jodal]

@trygvis, can you reproduce this bug? If so, could you run mopidy with --save-debug-log and provide the contents of mopidy.log?

[trygvis]

@jodal

It turns out that I'm only getting this every other time I'm starting mopidy.

Log: https://gist.github.com/fcc2a0b27b854e045acf

[jodal]

I can reproduce this on one of my machines by leaving LASTFM_{USERNAME,PASSWORD} unset.

The issue is a race condition in Pykka, where now 1) the actor is started, and 2) the actor is registered. If you're unlucky in the scheduling of your threads, the actor's on_start() method fails and shuts down the actor--thus unregistering it--before the actor has ever been registered in the ActorRegistry.

As far as I can see, a fix is to 1) register the actor, 2) start the actor, as the actor inbox is created earlier, and any messages sent to the actor before the actor is started will be processed as soon as it is started.

[jodal]

This should be fixed with the release of Pykka 0.12.2 (new deb package is out) and df11f05, which will be in Mopidy 0.4.1 and 0.5.0.