This PR is a preparation for factoring the whole AirPlay/AirTunes stuff out into a python addon.
What this PR does:
Extend the PipesManager to add some sort of plain C interface for using it from Python. PipesManager allows to create a pipe and read or write from/to it. The pipe can be feed into our player with using the pipe:// protocol (this is already used for internal AirTunes).
Expose the PipesManager API via our python interface (getting the object into python by accessing xbmc.PipesManager).
Expose our Zeroconf API via our python interface (allowing addons to announce or deannounce services) - accessible via xbmc.Zeroconf. This is build only when avahi is there on linux. (at least thats what i wanted to accomplish with the buildsys adaptions here haha).
Add the InfoLabels "seekbar, progress, progresscache" which where there already but only hooked up in the GetInt method not in the GetLabel method.
Additions to our Builtin functions:
a. Add "ShowPicture" for showing a single picture given by an URL - its just a wrapper for g_application.getApplicationMessenger().PictureShow(url) which wasn't there before (only slideshow builtins with a folder as argument as of now)
b. New params for the PlayMedia builtin:
* startpercentage= <- for telling the player to start the media at a given percentage (wrapper for the SetProperty of the item)
* mimytype= <- wrapper for item.SetMimeType("audio/blubblibb");
* isradio <- when set - SetProperty("isradio",true) on item
* isfile <- when set - item.m_bIsFolder = false; (opposite of isdir)
* no-skip <- when set - SetProperty("no-skip",true) on item
* no-pause <- when set - SetProperty("no-pause,true) on item
Sounds like much but imho its not very intrusive all in all. I have the python addon ready too. It still depends on libshairport for AirTunes (and will download it after addon installation - same like with boblight). It has identical features like the internal version as of now - but since we are still missing the python ctypes module on iOS - AirTunes is not available. We can get rid of the libplist dependency when finally removing the internal implementation.
Well i think its something we want for the future. It makes it easier to adapt protocol changes or new findings via addon. Also it might be interesting for 3rd party companys who having doubt about legality or something.
No Eden food.
Nice one. Is AirPlay in this implementation on windows still usable without libshairport?
Yes - we still need the libshairport porting for win32.
ahh sorry missread ... its usable without libshairport. When shairport is not found or ctypes is missing it just does the airplay part (video/pictures) only :)
Addon can be found here:
Tbh i'm not really familiar with json-rpc. I know it can be called from within python. When it looks readable enough when called from python i don't have a problem doing it that way. Montellese any thoughts?
I took a quick look at the new parameters and apart from the first one (i.e. startpercentage) which I already planned to add to JSON-RPC's Player.Open method all the other parameters look awfully AirPlay specific and not like something that would be useful to (m)any other clients using JSON-RPC. I'm always trying to keep JSON-RPC as "general" as possible (i.e. not adding anything that is very XBMC-specific) and AFAIK topfs2 is even more strict in that he thinks that other applications would/might like to adopt (parts of) our JSON-RPC API (which will be very difficult with XBMC-specific stuff in it everywhere).
All in all I don't want the JSON-RPC API to become like the Python API which to me looks like an API without any real structure (apart from the stuff that mirrors XBMC-internal classes/interfaces). Everytime something new was needed it was thrown in there somewhere so that it is available ASAP. That makes it look very messy. (I don't wanna step on anyone's toes here and I apologize if I just did, but that's my opinion)
I get that point. But just for defence - these properties where there before airplay. Exposing that SetProperty method of the CFileItem would be enough for doing the trick (mhh beside the mimetype which is not a property somehow). With builtin its not that nice doable, thats why i introduced params for each...
Yeah I know that these properties were there before but I just can't think of (m)any use cases for them (apart from AirPlay obviously). I agree that extending builtin isn't ideal either because that's another mess and adding to a mess usually doesn't make it any better. I also have to admit that I don't understand all the implications that come with setting those properties for a CFileItem before handing it to the player. I'm happy to add any options that make sense in a more common use case (like the startpercentage which has been requested multiple times already).
Generally I think moving AirPlay into an addon is a good idea because it will allow you/us to easier push updates for it.
I never used our python API so bear with me if this is a very stupid question/suggestion. If all these options you need to have available to start playback for AirPlay are properties of a CFileItem why don't you create a xbmc.ListItem object in python and set the necessary options/properties and then create an xbmc.Player object and use xbmc.Player.Play() by passing the URL and the previously created xbmc.ListItem object? That way you should still go through g_application.PlayFile (but not through g_application.PlayMedia in case that's important for you).
Because i don't have that much clue on python either ;). Will dig into this - thx :)
Thx Montellese - no changes to playmedia needed at all now. only the new builtin for ShowPicture (there isn't an api for this in python module either).
Do 727ae21 and fcbe343 need to be reordered (i.e. does everything build at each commit stage?)
8697a2c is fine. IMO both python APIs could do with further review. We want to be completely certain we get this right.
Rebased the PR and fixed the things which jm mentioned (so far possible). Will squash the commits and reorder when i have the go.
Beside that i'm a bit unsure if fore pushing changes the commit order (because IIRC i had bisectability in mind when doing this pr).
Yeah, I'm never sure about the order of how things are listed on github. eg by the looks f30e59c needs to go in after 4fcb033, and 4fcb033 needs to go in before 072f649...
This needs discussion as to exactly what we want to expose to python (and how it should be done).
I'll take care of the right order on the final squash. Hopefully github will take that order then when force pushing my repo.
Someone special we should invite here?
I can't tell you what we want to expose. But i can tell you what i need to be accessible for AirPlay - well every function i've exposed in that PR is needed. :)
[add] - extend pipesmanager for usage via python modul
[python] - expose pipesmanager and zeroconf via python modules
another rebase for keeping the country green
[fix] add missing infolabels they where only in getint
[add] - add builtin "ShowPicture" for showing a single picture given …
…by an URL - its just a wrapper for g_application.getApplicationMessenger().PictureShow(url) which wasn't there before
[pipesmanager] - changes as mentioned by jm
[zeroconf] - changes as mentioned by jm
[add] - integrate the new python modules into the buildsys and hook i…
…nto our xbmc python module
Independently from airplay, is there any chance to have the PipesManager available in Python?
What do you need it for?
I am working on a video/sound/picture calibrating helper addon. For the audio part I need a way to play a within python created PCM stream live in xbmc. This way I could implement some kind of live sinus test tone generator.
Will work on it again after frodo i think.
Memphiz - Frodo is out ;)
I know - but AE is broken on osx like sh... and ios6 makes atv2 unusable with XBMC. This one has low prio ...
If you wanna prepare something then you could try to figure out if loading shared objects (dll's) on android from python is possible (a.k.a. python module ctypes). If not - this would be a showstopper ...
all modules are built-in static, including ctypes.
@Memphiz do you have some love for this when you got back from vacation?
No Plans or working on that atm..
Maybe it was not such a good idea to remove this code.
Related to #698