Shairport-sync: Controlling Play/Pause/Next & Volume. In general and on Cygwin

Created on 7 Feb 2019  ·  58Comments  ·  Source: mikebrady/shairport-sync

For anyone who comes looking for this. I basically ran the following commands.

apt install -y build-essential git xmltoman autoconf automake libtool libdaemon-dev libpopt-dev libconfig-dev libasound2-dev avahi-daemon libavahi-client-dev libssl-dev libsoxr-dev libsndfile1-dev libglib2.0-dev
git clone https://github.com/mikebrady/shairport-sync.git
cd shairport-sync/
autoreconf -i -f
./configure --sysconfdir=/etc --with-alsa --with-pipe --with-stdout  --with-avahi --with-ssl=openssl --with-metadata --with-soxr --with-convolution --with-dbus-interface --with-systemd
make
make install

Then uncommented the line dbus_service_bus = "system"; in /etc/shairport-sync.conf followed by a systemctl restart shairport-sync
Afterwards, I setup a wrapper script

cat > /usr/local/bin/airplay-remote << 'EOF'
dbus-send --system --print-reply --type=method_call --dest=org.gnome.ShairportSync '/org/gnome/ShairportSync' org.gnome.ShairportSync.RemoteControl.$1
EOF
chmod +x /usr/local/bin/airplay-remote

Now I can use airplay-remote Pause/Play/VolumeUp/VolumeDown to control playback.

_Originally posted by @ThisIsQasim in https://github.com/mikebrady/shairport-sync/issues/223#issuecomment-441758016_


I found the remarkable post above buried in an old thread.
I cannot get a grip if this is common knowledge and if there is code available or not.
1) would appreciate a lot if someone could point to some simplified code that works.
2) my need is to compile on Cygwin. Will the solution still work? I am ok without volume control. What do I need to do in order to get it to work? (Unexperienced)
Many thanks!

(My needs are to do this on a Windows platform.)

All 58 comments

Yes, the post you refer to is using a new-ish facility that Shairport Sync has. It's still a bit rough and there's no real documentation yet. It requires Avahi because it needs to identify the remote control parameters of the audio source, and only Avahi provides the facilities for getting them.

However, with Avahi and with the --with-dbus-interface configuration option, you can send D-Bus messages to Shairport Sync as detailed in the OP. They will be relayed to the audio source.

I am really a newbie to Linux, but a happy surfer....
https://cygwin.com/packages/x86_64/avahi/
https://cygwin-ports-general.narkive.com/2ojP2VUF/avahi-and-cygwin
There seems to be some sort of Avahi available for Cygwin?
Would including it be a way forward or a way to mess things up...
Is alsa also required?

So, if Cygwin can accommodate Avahi, then the remote control stuff might work.

However, as advised in another post, without alsa you are not going to get synchronisation, so sooner or later you'll get overflow or underflow, resulting in an audio discontinuity which will be audible.

I don't know enough about Cygwin, but my guess is that alsa can't be made to work on it.

Shairport with metadata is fantastic for multiroom keypad supported audio like I have (multichannel amplifier).
Pls excuse my low experience, but my (naive) thinking was to add a few libraries to the successful Cygwin install that I now have.
I went through the commands above by @ThisIsQasim and documented:

Not available on Cygwin:

  • alsa
  • libasound2-dev

Possibly available on Cygwin:

  • libconfig-dev
  • libssl-dev

Already available on Cygwin:

  • build-essential (not as package)
  • git
  • xmltoman
  • autoconf
  • automake
  • libtool
  • libdaemon-dev
  • libpopt-dev

So, my question is if above is enough for the remote control function?
Play / Pause / Next would be the main focus.
That's all I need as the audio works fine already and the metadata is perfect.
(Do not necessarily need synchronization as my amp is common.)

So, I tried compiling despite alsa and libsound.

I think(?) I got pretty far, but have no clue really.... :-)
I have cut out two blocks of errors below:

