API - deprecated features v18

  Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Post Reply
rbuehlma Offline
Member
Posts: 60
Joined: Aug 2014
Reputation: 4
Post: #16
(2016-08-13 16:09)FernetMenta Wrote:  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?
find quote
FernetMenta Offline
Team-Kodi Developer
Posts: 6,242
Joined: Jul 2010
Reputation: 146
Location: Munich
Post: #17
Quote: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.

Quote: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?
find quote
rbuehlma Offline
Member
Posts: 60
Joined: Aug 2014
Reputation: 4
Post: #18
(2016-08-14 09:12)FernetMenta Wrote:  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?
find quote
FernetMenta Offline
Team-Kodi Developer
Posts: 6,242
Joined: Jul 2010
Reputation: 146
Location: Munich
Post: #19
(2016-08-14 14:16)Natronch Wrote:  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.
find quote
rbuehlma Offline
Member
Posts: 60
Joined: Aug 2014
Reputation: 4
Post: #20
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
Quote: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?
find quote
FernetMenta Offline
Team-Kodi Developer
Posts: 6,242
Joined: Jul 2010
Reputation: 146
Location: Munich
Post: #21
Quote:- 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.
find quote
rbuehlma Offline
Member
Posts: 60
Joined: Aug 2014
Reputation: 4
Post: #22
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.
find quote
Martijn Offline
Team Kodi
Posts: 17,014
Joined: Jul 2011
Reputation: 312
Location: Dawn of time
Post: #23
I don't see the need to add a new "functionality" that gets removed again next version.

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
rbuehlma Offline
Member
Posts: 60
Joined: Aug 2014
Reputation: 4
Post: #24
The functionality will not be removed but implemented/provided in a better way.
find quote
FernetMenta Offline
Team-Kodi Developer
Posts: 6,242
Joined: Jul 2010
Reputation: 146
Location: Munich
Post: #25
(2016-08-17 09:03)Natronch Wrote:  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.
find quote
rbuehlma Offline
Member
Posts: 60
Joined: Aug 2014
Reputation: 4
Post: #26
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?
find quote
mklein49 Offline
Junior Member
Posts: 18
Joined: Mar 2004
Reputation: 0
Post: #27
(2016-02-14 12:12)FernetMenta Wrote:  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
find quote
coffeecup Offline
Junior Member
Posts: 34
Joined: Jun 2011
Reputation: 0
Post: #28
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?
find quote
manĂ¼l Offline
Moderator
Posts: 408
Joined: Mar 2013
Reputation: 27
Post: #29
Hi. With the new async startup for PVRs is ADDON_GetStatus() still of any use? A quick grep couldn't yield a single call.
find quote
ksooo Offline
Team-Kodi Member
Posts: 855
Joined: Jan 2015
Reputation: 43
Location: Hamburg, Germany
Post: #30
As far as I know GetStatus was not used even before the async connect changes.
find quote