Login at Kodi Home

FernetMenta · (This post was last modified: 2017-07-22, 15:35 by FernetMenta.)

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

2)
SwitchChannel is not called anymore by Kodi and will be dropped from the addon interface

**Martijn** · 2016-02-14, 12:14

You mean v17?

FernetMenta · 2016-02-14, 12:27

(2016-02-14, 12:14)Martijn Wrote: You mean v17?

I meant v18 because I want to give the addon authors enough time

rbuehlma · 2016-08-11, 08:47

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?

FernetMenta · 2016-08-12, 08:02

(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.

rbuehlma · 2016-08-12, 09:47

(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?

FernetMenta · 2016-08-12, 11:01

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)

rbuehlma · 2016-08-12, 11:27

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.

FernetMenta · 2016-08-12, 12:52

I am sorry. I don't accept the PRs for the reasons I posted and in particular not for deprecated features.

rbuehlma · 2016-08-12, 12:59

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?

FernetMenta · 2016-08-12, 13:24

(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?

rbuehlma · 2016-08-12, 13:57

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?

FernetMenta · 2016-08-13, 08:11

what would call this api funktion and when?

rbuehlma · 2016-08-13, 11:42

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?

FernetMenta · 2016-08-13, 16:09

(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.