beli@HemmaServer ~/shairport-sync
$ PKG_CONFIG_PATH=/usr/local/lib/pkgconfig ./configure --with-ao --with-ssl=openssl --with-tinysvcmdns --with-pipe --with-stdout --with-avahi --with-metadata --with-soxr --with-dbus-interface --with-systemd

....

Including an AO back end. N.B. no synchronisation -- so underflow or overflow is inevitable!
checking for ao_initialize in -lao... yes
Including dbus support
checking for GIO_UNIX... yes
Including the metadata hub
Including the DACP client
Package systemd was not found in the pkg-config search path.
Perhaps you should add the directory containing `systemd.pc'
to the PKG_CONFIG_PATH environment variable
No package 'systemd' found
checking for xmltoman... xmltoman
checking how to run the C preprocessor... gcc -E
.....

beli@HemmaServer ~/shairport-sync
$ make install

make install-recursive
make[1]: Entering directory '/home/beli/shairport-sync'
Making install in man
make[2]: Entering directory '/home/beli/shairport-sync/man'
make[3]: Entering directory '/home/beli/shairport-sync/man'
make[3]: Nothing to be done for 'install-exec-am'.
/usr/bin/mkdir -p '/usr/local/share/man/man7'
/usr/bin/install -c -m 644 shairport-sync.7 '/usr/local/share/man/man7'
make[3]: Leaving directory '/home/beli/shairport-sync/man'
make[2]: Leaving directory '/home/beli/shairport-sync/man'
make[2]: Entering directory '/home/beli/shairport-sync'
make[3]: Entering directory '/home/beli/shairport-sync'
/usr/bin/mkdir -p '/usr/local/bin'
/usr/bin/install -c shairport-sync.exe '/usr/local/bin'
make install-exec-hook
make[4]: Entering directory '/home/beli/shairport-sync'
[ -e /usr/local/etc ] || mkdir /usr/local/etc
cp scripts/shairport-sync.conf /usr/local/etc/shairport-sync.conf.sample
[ -f /usr/local/etc/shairport-sync.conf ] || cp scripts/shairport-sync.conf /usr/local/etc/shairport-sync.conf
cp scripts/shairport-sync-dbus-policy.conf /usr/local/etc/dbus-1/system.d/shairport-sync-dbus.conf
getent group shairport-sync &>/dev/null || groupadd -r shairport-sync >/dev/null
/bin/sh: groupadd: command not found
make[4]: * [Makefile:1159: install-exec-hook] Error 127
make[4]: Leaving directory '/home/beli/shairport-sync'
make[3]:
[Makefile:1078: install-exec-am] Error 2
make[3]: Leaving directory '/home/beli/shairport-sync'
make[2]:
[Makefile:1016: install-am] Error 2
make[2]: Leaving directory '/home/beli/shairport-sync'
make[1]:
[Makefile:713: install-recursive] Error 1
make[1]: Leaving directory '/home/beli/shairport-sync'
make: *
* [Makefile:1010: install] Error 2

beli@HemmaServer ~/shairport-sync
$

Any suggestions for my ambition?

By replacing systemd with systemv, I could avoid the first error.
$ PKG_CONFIG_PATH=/usr/local/lib/pkgconfig ./configure --with-dbus-interface --with-systemv --with-ao --with-ssl=openssl --with-tinysvcmdns --with-pipe --with-stdout --with-avahi --with-metadata

"Make" works fine, but "Make Install" is still a problem. "groupadd -r" crashes.
Is there some other way of doing that?
...
cp scripts/shairport-sync-dbus-policy.conf /usr/local/etc/dbus-1/system.d/shairport-sync-dbus.conf
getent group shairport-sync &>/dev/null || groupadd -r shairport-sync >/dev/null
/bin/sh: groupadd: command not found
make[4]: * [Makefile:1159: install-exec-hook] Error 127
make[4]: Leaving directory '/home/beli/shairport-sync'
make[3]:
[Makefile:1078: install-exec-am] Error 2
make[3]: Leaving directory '/home/beli/shairport-sync'
make[2]:
[Makefile:1016: install-am] Error 2
make[2]: Leaving directory '/home/beli/shairport-sync'
make[1]:
[Makefile:713: install-recursive] Error 1
make[1]: Leaving directory '/home/beli/shairport-sync'
make: *
* [Makefile:1010: install] Error 2

To be honest, I think you are trying to do things with Cygwin that will run up against its limitations and simply leave you frustrated. The lack of synchronisation means that the system, even if you got it working, will always suffer from occasional "hiccups" when a buffer overflow or underflows somewhere. If I were in your shoes, I'd be looking at a standard Linux running on a real machine; even a Raspberry Pi Zero W.

Please forgive me, but now I am confused?! Shairport-sync as such works very nicely and according to your installation instructions on Windows/Cygwin. I am very happy so far. It appears quite stable!

Unfortunately, working off another device is not really an option for me as I want/need to keep several services on the same machine.

You have mentionned sound and synchronization as a possible issue a few times. Let's imagine that the sound continues as well as now...Then, please enlighten me, why would it not be possible to do the simple remote control functions in parallel as with the metadata?
Do you expect more problems ahead other than Cygwin not recognizing the "groupadd" command?

Found this:
https://superuser.com/questions/1169450/groupadd-command-not-found-in-cygwin/1169635#1169635
You cannot add a Windows user via Cygwin. You will have to create the user in Windows, than add the user details to Cygwin by running mkpasswd -l > /etc/passwd .
The user group details can be added by running mkgroup -l > /etc/group.

--with-systemv causes the crash
In the Makefile it seems like I only have the following 6 commands left:

getent group shairport-sync &>/dev/null || groupadd -r shairport-sync >/dev/null
getent passwd shairport-sync &> /dev/null || useradd -r -M -g shairport-sync -s /usr/bin/nologin -G audio shairport-sync >/dev/null
[ -e /var/run/shairport-sync ] || mkdir -p /var/run/shairport-sync

chown shairport-sync:shairport-sync /var/run/shairport-sync
[ -e $(DESTDIR)$(sysconfdir)/init.d ] || mkdir -p $(DESTDIR)$(sysconfdir)/init.d
[ -f $(DESTDIR)$(sysconfdir)/init.d/shairport-sync ] || cp scripts/shairport-sync $(DESTDIR)$(sysconfdir)/init.d/`

