[rbuehlma]

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.

Does this mean that I do not have to change the code in Kodi but that I simply can set this property? Its not clear to me how to do that in the addon. And how can I currently pass the channel URL to Kodi? I do not see any possibilities in the current API to do this (beside of the deprecated ones).

Therefore, I assumed that I would have to add API calls to the addon which allows Kodi to get this URL and the required add-on. The two possibilities to do this, are from my point of view when creating the FileItem after selecting the channel, or when opening the stream.

Is this correct so far?

[FernetMenta]

Does this mean that I do not have to change the code in Kodi but that I simply can set this property?

No, it requires some code changed in Kodi PVR.

Its not clear to me how to do that in the addon. And how can I currently pass the channel URL to Kodi?

strStreamURL is deprecated but still there in v17.

We have to distinguish between a short term solution and the bigger change that will come with v18. If I did you understand correctly, you are looking for some short term solution, right?

[rbuehlma]

We have to distinguish between a short term solution and the bigger change that will come with v18. If I did you understand correctly, you are looking for some short term solution, right?

I guess there was my miss-understanding. I assumed you did not want me to use/extend this strStreamURL solution but instead invest the effort in the long-term solution.

You are suggesting to add a property "inputStreamAddon" next to strStreamURL and set the Property in the FileItem together with the strStreamURL?

I expect that this workaround will still be required then:
https://github.com/xbmc/xbmc/pull/10273/...de359fd7a0
Do you have a better fix for that?

[FernetMenta]

You are suggesting to add a property "inputStreamAddon" next to strStreamURL and set the Property in the FileItem together with the strStreamURL?

Nope, I am suggesting a more generic solution. v17 is in beta now and only fixes are accepted. We observe a regression due to lacking any capability to set ListItem props on PVR ListItems. If you implemented a method to set ListItem props for pvr channels, we could consider this as a fix.

Check out CPVRDirectory::GetDirectory. This method creates the list of FileItems (channels) a user can select. You could call out to PVR, for example
PVRClient::GetPropsForChannel
return an array of props, and set those on the FileItem.

[rbuehlma]

Thanks for the explanation. Is clear now and I tried to implement this solution but I stumbled over some challenges:

- CPVRDirectory::GetDirectory is only one of the paths where the properties would need to be set. There is at least another one when opening a channel through the EPG.

- If I do set the "inputstreamaddon" property before the "pvr://" url is translated to the strStreamURL, the translation would not happen anymore as the addon will handle the pvr:// stream. (See CDVDFactoryInputStream::CreateInputStream)

One additional thought:
Currently setting the property would only make sense if also the strStreamURL is used. In any other case, a "pvr://" url would be provided to the addon.

Therefore, from my point of view, the solution

a property "inputStreamAddon" next to strStreamURL and set the Property in the FileItem together with the strStreamURL

would be less invasive and also more logical since most probably both implementations will not be used after v18. A bit a more generic solution would be instead of "inputStreamAddon" a property "streamProperties" containing a list of properties which are transferred to the FileItem upon translating to the strStreamURL.

What do you think about this?

[FernetMenta]

- If I do set the "inputstreamaddon" property before the "pvr://" url is translated to the strStreamURL, the translation would not happen anymore as the addon will handle the pvr:// stream. (See CDVDFactoryInputStream::CreateInputStream)

Right, here we see again that StreamURL is a hack and does not behave as one would expect. FileItem URLs are not supposed to be changed. Sorry, but this seems to be knock-out for v17. Better we focus on a clean solution for v18.

[rbuehlma]

Thats bad luck. But with this new Information, I would like to ask again to consider my two PR.

One of them implements the functionality of a field which is currently unused (the extension). The file extension is there for reason and if there is no better guess of the file format, its probably better to use the file extension instead of failing.

The other one adds demuxer support for the "otherStreamHack". Its definitely not be best solution, but currently the best we got to get it running in v17. And it will automatically removed as soon as the "otherStreamHack" is removed as the change is withing this code.

I do not see any negative impact from both of them.

[Martijn]

I don't see the need to add a new "functionality" that gets removed again next version.

[rbuehlma]

The functionality will not be removed but implemented/provided in a better way.

[FernetMenta]

The file extension is there for reason and if there is no better guess of the file format, its probably better to use the file extension instead of failing.

The file extension is only there because I forgot to delete it after having copied the skeleton of the class from another addon. I will change this.

[rbuehlma]

I guess the extension of the Zattoo Plugin has to wait until v18. But I have another question on a similar matter:

the seeking functions by time (DemuxSeekTime, SeekTime and PosTime provide the time in milliseconds mostly as "int". In my case, the stream has a very high PTS time as it is constantly growing since many years. Therefore, also the time in milliseconds does not fit in an integer anymore. Is it possible to change these parameters to uint64_t (or int64_t if there are cases where negative values are required)? Is somthing already planned in this direction?

[mklein49]

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

Hi,

I'm interested in attempting to perform this work. I'm new to Kodi Development. Is there a ticket defined that defines the requirements and/or vision for the work to be performed.

Thank you

[coffeecup]

I have some questions on this: https://github.com/xbmc/xbmc/pull/10467#event-793430350

I understand otherstream hack is deprecated for good reasons. I'm just wondering how or if at all there will be a way to implement iptv channels using mpeg dash or smoothstream in the future. Even if it will be possible to set FileItem properties of PVRChannels through ListItems or whatever, it would still need the PVR addon to provide the data through ReadLiveStream or so, right? This would mean that the only way is to access the proper inputstream addons somehow directly from the PVR addon?

[manül]

Hi. With the new async startup for PVRs is ADDON_GetStatus() still of any use? A quick grep couldn't yield a single call.

[ksooo]

As far as I know GetStatus was not used even before the async connect changes.