DietPi-Software | ShairPort sync: Not visible as playback device on Mac & i[phone/pad]

[Fourdee]

http://dietpi.com/phpbb/viewtopic.php?f=11&t=746&p=3245#p3244

[Fourdee]

Unfortunately, I do not own any Apple products, so unable to test on those devices.

Although, the installation appears to be working correctly with AirFoil which uses AirPlay protocol:

[Fourdee]

Bug report id 8d48c3f0-ec2a-49dd-a165-0f3d2bbb6aa9-0

[Fourdee]

Does anyone have a Apple device and would be willing to help test it with shairport sync?

[Scoindy]

yip I'm happy to help test; have an iphone and an ipad running ios10 and until I decide for certain that I'm fed up with the 'iosification' of osx and install linux on my macbook pro I can test with that too. I'll get a fresh installation of dietpi with shairport sync running on a pi now

[Fourdee]

@Scoindy
Legend, thank you, appreciate it 👍

[Scoindy]

@Fourdee
have just tested on both my iphone and ipad and it's working perfectly with HDMI audio.

Steps to test:

1. downloaded latest diet-pi image
2. booted, configured wifi, locale, rebooted
3. updated to v134
4. installed shairport-sync, vim, open-ssh, set logging to full
5. started ios music application, played mp3, hit airplay icon and selected Shairport Sync on Dietpi

Is there anything particular you'd like me to test?

[Fourdee]

@Scoindy
Excellent, thanks for running the test, really appreciate it 👍

Is there anything particular you'd like me to test?

The end user reported the shairport player was not available after a reboot. His avahi-daemon logs also indicated a termination.

If you could test the following i'd be grateful:

Install syslog so we can track avahi logs:

apt-get install rsyslog
reboot

After reboot:

• Check you can stream audio from your apple device to DietPi system.
• paste results of cat /var/log/syslog | grep avahi-daemon

[Scoindy]

@Fourdee
still good after a reboot...

I did receive the same message as the end user when I rebooted:

shairport-sync[936]: avahi client failure

but I assume that's just because networking went down before shairport-sync and it's just reporting lost connectivity.
I'm not too familiar with systemd yet and I can't work out how to get it to show the order that services are shutdown (or at least told to shutdown - some take longer than others of course) but I expect it's just the reverse of the startup order, and there's a definite dependency going that way:

interesting that the alsa services failed to start though, I'll see if I can turn on some logging.

I notice from the end user's syslog that his pi is connected using ethernet and I did see a similar issue in the shairport repo [(https://github.com/mikebrady/shairport-sync/issues/182)] where it's suggested that mixing ethernet and wi-fi might cause problems... I'll try replicating here.

[Scoindy]

...still working OK if I disable wifi and use eth0

[Fourdee]

@Scoindy

I notice from the end user's syslog that his pi is connected using ethernet and I did see a similar issue in the shairport repo [(mikebrady/shairport-sync#182)] where it's suggested that mixing ethernet and wi-fi might cause problems... I'll try replicating here.

Great testing and debugging, really appreciate it 👍

I'am just wondering if the user has WiFi + Ethernet enabled at the same time, maybe this is throwing shairport sync/avahi-daemon off.

but I assume that's just because networking went down before shairport-sync and it's just reporting lost connectivity.
I'm not too familiar with systemd yet and I can't work out how to get it to show the order that services are shutdown (or at least told to shutdown - some take longer than others of course) but I expect it's just the reverse of the startup order, and there's a definite dependency going that way:

DietPi takes control of avahi-daemon and shairport sync services (https://github.com/Fourdee/DietPi/blob/master/dietpi/dietpi-services). They are launched after SystemD is finished, using the service /etc/rc.local. At this point, DHCP connections 'should' be completed, however, not guaranteed.

As for checking SystemD ordering, this should do it: http://serverfault.com/questions/617398/is-there-a-way-to-see-the-execution-tree-of-systemd

[Scoindy]

@Fourdee
I've spent a bit of time trying to replicate Guggele’s issue and I'm more puzzled then when I started. With my build, both avahi and shairport come up correctly every time I start the system, and airport works perfectly. I did notice some odd behaviour with the shairport-sync process if I deliberately stop the avahi-daemon to try and mimic the service apparently falling over on Guggele’s system - this would explain why, even if dbus restarted the avahi-daemon, airplay isn't working for him. In the example in the attached document I haven't connected avahi to dbus; I've run out of time to try tonight but I don't think the end result would be different. It still doesn't explain what's causing avahi-daemon to crash of course, but it might shed some light on why it's not working despite both services being up?

shairport-sync.docx

[Scoindy]

@Fourdee

...didn't read your latest post in time...

DietPi takes control of avahi-daemon and shairport sync services (https://github.com/Fourdee/DietPi/blob/master/dietpi/dietpi-services). They are launched after SystemD is finished, using the service /etc/rc.local. At this point, DHCP connections 'should' be completed, however, not guaranteed.

I couldn't work out why there were .service files and /etc/*conf files, but the .service files were disabled. Just had a look at your code and it makes more sense now.

I'am just wondering if the user has WiFi + Ethernet enabled at the same time, maybe this is throwing shairport sync/avahi-daemon off.

I must say that I managed to have both NICs running at the same time I think on the first installation I did, and it caused me a few issues with connectivity and services until I looked at your code and understood how you were controlling the NICs - and stopped trying to manage them directly myself :-)

It might be helpful to have a look at a more complete syslog from Guggele rather than just the avahi-daemon entries?

[Fourdee]

@Scoindy

It might be helpful to have a look at a more complete syslog from Guggele rather than just the avahi-daemon entries?

Yep, sounds like the best move, you up for posting on forums?
User will need to install rsyslog, reboot, try to connect and then log file should be filled with lots of goodies cat /var/log/syslog :)

Failing that, could be a LAN configuration issue (on devices, or router) that is causing this to fail.

[Scoindy]

@Fourdee

yip sure; post here

[Scoindy]

@Fourdee

Hi,

No response to my forum post from the user after a couple of weeks unfortunately; not sure what you usually do in cases like this - mark them as unreproducible or something similar?

[Fourdee]

@Scoindy

yip sure; post here

Excellent 👍

No response to my forum post from the user after a couple of weeks unfortunately; not sure what you usually do in cases like this - mark them as unreproducible or something similar?

Yep, lets mark this as closed as unable to reproduce issue reported by user. We can always reopen if needed.

Thanks for your help on this one 👍