Move to MPD

[dbrgn]

I think it would be best if we replace Mplayer with MPD. One of the advantages is that it features a much better IPC API than the hack we're doing currently with the mplayer subprocess. Additionally the configurability is much better. A challenge will be to handle remote control by 3rd party applications, but I guess we can just ignore that feature and declare it as not supported.

I hope to find time to work on this in February.

[darnir]

I completely back your move here. A switch to MPD would be an excellent choice and may remove a lot of the headaches caused by various Mplayer crashes. MPD is extremely stable and a great choice for this project.

Remote control may be a problem, but that can be fixed at a later date. I'd like to help if possible to this shift. Once we decide on the design specifics, I'll try contributing as much as possible.

[mindstorms6]

Agreed. I am glad to help with a part of this.

[dbrgn]

Great. I'll make some initial drafts in a separate branch in the next few days. Then we can start the discussion.

[dbrgn]

Here's the first design decision: Should we communicate with the mpd directly via TCP, or should we use a client library like https://github.com/Mic92/python-mpd2? Any opinions? :)

Right now I tend to use the TCP based protocol directly, as we won't use most of the features anyways. All we need is to enqueue a song, and standard playback control like pausing, skipping and volume control.

On the other hand, a library would abstract away things like error handling...

---

Edit: What speaks for python-mpd2 is that it's well tested, actively developed and it does all the connection handling stuff like timeouts etc... Maybe it wouldn't be a bad idea to use it after all.

[dbrgn]

Never mind, I took a quick look at the library and it looks really nice. It saves us all the connection checking, timeout handling etc. So I'll use it.

I'll push a few first drafts to the mpd branch soon.

What do you think about creating a generic interface with abstract methods (load, playpause, stop, volume and terminate) to couple the player more loosely with the rest of the client? On one hand it's a great way to allow future backends to be created, on the other hand it might be a case of YAGNI and overly complex design...

[dbrgn]

Current design idea:

• MPD client backend that implements the player interface (backends/interface.py).
• Main connection instance that does playback control.
• Separate background thread with its own MPD client connection that waits for changes in playback status using the IDLE command (see http://www.musicpd.org/doc/protocol/ch03.html#idp49751888). When a relevant event occurs (e.g. end of song) it sends a signal to the process.

Current problems:

• The main connection instance looses connection after 1 minute without any action due to a server timeout (see https://github.com/Mic92/python-mpd2/issues/31). Possible workarounds: Wrapper or decorator to reconnect on connection errors. Or using the idle mode or pings to keep the connection alive. I don't know yet which one would work and which one would make more sense.
• I don't know yet how I'm going to detect the "30 seconds played" event. Probably with a "dumb" timeout, like in the MPlayer implementation.
• When trying to terminate the MPDPlayer while the status thread is still running, the entire process is blocked until an event happens.

[dbrgn]

Two possibilities to handle the connection timeout:

• Reconnect on every command: https://github.com/Mic92/python-mpd2/issues/31#issuecomment-33885468
• Regular pings.

It doesn't appear that connecting/disconnecting is a big overhead, so I'd suggest using the context manager in the link above. If someone thinks pings are the better solution, let me know.

[dbrgn]

I tried to continue with the development today. Unfortunately there's a problem with the signals.

The signal handlers execute code that can cause reentrancy problems. That means the following can happen:

• "Next track" command is received
• Connection to mpd is opened
• In the connection context manager, while the connection is open, the "song ended" signal handler fires and interrupts the context manager
• In the song end handler, the code to play the next song is called
• That code is already in the middle of execution though. That means that the already open connection is re-opened (which fails). Also, it can mean that locks are in an undefined state.

The signal handlers should not call any non-reentrant code. For that, we probably need an event loop of some sort.