Bring back pipe backend

[mainrs]

#283 removed the pipe backend during the Great Refactoring (TM pending). Might be a good idea to bring it back at some point.

Thinks to take care of:

• Logging to stdout would interfere with this feature. So if --backend pipe is specified and the daemon runs with the --no-daemon flag, all logging would have to happen on stderr instead.
• Add the new backend to the Backend enum.
• Add the needed code to setup.rs (I think this is were the backend logic lies).

"Fixes" #256 by basically providing the functionality in the first place.

[misuzu]

Something like this would be better:

backend = pipe
device = "ffmpeg -re -i - -c:a copy -f rtp rtp://127.0.0.1:1234"

spotifyd would start ffmpeg and pipe audio to ffmpeg's stdin and there would not be any logging issues.

[awerlang]

spotifyd would start ffmpeg and pipe audio to ffmpeg's stdin and there would not be any logging issues.

A new option (pipe_command) could be added for this, as the device should be used to point to a named pipe. I don't think spotifyd should be spawning processes though.

[misuzu]

I've added this feature to librespot-org, should be easy to adapt: librespot-org/librespot#422

[awerlang]

Being "easy to adapt" isn't a good reason to implement a feature.

The proposal for a subprocess backend (there it's a separate backend, a little different than what's proposed here) it's bad solution because then you have to handle failure in the spawned process. If spotifyd fails, then you have to restart both processes.

The pipe backend on the other hand would already allow, when re-integrated, in two ways

1. spotifyd --backend pipe | player ...

• redirect log to stderr, just like any tool have been doing (curl, wget, etc.)

2. spotifyd --backend pipe --device /tmp/musicfifo player /tmp/musicfifo

• both processes can be run as separate users, which is great from a security perspective

Is there an use case where the subprocess backend would help where pipe wouldn't?

[misuzu]

If spotifyd fails, then you have to restart both processes.

This is handled by init system.

Is there an use case where the subprocess backend would help where pipe wouldn't?

You'll need to modify systemd unit to use pipe backend. When stdout consumer crashes, it won't be restarted. With subprocess you'll only need to edit spotifyd's config and consumer restarts will be handled automatically.

[awerlang]

If spotifyd fails, then you have to restart both processes.

This is handled by init system.

Let me rephrase: If spotifyd fails, then both processes have to be restarted. It doesn't matter if such restart is automatic, there's still the instability in one process taking down the other. It doesn't need to be case with the pipe backend.

Is there an use case where the subprocess backend would help where pipe wouldn't?

You'll need to modify systemd unit to use pipe backend. When stdout consumer crashes, it won't be restarted. With subprocess you'll only need to edit spotifyd's config and consumer restarts will be handled automatically.

The subcommand approach requires the single systemd unit to have maximum permissions. With the pipe backend, you can have one system unit, running a separate user, minimal permissions, only one directory and network. Then the playback is either a regular process, or an user systemd service.

In sum, the subcommand backend doesn't add any new capability over the pipe backend, which allows more control over the processes.

[Rohmilchkaese]

Is there anything I can do, to get pipe backend ?
Is someone working on that ?

Just to get you right:
There is no pipe backend implemented at all at the moment ?
Or it just doesn’t get build with pipe support ?

[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.