I would imgine that groupadd, useradd and possibly chown will be problematic and need to be rewritten.
Any suggestions on how to move forward on this?
Do I really need to add/change rights if I run everything as Administrator on Windows?

I got the avahi and d-bus daemons (services) running (a few easy manual commands).
Then commented out the three Cygwin non-supported command lines above (groupadd, useradd and chown) to see what happens:
--> Shairport-Sync installs, can be started, seen on the network, connected to and delivers sound. Great!

When starting up Shairport-sync, I get this error:
Could not acquire a Shairport Sync native D-Bus interface "org.gnome.ShairportSync.i3316" on the system bus.

Mike, am I getting closer?
Thank you,
Bob

Here is more from the log:
(verb3)
....
zeroconf regtype is "_raop._tcp".
decoders_supported field is 1.
use_apple_decoder is 0.
alsa_use_hardware_mute is 0.
no special mdns service interface was requested.
configuration file name "/usr/local/etc/shairport-sync.conf" resolves to "/usr/local/etc/shairport-sync.conf".
loudness is 0.
loudness reference level is -20.000000
disable resend requests is off.
diagnostic_drop_packet_fraction is 0.000000. A value of 0.0 means no packets will be dropped deliberately.
setting dacp_server_active and advanced_dacp_server_active to 0 with an update flag value of 0
avahi: service '3BE7548BC13C@HemmaServer' group is not yet committed.
avahi: request to add "_raop._tcp" service without metadata
avahi: service '3BE7548BC13C@HemmaServer' group is registering.
Could not acquire a Shairport Sync native D-Bus interface "org.gnome.ShairportSync.i3316" on the system bus.
avahi: service '3BE7548BC13C@HemmaServer' successfully added.

