Implement IDLE command in mpd frontend about mopidy HOT 9 CLOSED

Our current design doesn't make it straight forward to implement 'idle' support. Though, we do have plans for some changes -- needed by e.g. the upcoming MPRIS and HTTP frontends -- that will make implementation of 'idle' easier.

Short answer: yes, but not right away.

As you can see at http://www.mopidy.com/docs/master/clients/mpd/, the only client we've tested that depends on 'idle' working is ncmpc. If you know of any other popular clients that doesn't work without 'idle', please tell us, and we'll update the client compatability list.

from mopidy.

Thanks,
I understand, I saw your documentation, I hoped if I push it a little it might go :-) currently I am developing IDLE-based client.

Looking forward using your API with my client :-)

from mopidy.

MPD client for XBMC? Shiny! We sure want Mopidy to work with that one ;-)

I'll leave this issue open as a friendly reminder to myself.

from mopidy.

For future reference:

The XBMC forum thread on this: http://forum.xbmc.org/showthread.php?t=79526

from mopidy.

any news on this?

from mopidy.

I'm working on some internal reorganization in Mopidy, which in turn will allow for giving the MPD protocol implementation access to the MPD client session. When this is in place, idle will be possible to implement.

from mopidy.

With the glib-loop branch in place (but not merged yet) I started doing some research against MPD to try and figure out the idle behavior. The following output is the subsystems that are triggered for each comment, with notes clarifying which playbacks state each applies to. I have a rather ugly script that I have hacked together to quickly get this data.

{'add': set(['playlist']),
 'addid': set(['playlist']),
 'clear': set(['player', 'playlist']), # player only when in playing state
 'consume': set(['options']),
 'crossfade': set(['options']),
 'delete': set(['player', 'playlist']), # player only when in playing state
 'deleteid': set(['player', 'playlist']), # player only when in playing state
 'disableoutput': set(['output']),
 'enableoutput': set(['output']),
 'load': set(['playlist']),
 'move': set(['playlist']),
 'moveid': set(['playlist']),
 'play': set(['player')]), # only when stopped
 'next': set(['player']), # only when in playing or paused state
 'pause': set(['player']), # only when in playing or paused state
 'playid': set(['player']),
 'playlistadd': set(['stored_playlist']),
 'playlistclear': set(['stored_playlist']),
 'playlistdelete': set(['stored_playlist']),
 'playlistmove': set(['stored_playlist']),
 'previous': set(['player']), # only when in playing or paused state
 'random': set(['options']),
 'rename': set(['stored_playlist']),
 'rm': set(['stored_playlist']),
 'save': set(['stored_playlist']),
 'seek': set(['player']),
 'seekid': set(['player']),
 'shuffle': set(['playlist']),
 'single': set(['options']),
 'stop': set(['player']), # only when in playing or paused state
 'swap': set(['playlist']),
 'swapid': set(['playlist'])}

Other things to note about behavior is that as soon as a client connects MPD starts tracking all subsystems for this client. By this I mean that if client 1 connects first, then client 2, client 2 starts playback and then client 1 does an idle call the result will be that client on gets a player subsystem changed response right away. This despite the player change happening before the idle call was invoked. This exact detail could probably be overlooked if we choose to.

As for the actual implementation of this, I would prefer that as little as possible of the code to support this leak out of mopidy.frontends.mpd. To achieve this I propose that the dispatcher broadcast subsystems to all active MpdSession actors in the same way that info is send to frontends. Then the MpdSession and/or MpdDispatcher belonging to that session should know if changed responses should be written to the client.

from mopidy.

Sounds like a good plan.

I have some upcoming ideas/commits on the MPRIS branch which takes the started_playing/stopped_playing events currently sent by the backend to the frontends (thus far only consumed by the Last.fm scrobbler) a bit further and adds more events, as needed by the MPRIS frontend. I believe this should be solved in approximately the same way. Hope to push the code during this weekend.

from mopidy.

Support for idle in Mopidy's MPD frontend have been merged with pull request #125. It will be in the 0.6 release.

from mopidy.