New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Implement IDLE command in mpd frontend #32

Closed
lzoubek opened this Issue Nov 9, 2010 · 9 comments

Comments

4 participants
@lzoubek

lzoubek commented Nov 9, 2010

Hi,
Do you plan implementing IDLE command in mpd frontend? Most of MPD clients use it. IMHO this is the only way for clients to update state smoothly.

Thanks

@jodal

This comment has been minimized.

Member

jodal commented Nov 9, 2010

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.

@lzoubek

This comment has been minimized.

lzoubek commented Nov 9, 2010

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 :-)

@jodal

This comment has been minimized.

Member

jodal commented Nov 9, 2010

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.

@jodal

This comment has been minimized.

Member

jodal commented Nov 9, 2010

For future reference:

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

@rkh

This comment has been minimized.

rkh commented Mar 1, 2011

any news on this?

@jodal

This comment has been minimized.

Member

jodal commented Mar 1, 2011

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.

@adamcik

This comment has been minimized.

Member

adamcik commented Jun 23, 2011

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.

@jodal

This comment has been minimized.

Member

jodal commented Jun 25, 2011

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.

@ghost ghost assigned adamcik Jul 22, 2011

@jodal

This comment has been minimized.

Member

jodal commented Jul 25, 2011

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

@jodal jodal closed this Jul 25, 2011

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment