Mopidy: Is there any chance to support WIN32 platform?

I know that @abarisain successfully used Mopidy on Windows about a year ago. AFAIK, it was not easy to install, but is possible with the right know-how, and there should be no or few obstacles in the Mopidy source code as all issues at that time was fixed.

Windows support depends on someone stepping up to maintain Mopidy on Windows. First of all, that includes writing install docs for Windows. Ongoing, they must regularly run Mopidy develop on Windows to detect and fix compatibility issues with new releases before they're released.

If I remember correctly it was a little tricky to track down the right
gstreamer version but the binaries were out there.
On 29 Mar 2015 09:34, "Stein Magnus Jodal" [email protected] wrote:

I know that @abarisain https://github.com/abarisain successfully used
Mopidy on Windows about a year ago. AFAIK, it was not easy to install, but
is possible with the right know-how, and there should be no or few
obstacles in the Mopidy source code as all issues at that time was fixed.

Windows support depends on someone stepping up to maintain Mopidy on
Windows. First of all, that includes writing install docs for Windows.
Ongoing, they must regularly run Mopidy develop on Windows to detect and
fix compatibility issues with new releases before they're released.

—
Reply to this email directly or view it on GitHub
https://github.com/mopidy/mopidy/issues/1088#issuecomment-87370977.

So, anyone?

I think this is possible, too. I'll test it tonight and if it works, I'll post an install guide. But I'm 99% sure it works on Windows, probably using Python (pip install) and GStreamer for Windows.

Please see https://discuss.mopidy.com/t/run-error-object-has-no-attribute-unix-signal-add/1752/20 for the most recent attempt at this. We found a couple of fixes you'll need but I don't have time to help someone every single step of the way on this (as I have no interest in Windows) so if you can finish off this work that would be really good.

I started working on this and have it mostly running. But I haven't looked at MPD backend. I also didn't run into the issues that seanvree did in the discuss thread.

Last thing I ran into was urlparse.urlunsplit adding on an extra "/" thereby causing os.path.realpath to erroneously add C:\ to the front of the path.

Pretty sure the reason I didn't run into what seanvree did was because I'm using mopidy-local-sqlite.

I found a similar issue with m3u.

@jodal why was this closed - i dont see windows here

http://docs.mopidy.com/en/latest/installation

so it appears the issue has not been resolved

It was a question and the question was answered. Are you interested in stepping up to maintain Mopidy on Windows?

@kingosticks thats kind of a silly question - as you might guess ive never even used Mopidy - perhaps I would need to try it before making that kind of commitment

In case anyone ever does pick this up or just wants to run it on their own like I do. You want PyGObject for Windows for the libraries, use the SQLite backend, and something like https://github.com/mopidy/mopidy/compare/develop...dukrat:win32?expand=1 for patches.

This seems a good place to add that in Python 3.8 you should note (from https://www.tornadoweb.org/en/stable/index.html#installation):

On Windows, Tornado requires the WindowsSelectorEventLoop. This is the default in Python 3.7 and older, but Python 3.8 defaults to an event loop that is not compatible with Tornado. Applications that use Tornado on Windows with Python 3.8 must call asyncio.set_event_loop_policy(asyncio.WindowsSelectorEventLoopPolicy()) at the beginning of their main file/function.