2015-03-31, 01:36
Sorry if this is the wrong place to post this, you guys should probably put a link up on the github repo since I saw you don't use GH issues to track bugs (sad panda).
Kodi handling only one client at a time (https://github.com/xbmc/xbmc/blob/7f627f...r.cpp#L447) for it's Airtunes server causes some really nasty race conditions and contention errors...
Steps to reproduce:
Scenario 1-
1. Start Airplay-ing from laptop
2. Close lid/quit itunes/stop playback by any means except manually disconnecting from Kodi via the iTunes airplay selector
3. Attempt to Airplay from any other device
4a. [rare] Airplay will either connect and register as playing on device while Kodi will not show any sort of airplay connection (or)
4b. [most common] Airplay will refuse to connect on second device
Scenario 2-
1. Start Airplay-ing from laptop
2. Stop playback with pause
3. without manually disconnecting from Kodi via the iTunes airplay selector
3. Attempt to Airplay from any other device
4. Airplay works
5. Simply open up laptop/restart iTunes (don't restart playback!)
6. iTunes' more robust Airplay connection management will attempt to re-handshake
7a. Secondary device playback will drop on Kodi (but not the device!)
7b. Secondary device will get a pause command and refuse to restart playback ("Unknown error" in 3rd party iOS 8 apps, iTunes app on iOS 8 will simply silently fail to restart playback)
Odd sidenote: Sometimes after client restarts (iOS is the main culprit here) Airplay will work again, but the album art displayed on Kodi will be from the previous song from when I was attempting to stream pre-restart, so Kodi is definitely getting the data somehow.
Tested using: RaspberryPi B+, last version of raspbmc (before they moved to "osmc"... this bug might be the impetus for me to upgrade though), iPhone 6 w/ latest iOS 8, and MacbookPro w/ OSX 10.10.2 (14C1514)
I believe the correct behavior here should be handling of up to N clients (say 10 for argument's sake) and simply choosing a stream to play based on the last device to issue a command (essentially embracing the inherent race conditions as a feature and allowing the clients to manage scheduling instead of the server). This is how I believe Apple's implementation works.
At the very least the server should at least cleanly and transparently kill the client connection (or maybe just simulate a server failure if apple clients don't have that logic) when it switches clients, this bug wouldn't be so terribly frustrating if my client devices didn't register as streaming/playing as if everything's fine while Kodi acts like Airplay doesn't exist (this is probably some sort of hung connection that's not being realized on the client side).
As a side note, I've been seriously considering and researching building a standalone Airplay/Airtunes server in Go and have the general stuff down but my C++ isn't good enough to grok the protocol specifics that y'all figured out... did you guys just reverse engineer from scratch or is there anywhere that has some specifics/documentation laid out?
Kodi handling only one client at a time (https://github.com/xbmc/xbmc/blob/7f627f...r.cpp#L447) for it's Airtunes server causes some really nasty race conditions and contention errors...
Steps to reproduce:
Scenario 1-
1. Start Airplay-ing from laptop
2. Close lid/quit itunes/stop playback by any means except manually disconnecting from Kodi via the iTunes airplay selector
3. Attempt to Airplay from any other device
4a. [rare] Airplay will either connect and register as playing on device while Kodi will not show any sort of airplay connection (or)
4b. [most common] Airplay will refuse to connect on second device
Scenario 2-
1. Start Airplay-ing from laptop
2. Stop playback with pause
3. without manually disconnecting from Kodi via the iTunes airplay selector
3. Attempt to Airplay from any other device
4. Airplay works
5. Simply open up laptop/restart iTunes (don't restart playback!)
6. iTunes' more robust Airplay connection management will attempt to re-handshake
7a. Secondary device playback will drop on Kodi (but not the device!)
7b. Secondary device will get a pause command and refuse to restart playback ("Unknown error" in 3rd party iOS 8 apps, iTunes app on iOS 8 will simply silently fail to restart playback)
Odd sidenote: Sometimes after client restarts (iOS is the main culprit here) Airplay will work again, but the album art displayed on Kodi will be from the previous song from when I was attempting to stream pre-restart, so Kodi is definitely getting the data somehow.
Tested using: RaspberryPi B+, last version of raspbmc (before they moved to "osmc"... this bug might be the impetus for me to upgrade though), iPhone 6 w/ latest iOS 8, and MacbookPro w/ OSX 10.10.2 (14C1514)
I believe the correct behavior here should be handling of up to N clients (say 10 for argument's sake) and simply choosing a stream to play based on the last device to issue a command (essentially embracing the inherent race conditions as a feature and allowing the clients to manage scheduling instead of the server). This is how I believe Apple's implementation works.
At the very least the server should at least cleanly and transparently kill the client connection (or maybe just simulate a server failure if apple clients don't have that logic) when it switches clients, this bug wouldn't be so terribly frustrating if my client devices didn't register as streaming/playing as if everything's fine while Kodi acts like Airplay doesn't exist (this is probably some sort of hung connection that's not being realized on the client side).
As a side note, I've been seriously considering and researching building a standalone Airplay/Airtunes server in Go and have the general stuff down but my C++ isn't good enough to grok the protocol specifics that y'all figured out... did you guys just reverse engineer from scratch or is there anywhere that has some specifics/documentation laid out?