2014-09-24, 18:29
The photo asset cache is not in gotham - nor in mainline - but it will be added in regard to this fix ...
2014-09-24, 18:58
If i comment out the ios7 renew thingy and use your announcements i still have the problem that we appear as audio only target. Are you sure this works 100% for you?
2014-09-24, 19:02
I'm using XBMC 13.2 with the two code changes you advised here:
http://forum.xbmc.org/showthread.php?tid...pid1800100
Together with two copies of dns-sd run from the command line to make the announcements. (Both have to be left running)
Try that first to see if you can verify my results and work backwards from that.
If the two code changes you suggested above don't disable the 10 second refresh code, then maybe that is needed as well ? What does the refresh do exactly ?
Leaving to go home now so won't be able to do any more testing until tomorrow...
http://forum.xbmc.org/showthread.php?tid...pid1800100
Together with two copies of dns-sd run from the command line to make the announcements. (Both have to be left running)
Try that first to see if you can verify my results and work backwards from that.
If the two code changes you suggested above don't disable the 10 second refresh code, then maybe that is needed as well ? What does the refresh do exactly ?
Leaving to go home now so won't be able to do any more testing until tomorrow...
2014-09-24, 19:26
Perhaps try it with reaanounce still active.
The only thing I can think of is that our work wireless network has bonjour service control - effectively a managed bonjour proxy, that may affect results. Ill have to try it at home on my Mac.
The only thing I can think of is that our work wireless network has bonjour service control - effectively a managed bonjour proxy, that may affect results. Ill have to try it at home on my Mac.
2014-09-24, 19:27
just start the airplay announcement before airtunes. Its the same problem like with ios7. If the client doesn't see the airplay announce before the airtunes it will only show up as audio only. The reannounce feature basically has a mechanism to update the airplay announcement every 10 secs - this leads to the fact that the device sees the airplay announcement after airtunes was started. Starting our announcements with sleep in different order doesn't work as the ios device might be offline / sleeping when we start the services. So thats the reason why we reannounce the airplay announcement every 10 secs. This is still needed for ios8 i think...
2014-09-24, 19:39
I see. Maybe also try my original version where the model number for the two announcements was deliberately different. (Clutching at straws here until I can test it at home 
)
)
2014-09-24, 23:47
new testbuilds - airplay should be fixed for ios8 with this:
The code for the testversion is here:
pull request to mainline: https://github.com/xbmc/xbmc/pull/5410
osx:
http://mirrors.xbmc.org/test-builds/osx/...x86_64.dmg
ios:
http://mirrors.xbmc.org/test-builds/darw...ay-ios.deb
atv2:
http://mirrors.xbmc.org/test-builds/darw...y-atv2.deb
win32:
http://mirrors.xbmc.org/test-builds/win3...irplay.exe
android-arm:
http://mirrors.xbmc.org/test-builds/andr...bi-v7a.apk
I expect the same problems on android as with ios7 clients (xbmc only showing up as a audio target because of the missing re-announce hack for android).
The code for the testversion is here:
pull request to mainline: https://github.com/xbmc/xbmc/pull/5410
osx:
http://mirrors.xbmc.org/test-builds/osx/...x86_64.dmg
ios:
http://mirrors.xbmc.org/test-builds/darw...ay-ios.deb
atv2:
http://mirrors.xbmc.org/test-builds/darw...y-atv2.deb
win32:
http://mirrors.xbmc.org/test-builds/win3...irplay.exe
android-arm:
http://mirrors.xbmc.org/test-builds/andr...bi-v7a.apk
I expect the same problems on android as with ios7 clients (xbmc only showing up as a audio target because of the missing re-announce hack for android).
2014-09-25, 10:06
Memphiz: I haven't tried your builds yet but I'm resuming my test setup from yesterday with access to an iOS 7.1.2 iPad as well as 8.0 and have found a problem.
With features=0x100029FF iOS 8 works fine for video and audio as we know, but iOS 7 only detects an audio device...
With features=0x77 iOS7 and iOS 8 both detect a video device, iOS 7 can send video but iOS 8 can only send audio. (As we also know)
These are all with the new version number of 150.33. I haven't tried the original numbers yet.
So I think we may have to experiment with the features bitmask a bit further to get compatibility with both iOS 7 and 8. (If possible)
Will do some further testing.
With features=0x100029FF iOS 8 works fine for video and audio as we know, but iOS 7 only detects an audio device...
With features=0x77 iOS7 and iOS 8 both detect a video device, iOS 7 can send video but iOS 8 can only send audio. (As we also know)
These are all with the new version number of 150.33. I haven't tried the original numbers yet.
So I think we may have to experiment with the features bitmask a bit further to get compatibility with both iOS 7 and 8. (If possible)
Will do some further testing.
2014-09-25, 11:03
Did you ensure that the airplay announcement is activated AFTER the airtunes announcement in your ios7 tests?
2014-09-25, 11:47
Sorry for the false alarm! After posting I went ahead and installed your Windows test build and saw the same problem - iOS 7 only seeing an audio device.
So suspecting the wireless network configuration I disabled the Bonjour service control system on our wireless controller and re-enabled normal multicast support, and now it works fine on both iOS 7 and iOS 8.
The service control system monitors bonjour broadcasts to build a list of bonjour services and then re-advertises them to individual wireless clients on a different schedule (and also in response to multicast group join requests) and thus "regenerates" all the bonjour packets as it sees fit rather than just passing them through immediately. Not surprisingly this does not seem to play well with the re-advertisement hack that XBMC implements, although apparently iOS 8 is still happy so in this regard iOS 7 seems to be more fussy about the order and timing of announcements than iOS 8.
With normal multi-casting in place I've now tested iOS 6.1.6, (iPhone 3GS) iOS 7.1.2 (iPad Mini with Retina) and iOS 8.0 (iPad 3) with the following:
Video: Instacast, BBC iPlayer, iMDB (trailer playback) Youtube in Safari, video from the camera roll using the Photos app.
Audio: Built in Music app, Spotify.
Pictures: still photos from the photos app.
Everything works fine, I can only find one small issue - when playing camera roll video from the photos app, when you switch to a video (static full screen preview on the iPad screen with the play button in the middle) XBMC shows the static preview image for a moment but then immediately starts buffering the video and starts playing the video even though the iPad play button has not been pressed and is still sitting on the static preview. For some reason it "jumps the gun" and starts the video before instructed.
This is a minor problem that I reported some months ago though and is completely unrelated to the iOS8 bonjour announcement issue, perhaps a shortcoming of the Airplay library used ? It happens with both iOS 8 and iOS 7.
For still photos the photo asset cache seems to work fine so it now displays the correct image from the slideshow.
Both iOS 7 and 8 see an audio only device for a few seconds after XBMC is launched, or the device is woken as before, but once it switches to Video it seems to reliably stay there.
So as far as this specific PR request for iOS 8 compatibility goes it looks very promising, and looks like a backward compatibility switch may not even be needed by the time of release.
I'll give the Mac test build some testing at home over the next few days as I'll be off work until Tuesday.
So suspecting the wireless network configuration I disabled the Bonjour service control system on our wireless controller and re-enabled normal multicast support, and now it works fine on both iOS 7 and iOS 8.
The service control system monitors bonjour broadcasts to build a list of bonjour services and then re-advertises them to individual wireless clients on a different schedule (and also in response to multicast group join requests) and thus "regenerates" all the bonjour packets as it sees fit rather than just passing them through immediately. Not surprisingly this does not seem to play well with the re-advertisement hack that XBMC implements, although apparently iOS 8 is still happy so in this regard iOS 7 seems to be more fussy about the order and timing of announcements than iOS 8.
With normal multi-casting in place I've now tested iOS 6.1.6, (iPhone 3GS) iOS 7.1.2 (iPad Mini with Retina) and iOS 8.0 (iPad 3) with the following:
Video: Instacast, BBC iPlayer, iMDB (trailer playback) Youtube in Safari, video from the camera roll using the Photos app.
Audio: Built in Music app, Spotify.
Pictures: still photos from the photos app.
Everything works fine, I can only find one small issue - when playing camera roll video from the photos app, when you switch to a video (static full screen preview on the iPad screen with the play button in the middle) XBMC shows the static preview image for a moment but then immediately starts buffering the video and starts playing the video even though the iPad play button has not been pressed and is still sitting on the static preview. For some reason it "jumps the gun" and starts the video before instructed.
This is a minor problem that I reported some months ago though and is completely unrelated to the iOS8 bonjour announcement issue, perhaps a shortcoming of the Airplay library used ? It happens with both iOS 8 and iOS 7.
For still photos the photo asset cache seems to work fine so it now displays the correct image from the slideshow.
Both iOS 7 and 8 see an audio only device for a few seconds after XBMC is launched, or the device is woken as before, but once it switches to Video it seems to reliably stay there.
So as far as this specific PR request for iOS 8 compatibility goes it looks very promising, and looks like a backward compatibility switch may not even be needed by the time of release.
I'll give the Mac test build some testing at home over the next few days as I'll be off work until Tuesday.
2014-09-25, 14:15
(2014-09-24, 23:47)Memphiz Wrote: new testbuilds - airplay should be fixed for ios8 with this:After the problems with iOS 7 I didn't believe you would be able to make this work!
[...]
It even works after waking Win7 from sleep although you then have to manually reenable AirPlay on your iDevice. (Pls note I use XBMCLauncher to auto restart Kodi after resuming from sleep.)
Thanks a million Memphiz and DBMandrake! Still no need to buy an AppleTV.
BTW I noticed if (iOS 8 'camera roll') video playback gets stuck, just press Stop on your remote, restart the iOS stock Photos app and AirPlay video playback is fixed.
2014-09-25, 15:23
@AussieFries - all kudos to DBMandrake this time really. He has done the dirty work in finding out the right bits. Implementing this into testbuilds was not even called work imo.
@DBMandrake - well the problem with the cameraroll video which starts to play is not a shortcoming of the used airplay library because for photos and video it is no library involved (its code in our codebase handling all this). What you describe looks like a big change in the airplay protocol to me. Normally ios sends a /play command with the url attached when it wants us to play something. The case you describe is that it sends the /play with url without wanting us to start playback but instead only start buffering.
There is another command called /rate 1/0 which atm is used for pause/unpause playback - might be that i got it all wrong the whole time. I think its really risky to change the airplay code here (e.x. on /play only "save" the url to be played back and wait for /rate 1 to actually start playback).
@DBMandrake - well the problem with the cameraroll video which starts to play is not a shortcoming of the used airplay library because for photos and video it is no library involved (its code in our codebase handling all this). What you describe looks like a big change in the airplay protocol to me. Normally ios sends a /play command with the url attached when it wants us to play something. The case you describe is that it sends the /play with url without wanting us to start playback but instead only start buffering.
There is another command called /rate 1/0 which atm is used for pause/unpause playback - might be that i got it all wrong the whole time. I think its really risky to change the airplay code here (e.x. on /play only "save" the url to be played back and wait for /rate 1 to actually start playback).
2014-09-25, 15:23
(2014-09-24, 23:47)Memphiz Wrote: new testbuilds - airplay should be fixed for ios8 with this:
The code for the testversion is here:
pull request to mainline: https://github.com/xbmc/xbmc/pull/5410
osx:
http://mirrors.xbmc.org/test-builds/osx/...x86_64.dmg
ios:
http://mirrors.xbmc.org/test-builds/darw...ay-ios.deb
atv2:
http://mirrors.xbmc.org/test-builds/darw...y-atv2.deb
win32:
http://mirrors.xbmc.org/test-builds/win3...irplay.exe
android-arm:
http://mirrors.xbmc.org/test-builds/andr...bi-v7a.apk
I expect the same problems on android as with ios7 clients (xbmc only showing up as a audio target because of the missing re-announce hack for android).
Dear Memphiz,
Can you provide testbuilds for Raspberry PI?
2014-09-25, 15:30
Nope jenkins doesn't build rbpi in a distributable way. You need someone in the RBPI forum to build it for you (maybe millhouse adds it to his test builds).
@DBMandrake for the /play vs. /rate thingy - i think i do it right. At least based on the reverse engineered protocol:
http://nto.github.io/AirPlay.html#video-httprequests
It say /play should start playback ...
@DBMandrake for the /play vs. /rate thingy - i think i do it right. At least based on the reverse engineered protocol:
http://nto.github.io/AirPlay.html#video-httprequests
It say /play should start playback ...