When connecting an iDevice:
New RTSP connection from 192.168.1.141:51407 to self at 192.168.1.180:5000 on conversation thread 1.
Successfully created RTSP receiver thread 1.
CSeq: 0.
DACP-ID: CAAED94E3DFC0AFF.
Active-Remote: 2806630310.
User-Agent: AirPlay/371.4.7.
RTSP thread 1 received an RTSP Packet of type "OPTIONS":
Type: "CSeq", content: "0"
Type: "DACP-ID", content: "CAAED94E3DFC0AFF"
Type: "Active-Remote", content: "2806630310"
Type: "User-Agent", content: "AirPlay/371.4.7"
Connection 1: OPTIONS
RTSP thread 1: RTSP Response:
Type: "CSeq", content: "0"
Type: "Server", content: "AirTunes/105.1"
Type: "Public", content: "ANNOUNCE, SETUP, RECORD, PAUSE, FLUSH, TEARDOWN, OPTIONS, GET_PARAMETER, SET_PARAMETER"

When disconnecting an iDevice:
RTSP conversation thread 1 -- connection closed.
Synchronously terminate playing thread of RTSP conversation thread 1.
player_stop
player_thread_lock acquired
player thread of RTSP conversation 1 is already deleted.
Successful termination of playing thread of RTSP conversation thread 1.
Request termination of RTSP conversation thread 1.
Connection 1: RTSP thread terminated.

When shutting down (ctrl-c)
shutdown requested...
avahi: avahi_unregister.
Request to shut down all rtsp conversation threads
asking playing threads to stop

Well, you’ve made a lot of progress. Let me check some stuff out and get back to you.

Thank you very,very much Mike!

Perhaps(?), a last problem: Having the same name for groups and users is not possible in Windows.
User: shairport-sync
Group: shairport-sync

Any way to get around this?

"Linux/UNIX has a separate name space for users and groups. Users are identified by their uidNumber; groups by their gidNumber. Under Linux/UNIX a user name and a group name are in separate name spaces. Not so with MS Windows - users and groups share a common name space. User accounts and group accounts are identified internally (and externally) by their SID (security identifier)."

You don't need the --with-system* stuff at all.

I've been using:

PKG_CONFIG_PATH=/usr/local/lib/pkgconfig ./configure --with-ao --with-ssl=openssl --with-avahi --with-dbus-interface

Can you say what packages you chose to install avahi please? And how did you get it to start as a service?

1) Great news to not need ---with system*.

2) I basically chose everything called avahi :)
avahi

3) Getting the services to work:

Making the daemons work
In order for the system daemons to work, Windows must be told how to start them, and when. Here are the steps needed for the various daemons. Please make sure that LSA authentication is installed (see above) and Windows was rebooted. Further the dummy users mentioned above should be set up already.

Cygwin Server
This is needed for IPC message queues, semaphores and shared memory support. More information is available on the Cygserver page.

user $/usr/bin/cygserver-config
Just follow the on-screen information.
Go into the windows services panel and search for "CYGWIN cygserver".
In its properties Change "Startup type" to "Automatic (Delayed Start)". The normal automatic start may be too fast. If it is, you get weird UID->Name resolutions.

dbus system bus
It is good to have a system bus. Most applications run fine with a session bus only, but a system bus makes live much easier.

user $/usr/bin/messagebus-config
Just follow the on-screen information
Go into the windows services panel and search for "CYGWIN D-Bus system service".
In its properties Change "Startup type" to "Automatic (Delayed Start)".
Open a command (CMD) prompt with administrator privileges and add cygserver to the dependencies:
C:\WINDOWS\system32>sc config messagebus depend= cygserver
The depend= is a keyword, there really must be a space between it and the dependency list!

Avahi Daemon

