[KenV99]

Hi,

When attempting to play LiveTV via an external player using playercorefactory.xml, the filename passed as an argument is not translated into an os-specific path.

As an example, when I tune to CNN using DVDPlayer, in the debug log, I can see that the initial designation is "pvr://channels/tv/All TV channels/55.pvr" and then there is a line stating:
"DEBUG: AddOnLog: Windows Media Center Client - wingl windx x86 Edition: OpenLiveStream> opening stream: smb://HTPC-W7/Users/Public/Recorded TV/TempSWMC/LiveTV_EinsteinsSon_Digital Cable_1106_2014_05_22_08_53_40.ts"

However, when I attempt to call an external player, it is passed "pvr://channels/tv/All TV channels/55.pvr" and hence cannot play the correct file. If I get the appropriate filename from the log and give that to MPC-HC, it plays without a problem, albeit it starts from the whatever time the stream/file was initialized.

In addition, in the Python API, obtaining the file playing from the player class, returns "pvr://channels/tv/All TV channels/55.pvr". Running this string thru xbmc.translate() returns the same string, while all other "special" file/directory names are appropriately translated.

[xhaggi]

It would be nice if you could add this to our bug tracker at http://trac.xbmc.org. Thanks

[KenV99]

It would be nice if you could add this to our bug tracker at http://trac.xbmc.org. Thanks

Done!

http://trac.xbmc.org/ticket/15240
http://trac.xbmc.org/ticket/15241

Sorry, the instructions on git said to post in the forums and did not mention using trac.xbmc.org...

[jmarshall]

This is not a bug.

Almost all URLs that XBMC supports won't be translated by xbmc.translatePath(), as for the majority of them it makes no sense whatsoever to translate them. The only thing it handles is special:// URLs.

[KenV99]

This is not a bug.

Almost all URLs that XBMC supports won't be translated by xbmc.translatePath(), as for the majority of them it makes no sense whatsoever to translate them. The only thing it handles is special:// URLs.

Ok. Is there a reason that the developers for pvr add-ons do not want the underlying files or streams to be discoverable by the developers writing add-ons in python? It seems inconsistent with the discoverability of the video files for movies and TV as implemented in the Python API. When the player.getPlayingFile() function is called, a valid path/filename is returned for these files, while an invalid url in the form of pvr://... is returned for LiveTV. And there does not seem to be any exposed function to allow interpretation of this designation into a valid path/filename. Perhaps requests from player.getPlayingFile() should automatically return a valid path/filename (or a url that can be interpreted by the OS) instead of the enigmatic pvr://... url.

[jmarshall]

You'll also find videodb:// URLs are likewise not translated for you using this function. Similarly musicdb:// and the like.

It is certainly possible that a pvr:// URL is completely meaningless outside of XBMC (i.e. there is no underlying file implementation).

[KenV99]

You'll also find videodb:// URLs are likewise not translated for you using this function. Similarly musicdb:// and the like.

It is certainly possible that a pvr:// URL is completely meaningless outside of XBMC (i.e. there is no underlying file implementation).

Agreed, that is true for videodb and musicdb, but for pvr there is either a url stream or a file coming from the backend. Given the nature of the implementation of backend servers and frontend consumers in XBMC, it seems that a stream or filename that is interpretable outside of XBMC is necessary in order to interact with the backend serving the video. In the case of pvr.wmc, there is .ts file that underlies the pvr:// url. For others, there is an http:// or rtmp:// stream. It would seem appropriate that either player.getFilePlaying() directly returns the underlying file or stream or that a function such as xbmc.translate() allows for conversion of the pvr:// url to something more useful. If some frontends that I am not familiar with do not have something useful to return, an error code could be returned.

In the least, it might be noted in the pydocs for xbmc that getPlayingFile does not return a valid path/filename for LiveTV. If you could point me to the right person to annotate that, I'd be happy to do so. Likewise I think it should be noted on the page discussing external players that the filename argument does not return a valid filename for LiveTV.

[nickr]

You'll also find videodb:// URLs are likewise not translated for you using this function. Similarly musicdb:// and the like.

It is certainly possible that a pvr:// URL is completely meaningless outside of XBMC (i.e. there is no underlying file implementation).

Agreed, that is true for videodb and musicdb, but for pvr there is either a url stream or a file coming from the backend. Given the nature of the implementation of backend servers and frontend consumers in XBMC, it seems that a stream or filename that is interpretable outside of XBMC is necessary in order to interact with the backend serving the video. In the case of pvr.wmc, there is .ts file that underlies the pvr:// url. For others, there is an http:// or rtmp:// stream. It would seem appropriate that either player.getFilePlaying() directly returns the underlying file or stream or that a function such as xbmc.translate() allows for conversion of the pvr:// url to something more useful. If some frontends that I am not familiar with do not have something useful to return, an error code could be returned.

you'll find for example that mythtv backend has its own protocol which is not translatable to a filesystem path. Therefore a generic system will not be possible.

In the least, it might be noted in the pydocs for xbmc that getPlayingFile does not return a valid path/filename for LiveTV. If you could point me to the right person to annotate that, I'd be happy to do so. Likewise I think it should be noted on the page discussing external players that the filename argument does not return a valid filename for LiveTV.

are you talking about a wiki page? Edit it!

[KenV99]

I guess I'm just disappointed that for those frontends where useful information could be provided, that it isn't. I recognize that it is a complicated system with multiple frontends, but I can see from my own and others debug logs that the os-specific information about the file or stream is being written to the logs. If that info could also be written to a centralized class that could be exposed to the python api, then it would be accessible to add-on community.

Pydocs is extracted directly from the source code, so there is no way of me directly editing it: http://wiki.xbmc.org/index.php?title=PyDocs

I'll look into editing the wiki page for the external players.

---

I'll see if I can search through the source on github and find where pydocs is extracted from and try to put in a pull request with the annotation, but i'm not very experienced in cpp. Any guidance would be appreciated.

[nickr]

I'd have to ask, what's wrong with the xbmc player?

[KenV99]

I'd have to ask, what's wrong with the xbmc player?

Nothing, in particular. For some video files I prefer using MPC-HC with madVR and SVP. But I maintain a script add-on for external ambient lighting and use the filename to then get more information about the video stream in order to configure the lighting. This works great for normal files, but then fails for LiveTV. I just need to be able to discover if the video is 16:9 or 4:3.

[jmarshall]

The aspect ratio is certainly already available to the skin, so should certainly be available to python (and likely over JSON-RPC as well).

[nickr]

Some broadcasters change aspect ratio mid stream, eg during adverts.

[negge]

Like nickr said, the reason why you're having this problem (which also means it's not possible to "download" live streams through the JSON-RPC API) is because some backends serve the stream data to XBMC directly over TCP instead of using a URL and a higher-level protocol such as HTTP or RTMP.