API - deprecated features v18

  Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Post Reply
FernetMenta Offline
Team-Kodi Developer
Posts: 6,190
Joined: Jul 2010
Reputation: 140
Location: Munich
Exclamation  API - deprecated features v18
Post: #1
strStreamURL for channels and recordings is deprecated. It lead to a lot of issues and workarounds. Changing the original fileitems's path and pretend it is something other is not the way to go.

pvr addons need to implement the required API functions like ReadRecordedStream or ReadLiveStream
(This post was last modified: 2016-02-14 12:55 by FernetMenta.)
find quote
Martijn Offline
Team Kodi
Posts: 16,915
Joined: Jul 2011
Reputation: 310
Location: Dawn of time
Post: #2
You mean v17?

Read/follow the forum rules.
For troubleshooting and bug reporting, read this first
Interested in seeing some YouTube videos about Kodi? Go here and subscribe
find quote
FernetMenta Offline
Team-Kodi Developer
Posts: 6,190
Joined: Jul 2010
Reputation: 140
Location: Munich
Post: #3
(2016-02-14 12:14)Martijn Wrote:  You mean v17?

I meant v18 because I want to give the addon authors enough time
find quote
rbuehlma Offline
Member
Posts: 50
Joined: Aug 2014
Reputation: 4
Post: #4
The PVR addon I'm working on receives a DASH stream. This Stream can be played with the inputstream.mpd. If strStreamURL is deprecated, is
there an other way to use an inputstream addon out of the PVR addon?
find quote
FernetMenta Offline
Team-Kodi Developer
Posts: 6,190
Joined: Jul 2010
Reputation: 140
Location: Munich
Post: #5
(2016-08-11 08:47)Natronch Wrote:  The PVR addon I'm working on receives a DASH stream. This Stream can be played with the inputstream.mpd. If strStreamURL is deprecated, is
there an other way to use an inputstream addon out of the PVR addon?

Yes. The entire streaming API of PVR will be dropped in favour of inputstream API. A PVR addon just sets a normal Kodi file item and Kodi will open it using an appropriate method. This makes strStreamURL obsolete.
find quote
rbuehlma Offline
Member
Posts: 50
Joined: Aug 2014
Reputation: 4
Post: #6
(2016-08-12 08:02)FernetMenta Wrote:  A PVR addon just sets a normal Kodi file item

Could you hint me to the direction on how to do this? I scanned through the data structures used by the PVR addon but could not find such a property?

And is it correct that PVR addons using some special protocol (like mythtv) should then provide an inputstream supporting the same?
find quote
FernetMenta Offline
Team-Kodi Developer
Posts: 6,190
Joined: Jul 2010
Reputation: 140
Location: Munich
Post: #7
Quote:And is it correct that PVR addons using some special protocol (like mythtv) should then provide an inputstream supporting the same?

Yes, those PVR addons are required to implement two extension points: PVR and InputStream. Implementations must support multiple instances of the InputStream ext point. That enables playing multiple channels/recordings at the same time, a requirement for picture-in-picture and thumbnail extraction.

For VideoPlayer there won't be channels anymore, just FileItems that are passed to OpenFile().

Quote:Could you hint me to the direction on how to do this? I scanned through the data structures used by the PVR addon but could not find such a property?

Sorry, I used the wrong tense. This is not implemented yet. Pythons addons can set properties on ListItems but PVR addons can't in the current version. Maybe we need to add an array of properties to the pvr structures. (Also required for other properties like preventing Kodi from doing a content lookup)
find quote
rbuehlma Offline
Member
Posts: 50
Joined: Aug 2014
Reputation: 4
Post: #8
Ok, now all becomes clearer thanks for the explanation.

Considering that there currently seems not to be a better option, would it be possible to accept my two PR:
https://github.com/xbmc/xbmc/pull/10272
https://github.com/xbmc/xbmc/pull/10273

In understand that they are not to stay for ever but until the right/clean way is ready, it will be possible to use it as a workaround. Switching to the new way should not be very hard then as we simply need to set this file item instead of the URL.