user $/usr/sbin/avahi-daemon-config
Just follow the on-screen information.
Go into the windows services panel and search for "CYGWIN Avahi service".
In its properties Change "Startup type" to "Automatic (Delayed Start)".
Open a command (CMD) prompt with administrator privileges and add dbus to the dependencies:
C:\WINDOWS\system32>sc config avahi-daemon depend= messagebus

Many thanks. It’ll be late tomorrow before I can get back to it, but that’s very useful.

Brilliant!

Not --with-tinysvcmdns and --with metadata?

Avahi replaces tinysvcmdns and with-dbus-interface automatically includes metadata.

Having a proper look at this today. I spent much of yesterday getting a clean version of Windows and Cygwin ready...

I have been successful so far on Win 7 32-bit.
I read some old blog (2012) about needing Bonjour together with Avahi daemon on windows.
Bonjour is easy to install and most iDevice users have it already. But perhaps not your clean set-up.
https://cygwin.com/ml/cygwin-announce/2012-04/msg00008.html

Thanks. I’m making some slow but steady progress on this, trying to do it in an orderly way. No result yet though.

Well, I've made no headway on this. The problem is that I can not configure Cygwin to work with a D-Bus and an Avahi service, using the latest Windows 10 (Education) and the latest Cygwin 64. I may try again next week, but have had no luck at all this week. Otherwise, Shairport Sync compiles and begins correctly. Very frustrating.

Is there something I can do/test?
From my logs this appears to work on my configuration, right?

Thanks, yeah, it seems to be working in your case, though I'm not absolutely certain. Is there anything that you do with your network settings to get it to work, or is there anything special about your settings? (I'm running Windows 10 inside a VMWare virtual machine, so that may be a factor, though I think it is very unlikely.)

Nothing special that I can think of.
Win7 32bit
Latest Cygwin, etc...
Installed Shairport-sync according to your instructions
(3.2.2-OpenSSL-Avahi-ao-dbus-sysconfdir:/usr/local/etc)
Have very old Bonjour running (3.0.0.10)
Followed the manual daemon instructions
Enabled firewall for shairport-sync
RDP
I did create group: shairport and user: shairport-sync (but that was after I sent the first log)

I have two very similar Win7 32 machines and could maybe run Cygwin on my WIn10 laptop, although I am out of space. Would require alot of moving around files....
(Maybe I could format a third virgin Win7 32 and let you RDP to it (fiber). Would take a day or two).

How could I test that it is working or provide you with some log?

Thanks, but don’t trouble yourself, yet. I will try a real laptop next week and see what happens.

Okay, so progress at last. I have a reliable way to get a working Cygwin on a clean Windows 10 with a D-Bus and an Avahi service that runs.

That

Could not acquire a Shairport Sync native D-Bus interface "org.gnome.ShairportSync.i3316" on the system bus.

message is there alright. It is a permissions issue. I'll need to look at how permissions are handled in Cygwin. But at least, now I can!

So, some more progress. A full compilation and installation works, and I've even been able to install it as a service, and it works!

image
However, I still haven't got the D-Bus connection going. There is definitely a system D-Bus in operation -- Avahi is using it -- but SPS isn't able to connect to it, even though its permission file looks right. More investigation needed...

Is the Cygwin Server also necessary?
https://wiki.gentoo.org/wiki/Prefix/Cygwin/X#Making_the_daemons_work
EDIT: I have found "Delayed Automatic" useful in other circumstances as well although it is agreebly not the root problem.
Could the permission issue be related to group/user naming?

Yes, as far as I know, the program cygrunsrv needs to be there. That link was a very useful starting point but the suggestions are over-complex for what we need. I'm building a guide. Apart from the D-Bus problem, when Windows finishes starting up, the Shairport Sync service is automagically running. Pretty cool.

So, yes, it seems that the user SYSTEM is unable to provide a D-Bus service. If the user is something other than SYSTEM, the D-Bus service appears and works. It may be necessary to create an unprivileged user. Looking at that now...

