[FernetMenta]

W.r.t to the removal of SwitchChannel:
What is the new calling sequence for this?

VideoPlayer treats PVR as any other source. VP gets a file item, determines appropriate inputsteam, opens demuxer, and plays streams. Note that all pvr stream relevant functions will be splitt off the pvr api and moved to inputstream.

[margro]

Well my question is exactly this: what is "whatever needs to be done". This is not clear to me.

[margro]

VideoPlayer treats PVR as any other source. VP gets a file item, determines appropriate inputsteam, opens demuxer, and plays streams. Note that all pvr stream relevant functions will be splitt off the pvr api and moved to inputstream.

So this means: OpenLiveStream -> CloseLiveStream -> OpenLiveStream -> CloseLiveStream at the PVR addon side if I watch 2 channels after each other?

[FernetMenta]

Inputsteam API has no method OpenLiveStream. As mentioned, this part of the PVR api will die. Inputstream is NOT a singelton. Everytime VP opens a fileitem a new instance of inputstream will be created. There can even be multiple instances of the same type active playing at the same time.

[scarecrow420]

Im also a bit lost as to what this actually means for the pvr.wmc addon. I've been getting further and further away from Kodi development in recent months/years but I would be happy to make changes to keep pvr.wmc/ServerWMC functioning with Kodi, but Im not an expert in this and simply don't know what we need to do to ensure addons still continue to function once this change goes through? Any pointers would be appreciated

[MatthewLundberg]

I see in the recent commit that strStreamURL is gone in master, yet GetLiveStreamURL remains.

Is the plan to remove the latter also? If not, how would you get it to be called?

[da-anda]

guys, it looks like you're kinda lost atm. I'm not at all into anything PVR or binary add-ons, but Fernet wrote that your add-ons now need to support ReadRecordedStream and ReadLiveStream API functions. From a quick look, these require buffers to be filled and passed around. Now, it doesn't make much sense that each and every PVR add-on is writing it's own buffer logic, so I suggest to maybe write some helper lib (or abstract PVR add-on / foundation) that all add-on can be based on. Alternatively, your add-ons could use current PVR API to provide EPG, recordigns etc and utilize the inputstream API for playback. That's at last what I gathered. Now, the inputstream API is not yet fixed and could be modified to suite your needs, but you have to check out the API and give feedback. Thanks.

[da-anda]

Btw, please don't hesitate to speak freely and keep asking. I try to get and provide answers for your questions.

[FernetMenta]

I see in the recent commit that strStreamURL is gone in master, yet GetLiveStreamURL remains.

Is the plan to remove the latter also? If not, how would you get it to be called?

that's dead code and I forgot to remove it too. will be dropped in next round

[rbuehlma]

utilize the inputstream API for playback.

Thanks for your support. Thats exactly what I would love to do with the pvr.zattoo addon, but how? Do you know a way of triggering an inputstream addon (inputstream.adaptive in my case) from a pvr addon? Until now, I did that with some minor patches to kodi and using the strStreamUrl. Is there another way?

[negge]

The VBox PVR addon can be used as an example of how to implement basic support for ReadLiveStream:

https://github.com/kodi-pvr/pvr.vbox/blo...t.cpp#L946 here we just pass the call on to a "timeshift buffer". This particular addon has two implementations, one that actually does buffering and one that just passes the calls through.

https://github.com/kodi-pvr/pvr.vbox/blo...Buffer.cpp is the implementation of the dummy buffer

https://github.com/kodi-pvr/pvr.vbox/blo...Buffer.cpp this is the base class for buffers. As you can see it takes a URL, basically the same URL that you would have previously passed to strStreamUrl.

@FernetMenta am I correct in assuming that ReadLiveStream is here to stay at least for now, or is this way of passing input to Kodi also about to be deprecated in the near future? If not, then addon developers can consider this implementation as a reference guide.

[da-anda]

guys, it looks like we got FernetMenta wrong - or at least I did. As part of the refactoring of the PVR feature to decouple it from videoplayer using inputstream API (internally I guess), ALL playback related function will get dropped from the PVR API, so also ReadLiveStream etc.

Thus, FernetMenta would like to open up the discussion on how the new API (that has to go through the inputstream interface) should look like, or which requirements you have on it. To temporarily fix your add-ons until ReadLiveStream etc will get dropped, you can use the buffer dummy stuff linked by negge above.

[FernetMenta]

utilize the inputstream API for playback.

Thanks for your support. Thats exactly what I would love to do with the pvr.zattoo addon, but how? Do you know a way of triggering an inputstream addon (inputstream.adaptive in my case) from a pvr addon? Until now, I did that with some minor patches to kodi and using the strStreamUrl. Is there another way?

Currently there is no way to do this but it can be implemented. Why don't you draft something that would fit your requirements?

[da-anda]

ok, new information from our recent chat in Slack:

fernetmenta
a pvr addon will be able to implement pvr api or pvr api AND inputstream api
vnsi and hts for example will implement both APIs
pvr.simple will only implement pvr (channel, epg) because it does no streaming by itself

da-anda
and how will streams be handled with only PVR API when streaming functions are being dropped from it?

fernetmenta
by kodi or other inputstream addons like inputstream.adaptive
same way it works with many other addons like amazon, construct a fileitem and send it to player

da-anda
so Kodi will ask PVR add-on to return a cFileItem for a certain channel/recording and return it. Kodi will handle form there?

fernetmenta
no, a pvr addon does not know what a fileitem is, pvr component will ask the addon for required info and constructs the fileitem

so there will be a replacement for streamUrl of some sort, the API will just be a bit different in future. In the meantime, you can fix your add-ons temporarily via the buffer thingy as mentioned above.

And to make it clear, the new PVR API is up for discussion. So which infos do you have to pass to Kodi in order for it to create a suiteable cFileItem for playback? Just the URL, headers, cookies or whatever else. Please start discussion about it and come up with a draft on how it should look like in your eyes.

[da-anda]

I created a thread to discuss the new API functions needed https://forum.kodi.tv/showthread.php?tid=318996