https://github.com/xbmc/xbmc/pull/10272
does not add an additional hack but only extend an existing one and can be reverted together with the actual hack.

https://github.com/xbmc/xbmc/pull/10273
implements a functionality for a field which was already there. It would be great if this can also be included and kept until then.

The only exception is this commit:
https://github.com/xbmc/xbmc/pull/10273/...de359fd7a0
Without it, you will run into a segfault (see comment in PR). My commit is just to prevent this segfault. You can probably come up with a real fix there.
find quote
FernetMenta Offline
Team-Kodi Developer
Posts: 6,190
Joined: Jul 2010
Reputation: 140
Location: Munich
Post: #9
I am sorry. I don't accept the PRs for the reasons I posted and in particular not for deprecated features.
find quote
rbuehlma Offline
Member
Posts: 50
Joined: Aug 2014
Reputation: 4
Post: #10
Do you have a time line/Kodi version, when it will be possible to set this file item out of a PVR addon?
Can you propose another solution for my case?
And how can a feature be deprecated as long as the desired new solution is not in place?
find quote
FernetMenta Offline
Team-Kodi Developer
Posts: 6,190
Joined: Jul 2010
Reputation: 140
Location: Munich
Post: #11
(2016-08-12 12:59)Natronch Wrote:  Do you have a time line/Kodi version, when it will be possible to set this file item out of a PVR addon?

Why don't you implement this instead of your current approach?
find quote
rbuehlma Offline
Member
Posts: 50
Joined: Aug 2014
Reputation: 4
Post: #12
Yeah, I can try it Smile Will probably take some rounds on the PR.

My approach would be to add a PVR-Api function like
- CFileItem GetFile(PVR_CHANNEL)
- CFileItem GetFile(RECORDING)

A new "Capability" will tell Kodi that these Functions are implemented by the Addon.

I would also like to support this case (playing a past (or even future) EPG entry):
http://forum.kodi.tv/showthread.php?tid=261874
This could be a function like this:
- CFileItem GetFile(EPG_TAG)

Would that be the way to go?
find quote
FernetMenta Offline
Team-Kodi Developer
Posts: 6,190
Joined: Jul 2010
Reputation: 140
Location: Munich
Post: #13
what would call this api funktion and when?
find quote
rbuehlma Offline
Member
Posts: 50
Joined: Aug 2014
Reputation: 4
Post: #14
What about if we call the CPVRClient in VideoPlayerCodec::Init and let there the "pvr://" file item be translated into the file item which is then provided to CDVDFactoryInputStream::CreateInputStream.
This would make the whole CDVDInputStreamPVRManager obsolete. For backwards compatibility, the file item is simply not translated causing CDVDInputStreamPVRManager to be used.

This would mean all special handling for PVR streams would need some rework (channel switch, recording and so on).

Else we could keep CDVDInputStreamPVRManager and make it a simple wrapper to the actual input stream and call CDVDFactoryInputStream::CreateInputStream from within CDVDInputStreamPVRManager again to create the input stream fro the new file item.

What do you think?
find quote
FernetMenta Offline
Team-Kodi Developer
Posts: 6,190
Joined: Jul 2010
Reputation: 140
Location: Munich
Post: #15
(2016-08-13 11:42)Natronch Wrote:  What about if we call the CPVRClient in VideoPlayerCodec::Init and let there the "pvr://" file item be translated into the file item which is then provided to CDVDFactoryInputStream::CreateInputStream.

not sure what you are suggesting. VideoPlayerCodec::Init belongs to paplayer and has no relationship to pvr.

Anyway, I already explained the future changes: all streaming relevant API functions will be dropped from PVR. No backwards compatibility needed here.
The URL path of a fileItem is not supposed to be changed. this is why strStreamURL and the otherStream hack will be removed.

A requirement for now and the future is for PVR to set properties on ListItems. If you implement this, your addon will work with current version.
find quote
Post Reply