Conversation
|
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. |
|
Agreed. I am glad to help with a part of this. |
|
Great. I'll make some initial drafts in a separate branch in the next few days. Then we can start the discussion. |
|
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. |
|
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 ( |
|
Current design idea:
Current problems:
|
|
Two possibilities to handle the connection timeout:
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. |
After this change, each command to MPD results in a connect() and disconnect() call. This ensures that server connections never time out. Refs #45.
The ``StatusThread`` now uses ``select.select()`` calls with a timeout to check whether the MPD ``idle`` command has new information already or not. This prevents a blocked client if something goes wrong. Refs #45.
After this change, each command to MPD results in a connect() and disconnect() call. This ensures that server connections never time out. Refs #45.
The ``StatusThread`` now uses ``select.select()`` calls with a timeout to check whether the MPD ``idle`` command has new information already or not. This prevents a blocked client if something goes wrong. Refs #45.
- Logging in interesting places - Status thread with second MPD client instance to check for song ending. There is still a problem with server side timeouts. We'll have to use pings or the idle command to overcome them. Or maybe create a wrapper around the MPD client instance that automatically reconnects and re-runs the command.
After this change, each command to MPD results in a connect() and disconnect() call. This ensures that server connections never time out.
The ``StatusThread`` now uses ``select.select()`` calls with a timeout to check whether the MPD ``idle`` command has new information already or not. This prevents a blocked client if something goes wrong.
|
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:
The signal handlers should not call any non-reentrant code. For that, we probably need an event loop of some sort. |
3 participants
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.