(2012-04-11, 15:51)bradvido88 Wrote: In previous versions on XBMC (early Eden), when listing upnp:// directories (PlayOn is my upnp server in this example), xbmc would return the http:// path to the file in the "file" field.
Previously, i would get a http:// url:
Code:
http://127.0.0.1:63478/netflix-3fafe162-7ea8-4219-a789-c7367386b9d9/1-netflix-3fafe162-7ea8-4219-a789-c7367386b9d9.mpg
In Eden final, I get a upnp:// url
Code:
upnp://9306789e-2927-4a65-a08d-58a4c8337492/netflix%2d4620b511%2ded24%2d4921%2dae3a%2def450a4a07b3
Here is a sample from the xbmc log where i play a upnp:// path and it resolved it to http://
Code:
09:00:32 T:12672 DEBUG: CApplication::OnKey: return (f00d) pressed, action is Select
09:00:32 T:12672 DEBUG: CGUIWindowVideoBase::OnPlayMedia upnp://9306789e-2927-4a65-a08d-58a4c8337492/abc%2d1939a4d1%2d1a83%2d471e%2db529%2d90a690324a02
09:00:32 T:12672 DEBUG: CUPnPDirectory::GetResource - resource protocol info 'http-get:*:video/mpeg:DLNA.ORG_PN=MPEG_PS_NTSC;DLNA.ORG_OP=01;DLNA.ORG_CI=1;DLNA.ORG_FLAGS=25700000000000000000000000000000'
09:00:32 T:12672 DEBUG: CPlayerCoreFactory::GetPlayers(http://127.0.0.1:63478/abc-1939a4d1-1a83-471e-b529-90a690324a02/1-abc-1939a4d1-1a83-471e-b529-90a690324a02.mpg)
09:00:32 T:12672 NOTICE: DVDPlayer: Opening: http://127.0.0.1:63478/abc-1939a4d1-1a83-471e-b529-90a690324a02/1-abc-1939a4d1-1a83-471e-b529-90a690324a02.mpg
The http:// is much more useful to me. Is there any way to resolve the upnp:// path into the http:// path that it references (using JSON-RPC)?
When I play the upnp:// file in XBMC, I can see from XBMC's log that it resolved the upnp:// path to a http:// path, then plays the http:// file.
Problem with returning http in the file object is due to the fact that in accordance with upnp that path could change so its loosy for a client to cache, the upnp path is much nicer as that forces xbmc to do the lookup and decide what protocol to use (a upnp path could end up in several transport options and we can choose which is best, http, rtsp, samba etc and with several transcoding options). I haven't followed xbmc code closely with upnp but I'm guessing this was an internal url change to allow for scanning upnp stuff into the database (as that had the problem before that the http changed).
I'm guessing you want to resolve the upnp url to a http one so you could stream it in your client without going through xbmc? One way to do that would be to actually ask the upnp device about the transports, i.e. you ask it what we ask it. The downside being that you need to be on the same network (which you had to be before too) and that you need to talk upnp (which is actually just xml and http), the biggest problem is that you need to resolve the uuid into an IP, for that you'd need to do an ssdp lookup which requires more than http IIRC.
As for letting xbmc doing this resolve I'm not sure if it would be good, one could append different alternative file paths but knowing that they aren't garantued, kindof how upnp does with the transport. Or have a method you can call to xbmc to do that resolve (might be nicer to just do it in the initial file object fetch.)
EDIT: I guess I'm saying that you'd need to request that our internal filesystem directory calls provides alternative filepaths to the object, much as how upnp does. That way the jsonrpc could report those also. Not sure if we want to add that to our filesystem or not but could be worth a feature request. Might be nice for addon creators to be able to provide alternatives (as with stream details as quality etc.)