Windows support

[JCapucho]

This PR allows spotifyd to run on windows as non-daemon and daemon-like, only the rodio-backend is supported and the config file is stored on:

%AppData%/Roaming/spotifyd/spotifyd.conf

All output is logged into a .spotifyd.log file on windows when running in both non-daemon and daemon mode although in daemon mode the startup is logged to the console before a detached subprocess with the same binary and arguments (with the exception that the argument --no-daemon is set) is started

[mainrs]

As this is (compared to other PRs) larger change I'll add it to the v1 milestone for now. This doesn't mean however that it won't get merged beforehand.

[MartB]

This seems to work perfectly fine on windows, just needs a rebase.

[JCapucho]

I rebased the branch and improved the logging now --no-daemon will use the terminal and the daemon will use the file but the file will be stored next to the config file instead of the current working directory this makes it easier to use windows services

[mainrs]

Thanks for that! I will merge this after I can update the librespot dependency. I will take a closer look at it then and do a proper code review. I just skimmed through it for now.

[Plecra]

Just want to add that there's currently a runtime dependency on libogg (from with-tremor), and I wouldn't expect to find it on most windows systems. Users will have to do something about this if they want to use spotifyd.

Edit: Skimmed through the implementation, and it looks like tremor and libogg are alternatives to lewton. Is there a reason we couldn't switch to the Rust implementation?

[Plecra]

Also, why aren't we using the windows services API for this? It seems to fit the role best.

[JCapucho]

I'm longer working on this and don't plan on working on it since I finally got rid of windows on the last machine I used that had it, if my memory is right I didn't use services because they are hard to get right and require special permissions while this method doesn't

[ekx]

Tried this out today. Seems to work well so far... Found one Issue: When I switch the audio output devices while spotifyd is running it keeps playing on the old device. Tested on latest Windows 10

[CptPotato]

A small issue I ran into is that I can't get the password_cmd option to work on windows. Other than that it is working fine for me 👍

[Runeii]

Seems that on Windows (10) the following commands work:

cargo build --release --no-default-features --features rodio_backend
cargo run --no-default-features --features rodio_backend

And this PR will build/run completely fine. However, it's not currently possible to install it using:

cargo install --path . --locked
cargo install --path . --locked --no-default-features --features rodio_backend

As it complains about:

error: failed to run custom build command for 'alsa-sys v0.1.2'

Which suggests to me it's ignoring the rodio_backend build flag.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[zoeleu]

Why is this dead? This is a great feature. I want to have spotify running HQ, without the desktop client.

[Brin-o]

Hi, just want to express my support for getting this pr in. It would be really cool to get a lightweight spotify client for windows.

[StaticPH]

I can confirm that with a bit of finagling, the code from the PR branch runs on Windows 8.1
To be clear, this means that the working build I have is based off the version 0.2.24 codebase, and not a more recent version with JCapucho's changes patched in; I don't know if simply applying the changes to the current codebase would yield a working build, and I didn't particularly need anything from the 3.0.x release, so I never tried.

I found that I had to specify limited version ranges for librespot, protobuf-codegen, and protobuf-codegen-pure in Cargo.toml

[dependencies.librespot]
version = ">= 0.1.1, < 0.1.2"
default-features = false
features = ["with-tremor"]

[build-dependencies.protobuf-codegen]
version = "~2.8.1, < 2.9.0"

[build-dependencies.protobuf-codegen-pure]
version = "~2.8.1, < 2.9.0"

I think I might have also needed to manually update the manifest and lockfiles for librespot accordingly, and build it with --features="rodio-backend,with-tremor", but its been several weeks and its not clear from my command history if I did or not.

I definitely had to regenerate/update the lockfile for spotifyd itself, making sure that it listed acceptable versions for protobuf-codegen, protobuf-codegen-pure, and the various librespot crates. I probably did that with cargo generate-lockfile --offline, but again, my command history doesn't indicate whether or not I did it by hand.

To build spotifyd, I had to use the MSVC toolchain rather than GNU toolchain, as I found that no matter what I did, the latter either failed to build, built an executable that simply didn't work, or built an executable I couldn't run; your results may differ.
The actual command I used is rustup run 1.47.0-x86_64-pc-windows-msvc cargo build --release --no-default-features --features="rodio_backend" --manifest ~/.cargo/git/checkouts/spotifyd-36f4565cca355e0b/d119fc3/Cargo.toml.
It may or may not also be possible with the right setup to build and run with the dbus_keyring and/or dbus_mpris features, but I didn't attempt that because just getting spotifyd to run at all was enough for me.

[vincenttermaat]

What needs to be done to get this merged?

[robinvd]

It should atleast be updated to the current master.

[lamaland]

Hi there, any help needed here? Would love to run this daemon on Windows.
Thanks for working on this.

[vincenttermaat]

I am using librespot instead

[CypherpunkSamurai]

Is this PR still active?

[DomingoMG]

Is something known?

[Katzenwerfer]

I believe it is currently preferred to use librespot (which was linked three comments above)

[brian6932]

I built this, and after playing with it for a bit, managed to get it to work.
For anyone on Windows that is getting:

Caught panic with message: attempted to zero-initialize type `librespot_tremor::tremor_sys::ov_callbacks`, which is invalid

Remove librespot's with-tremor feature flag in Cargo.toml
Specifically the 2nd thing here: #719 (comment)
The other methods of getting it to work did not work for me
Can someone please rebase this already, so that we don't have to do these annoying workarounds?

[slondr]

@Katzenwerfer @DomingoMG @CypherpunkSamurai
This PR is fairly old, and has merge conflicts which aren't resolved, plus the author has already disclaimed it. Finally, I'm not sure any maintainer uses Windows to test this.

If someone could get this into a working, mergeable state, I may be able to throw together a Windows box to try it.

[hackedXD]

test

[CypherpunkSamurai]

We need two reviews for this PR to pass. I'll try cloning the branch and testing it out. If anyone else got time please do.

[RakeshChowdhury]

LGTM

[eladyn]

@RakeshChowdhury As has been pointed out in this comment, this PR currently is not mergeable and - up until now - no one has stepped up to fix the conflicts. So unless someone with interest shows up to get it working, this PR is unfortunately not going to happen. :/

[catumin]

My branch here https://github.com/BKasin/spotifyd/tree/windows is rebased against the current commit of master, and seems to be working. Config file paths could definitely be handled better, and I'll have to research windows daemons/services if a better solution for that is desired. But as things stand it seems to work completely fine.

---

What is the preferred way for me to handle getting that branch ready? Should I open a PR or should this one be re-targeted?

[eladyn]

@BKasin thank you for working on this! I haven't had a look yet, but opening a new PR seems like the easiest way forward.
I'm currently not at home (and won't be for some time), but I'll try to at least give feedback an answer any questions you have.

[catumin]

@eladyn can probably close this now that #1219 is merged.