I have 1 service called CYGWIN cygserver running and
3 cygrunsrv processes and 1 cygserverprocess running
(no sharepoint-sync daemon running.)
Avahi and D-Bus have running processes AND services (Avahi-daemon and messagebus).
All above are SYSTEMowned

It’s going to take another day or so to put a script together. Where/how are you seeing these processes?

In the Task Manager.
Does that mean that you have identified a solution?

If I’m not mistaken, it’s not a problem. When I look in the Services application, it shows the DBus service, the Avahi service and the AirPlay service. I need to do a little more investigation and stick it all in an installer. So yeah, I think I have the makings of a solution.

Are you saying that by changing permissions to full control for Avahi, Dbus and Cygwin processes to either:
SYSTEM
or
USER
or
Everyone
it could work?
How about ownership?

I could give that a manual try?

No, I’m not sure yet, but not SYSTEM. Also, you need an installer script.

Hmm, it's still resisting me!

Well, I have still not been able to get Shairport Sync, when installed as a Cygwin Service, to be able to provide a D-Bus service. It looks like some kind of an issue in the D-Bus library Shairport Sync is using.

Anyway, I've added a Cygwin installer and updated the CYGWIN.md page to reflect everything learned over the past week or so. It's in the development branch.

Summarising: we can now install a Shairport Sync-based AirPlay service in Cygwin, but it doesn't offer a D-Bus interface.

Mike, first of all, many thanks for your great effort! I am impressed by your drive and diligence!

A few comments to your new write-up:

  • Really cool with the service! 👍
  • I did notice in the install process that I posted above that Cygwin, Avahi and the Dbus were linked through dependencies.
    Not sure what the meaning of this is, but is it something to consider?
  • I think I can recommend (at least on Win7) to set the Firewall to report/ask when it is sensing new communication during the installation (from Shairport-Sync). Thereby you get an assisted configuration of the firewall.

Secondly, I do hope that you will gravitate back to this issue very soon. Perhaps out of pure frustration of being so close!
Thirdly, I really want to help to solve this enigma, but am not sure how I can best help?

Excuse my naive question, but would it be possible to swap the DBus library and see if would help to at least gain access?
Do you still think that there is a permission issue or is there some other sort of API issue?
I would be happy to try to find insights elseware to help move the solution forward, but would need some pointers.

Many thanks,
Bob

Thanks Bob.

  • It's kinda nice to see it showing up as a Windows Service, even without the D-Bus interface.
  • The dependencies are there and they are unavoidable, I'm afraid. But there's nothing to be concerned about.
  • I might have a look at the Firewall thing, but my suggestion has the merit of being is straightforward. People who know better can take their own route.

To be honest, I really don't know what the problem could be. It could be a missing library, or it could be a mistake somewhere, the fact that the Avahi D-Bus interface works is very interesting. Swapping the D-Bus libraries would be a really difficult thing to do. D-Bus documentation is hopeless beyond description. A better approach is to try both libraries in a small application and try to see what is happening (this is computer development as a natural science!). Even then, it might turn out to be better to wait for a fix if it is a library problem. I've tried to contact the Cygwin guys to see if they might have any suggestions.

Great that you have reached out to the Cygwin guys!
Are there any “dbus guys”? 😜😁

I actually meant that the dependencies were set manually in the described process and not in your installation manual. A good or bad difference? A solution?🎅🏻

There are D-Bus guys alright, but it’s not at all clear that it’s their problem.

Regarding dependencies, they are actually written into the respective config scripts. So the order of installation is important, and when starting up they will be started in the right order.

I noticed your thread over att Cygwin.
Did you get any good ideas or pointers?
Anything I can do to raise attention?

Well, I got a response, but I need to create a little app that shows the problem a bit more clearly. First, though, I need to get the latest version of SPS out, and have some actual work (!) to do...

Hello Mike,
I have not really moved on and rely on a poor Airplay implementation that produces noise.
Shairport works much better.
Still interested if you could get the dbus moving...
Thx!

