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).