XBMC has two explicit dependencies to make airplay functionality actually work. The first is that avahi must be enabled, such that the system can announce the existence of the service. Additionally, if avahi was compiled without dbus, airplay will be unable to register itself as a service with avahi-daemon, and airplay will again fail to work as expected. I've confirmed this affects 12.0, have not tested older versions properly, I suspect this also holds true for the 9999 ebuild. Reproducible: Always
Created attachment 339524 [details, diff] proposed 12.0 ebuild changes
Note: This does not address the absence of libshairport (bug 386909) which I intentionally excluded given it has it's own ticket.
I just wanted to emphasize: Although airplay can live without airtunes (libshairport), it will not play back pure audio streams in that case. It will stream videos with audio, pictures, but not pure audio data. The other way 'round, airtunes will not do anything with the absence of airplay. So in order to get the full enjoyment of streaming all kinds of media we will need both airplay and airtunes. This might seem to be strange because airplay is the successor of airtunes and is able to stream the full spectrum of available media on Apple devices. But I **assume** (I really don't know tbh) airplay is based on an enhanced airtunes codebase, so again under the hood we might have both airplay and airtunes again. http://en.wikipedia.org/wiki/AirPlay Again I would like to point to bug https://bugs.gentoo.org/show_bug.cgi?id=386909. I use this ebuild since I created it in 2011 and the overall stability grows with each update of xbmc.
Up stream has merged the unified airplay branch into master. Since then my former ebuild is obsolete but an ebuild for libshairplay is available here: https://bugs.gentoo.org/show_bug.cgi?id=458734
https://bugs.gentoo.org/show_bug.cgi?id=468558 can be considered a replacement for this issue.
