2014-09-28, 21:57
Not directly related to the problem at hand, but I was experimenting with a custom build of 13.2 with tweaked airplay announcements for my daily use (I'm not ready to start using Helix for regular use yet) so that I could at least use video and audio airplay again, even if photos didn't work properly. (I don't use photos so don't mind)
It was also bothering me that we changed a number of things and that we weren't 100% certain how many of those changes were actually needed - I couldn't help experimenting with the announcements again and tried reverting srcvers back to 101.28 and vs to 130.14 - as they originally were in Gotham but keeping the new features bitmask. It still worked absolutely fine on iOS 7 and iOS 8 - I couldn't tell any difference.
It looks like all the secret sauce of getting it to work with iOS 8 is in the features bitmask, so if you want to simplify the code change in your PR and minimise the impact it doesn't seem necessary to advertise later version numbers as we first thought - this also avoids a potential issue in the future where one version is advertised and another reported when connecting - at the moment that doesn't seem to cause a problem but who knows what might happen in the future with a version mismatch.
Here's my theory on how the various parameters are interpreted by the client:
If the model is reported as a known version of the AppleTV, eg AppleTV2,1 or AppleTV3,1 the features bitmask is ignored and the supported feature set is derived from the version numbers - eg Apple knows that an Apple TV reporting 130.14 supported certain features, while 150.33 supported an increased set of features. There's no need for the client to check the bitmask (even though the AppleTV probably sets it) because Apple control the firmware versions and features of the Apple TV. So the bitmask gets ignored.
If the model is reported as an unknown model such as Xbmc,1 (3rd party vendor) then the version numbers don't matter as much or perhaps don't even matter at all. In the case of an unknown model the bitmask is used instead.
I spent a couple of hours tonight trying individual bits in the bitmask to get a better sense of what's going on - I tried both going backwards from a known working bitmask of 0x100029FF and forwards from the known broken bitmask of 0x77.
The first thing I discovered is that we don't need to set the bit for photo asset caching
At least not with the old version numbers re-instated. By turning bit 13 off the photo library now works properly with 13.2, so you may not need to implement the photo asset library at all - it certainly doesn't seem any slower to me without it. (Maybe keep it in your back pocket though in case it ever does become mandatory)
Next thing I tested was removing bit 31 - it's not documented and I can't find any change when disabling it. I then tried disabling mirroring (bit 7) and videofairplay (bit 2) both individually and together. The results are:
2 and 7 both off: detected as a video device but both video AND audio fail to work.
2 off, 7 on: video works but audio does not! (disabling the videofairplay bit kills audio for some reason)
2 on, 7 off: (this is original XBMC) audio works but video does not.
2 on, 7 on: both audio and video work.
I then decided to work forwards from 0x77 to see what the absolute minimally intrusive change is that fixes the iOS 8 issue.
It turns out it's very simple - changing features from 0x77 to 0xF7 (turning on bit 7 for mirroring) is the ONLY change needed! No other mystery bits, no changes to version numbers, no changes to model numbers, no photo cache support code required. A single line patch to restore functionality to the same level that we had with iOS 7.
I've also tested 0xF7 with iOS 7 and iOS 6 - they are all working for audio, video, photos. IMHO this single bit change in the bitmask should be enough of a no brainer to go even into Gotham, if another maintenance release of Gotham is planned...(if not, Helix I guess) It is certainly going into my own custom build of Gotham.
Of course this doesn't address the separate issue you're looking at with rate support for the photos app, but that is a more intrusive fix and as yet we haven't got to the bottom of what's going on in the photos app even though honouring the rate in the initial connection does seem to be the right thing to do....but not the whole solution.
It was also bothering me that we changed a number of things and that we weren't 100% certain how many of those changes were actually needed - I couldn't help experimenting with the announcements again and tried reverting srcvers back to 101.28 and vs to 130.14 - as they originally were in Gotham but keeping the new features bitmask. It still worked absolutely fine on iOS 7 and iOS 8 - I couldn't tell any difference.
It looks like all the secret sauce of getting it to work with iOS 8 is in the features bitmask, so if you want to simplify the code change in your PR and minimise the impact it doesn't seem necessary to advertise later version numbers as we first thought - this also avoids a potential issue in the future where one version is advertised and another reported when connecting - at the moment that doesn't seem to cause a problem but who knows what might happen in the future with a version mismatch.
Here's my theory on how the various parameters are interpreted by the client:
If the model is reported as a known version of the AppleTV, eg AppleTV2,1 or AppleTV3,1 the features bitmask is ignored and the supported feature set is derived from the version numbers - eg Apple knows that an Apple TV reporting 130.14 supported certain features, while 150.33 supported an increased set of features. There's no need for the client to check the bitmask (even though the AppleTV probably sets it) because Apple control the firmware versions and features of the Apple TV. So the bitmask gets ignored.
If the model is reported as an unknown model such as Xbmc,1 (3rd party vendor) then the version numbers don't matter as much or perhaps don't even matter at all. In the case of an unknown model the bitmask is used instead.
I spent a couple of hours tonight trying individual bits in the bitmask to get a better sense of what's going on - I tried both going backwards from a known working bitmask of 0x100029FF and forwards from the known broken bitmask of 0x77.
The first thing I discovered is that we don't need to set the bit for photo asset caching
At least not with the old version numbers re-instated. By turning bit 13 off the photo library now works properly with 13.2, so you may not need to implement the photo asset library at all - it certainly doesn't seem any slower to me without it. (Maybe keep it in your back pocket though in case it ever does become mandatory)Next thing I tested was removing bit 31 - it's not documented and I can't find any change when disabling it. I then tried disabling mirroring (bit 7) and videofairplay (bit 2) both individually and together. The results are:
2 and 7 both off: detected as a video device but both video AND audio fail to work.
2 off, 7 on: video works but audio does not! (disabling the videofairplay bit kills audio for some reason)
2 on, 7 off: (this is original XBMC) audio works but video does not.
2 on, 7 on: both audio and video work.
I then decided to work forwards from 0x77 to see what the absolute minimally intrusive change is that fixes the iOS 8 issue.
It turns out it's very simple - changing features from 0x77 to 0xF7 (turning on bit 7 for mirroring) is the ONLY change needed! No other mystery bits, no changes to version numbers, no changes to model numbers, no photo cache support code required. A single line patch to restore functionality to the same level that we had with iOS 7.
I've also tested 0xF7 with iOS 7 and iOS 6 - they are all working for audio, video, photos. IMHO this single bit change in the bitmask should be enough of a no brainer to go even into Gotham, if another maintenance release of Gotham is planned...(if not, Helix I guess) It is certainly going into my own custom build of Gotham.
Of course this doesn't address the separate issue you're looking at with rate support for the photos app, but that is a more intrusive fix and as yet we haven't got to the bottom of what's going on in the photos app even though honouring the rate in the initial connection does seem to be the right thing to do....but not the whole solution.