Thanks for the reminder – I haven't pursued this properly, so I'll get back to it shortly.

Hi there. I've put a question and (finally) offered some sample code to the Cygwin list regarding the D-Bus issue. It may take a good while to get an answer, as I'd say this is an issue that falls between the Cygwin people and the GDBus people...

Jumping in here, unrelated to Cygwin, but maybe helpful. Let me know if I should post this elsewhere.

I need a way to stop Shairport when another audio app wants to play. I’ve been restarting the service, but that seems a bit heavy.

In one of my other audio playback apps, I listen for messages on a pipe. For MPD, I can simply call “mpc stop”. So in the Shairport config, I simply call a script on start that handles stopping the other players.

2 questions:

  1. How do I go about stopping Shairport? With this dbus method (using busybox on a buildroot build, not sure I even have dbus).
  2. Might it be easier to just build a simple control mechanism into the code to solve the issue for @OneBobone (and me?)

Actually, I do have dbus, but get this:

`# dbus-send --system --print-reply --type=method_call --dest=org.gnome.ShairportSync '/org/gnome/ShairportSync' org.g
nome.ShairportSync.RemoteControl.Play

Error org.freedesktop.DBus.Error.ServiceUnknown: The name org.gnome.ShairportSync was not provided by any .service files
`

Hi Kevin. Thanks for the posts. However, they are unrelated to this issue with Cygwin, which seems to have a D-Bus issue of its own.

There is no "simple control mechanism" to stop Shairport Sync for the following two reasons.

  1. Shairport Sync can't really be compared to mpd because it is not a self-contained player like mpd. It is controlled by a separate "client" music player such as iTunes, etc. The natural way to control Shairport Sync is to control the client. Shairport Sync can influence the client using a limited set of remote control commands.

  2. Shairport Sync runs in the background as a daemon. The only way to reach it is by some IPC mechanism, and D-Bus seems to be the most flexible. MQTT is another possibility (for which Shairport Sync also has an interface).

It follows that sending a D-Bus or an MQTT message to Shairport Sync which is relayed as a remote control "stop" command to the client is a reasonable and non-kludgy way to go about getting Shairport Sync to stop playing.

Regarding the D-Bus error you report above:

  1. Make sure you have compiled Shairport Sync with D-Bus support.
  2. Make sure a correct D-Bus policy file has been installed – there is quite a bit of security regarding access to the D-Bus "system" bus.

Hi Mike, thanks for the rest of the info.

I got past the initial error by creating the policy file and a simple .service file in the my /usr/share/dbus-1/system-services/ folder.

Does this service need to actually be the one that starts Shairport-Sync? I use SystemV, and typically start services with start-stop-daemon.

Good stuff. AFAIK, the service doesn't need to be the one to start the application. In a systemd system, the Shairport Sync daemon is started in the normal way with a systemd init script and has no entry in /usr/share/dbus-1/system-services/.

Let me track down how buildroot configures things. I know dbus is working, but not sure if the proper config flags are set for the build

I needed to add the flag to buildroot.

Now I get this:

# dbus-send --system --print-reply --type=method_call --dest=org.gnome.ShairportSync '/org/gnome/ShairportSync' org.gnome.ShairportSync.RemoteControl.Play

Error org.freedesktop.DBus.Error.UnknownMethod: No such interface “org.gnome.ShairportSync.RemoteControl” on object at path /org/gnome/ShairportSync

Solved it. Though not clear on all the details as to how. Seems to work when the service is loaded by my /etc/init.d/ but not by the EXEC parameter in the dbus service file.

Good that you got it working. If you got a moment to record what you did it might be useful to some other users.

Great stuff, thanks.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

purefan picture purefan  ·  5Comments

ContraVarus picture ContraVarus  ·  7Comments

fundix picture fundix  ·  3Comments

LinusU picture LinusU  ·  4Comments

rockrabbit picture rockrabbit  ·  6Comments