Hello! I apologize in advance if this isn’t the proper forum to post my inquiry, but I have a question regarding the CoreELEC Kodi PVR API v5.10.4 modifications/patches.
I develop a third-party Kodi PVR addon for the HDHomeRun, and some of my users have had difficulty using it with CoreELEC due to the bump in the PVR API version. When they started reporting problems I went looking for this API change to support it, but learned that it’s a CoreELEC exclusive changeset.
My concern is that I am unable to support CoreELEC at this time since the formal Kodi PVR API is still at version 5.10.3. If Kodi is to bump their API to 5.10.4, chances are good it won’t be the same set of changes and there will be a version conflict in the future, leaving me in a bit of a pickle.
I would love to be able to support all my users, and they seem to really like CoreELEC. Is there any chance that CoreELEC could use a different mechanism to detect/access the enhanced PVR functionality for addons that support it without changing the formal Kodi API? I can think of a couple different tricks you might be able to use, but I’m mainly a Windows person so I’m not going to pretend to know something you don’t
Thanks for your time, and Happy Holidays! Looks like a great product you have here!
The API was bumped to add support for the PVR archive feature.
After some internal discussions, bumping the API was the only sure way to prevent any compatibility issues with the PVR addons we build with our releases.
How are you building your addon for ARM/CoreELEC? Or does it not have a binary?
It’s a regular old Kodi binary addon, packaged and deployed as a .zip file to the end users. I have my own build methodology I put together using msbuild – for all the *nix distros I use GCC. I have the XBMC repo as a submodule/dependency and it will pull the necessary headers from there for the PVR and addon APIs.
I completely understand the need to increment the API, was just reaching out to see if there was any plans or possibilities for PVR addons that hit API 5.10.3 (perhaps as a minimum version?) to still work with CoreELEC so I can provide the proper guidance to my users.
Not being an IPTV household, I admit to not really looking at what the new features were, but have you guys considered contributing them back to Kodi? If the CoreELEC API changes are in the pipeline, the worry about Kodi stepping on them with changes of their own could be alleviated.
But hey - I’m not preaching or asking you to change anything here (seriously) Not my style. At least one user was enterprising enough to adapt the code to CoreELEC themselves, and if enough really start getting into CoreELEC, there is no reason I couldn’t have a special CoreELEC build myself!
The changes where submitted to Kodi upstream, unfortunately due to Leia being at the Beta stage they are not accepting any bumps to the API now until after Leia is final.
We would be able to add your addon to our buildroot and build it when doing our releases and add it to our repositories so it would be compatible for our users.
Cool, thank you - I was able to find the PR and the associated discussion points on GitHub and the forum.
You guys are welcome to grab the PVR and include it if you want - I use a permissive license (MIT), I didn’t want to make this inquiry any type of self-promotion on my part. Given that the code build and layout is customized (no CMake, uses its own version of a couple FOSS libraries, etc) it’s probably not worth your time/effort just to support a few users LMK if you feel otherwise, you are honestly welcome to use/include it if you wanted to go that route.
Seeing that it’s being worked for Kodi 19 relieves my trepidation about doing some one-off build(s) for my users, that is likely the best route to go at this point, easiest for everyone!
Thank you for the information, I truly appreciate it!
I was looking over the patchset itself finally, and have a question. It looks like the only truly breaking change made to the API was the addition of the bHasArchive field to PVR_CHANNEL. I agree that changing that structure does require you to bump the API version and require addons to be compiled against it.
Did you guys consider adding a method to get this flag instead of changing the structure? Yes, that would require more calls into the PVR addon, but you could use the presence or absence of this new method to detect non-compliant addons and default the flag to false as necessary. Unless I’m missing something critical here, you could keep the minimum PVR version at 5.10.0 and not have any need to recompile/build all of the non-IPTV addons.
Given that Kodi has moved to a repository-based binary addon distribution I think coming up with a way to not break the PVR API would be of benefit to both CoreELEC and your user base. There is little chance that any non-CE built PVR addons are going to be compatible with CE for the lifetime of Leia.
I do hope you are willing to take another look at this, but will try not to bother you anymore I let my gang know that I decided against supporting the API change after reviewing it, but they are free to ‘roll their own’ and I will help them if they want
I would like to propose a solution to this PVR API incompatibility. I got myself an ODROID-C2 and started playing around. I believe you can remove the incompatibility by reusing the strInputFormat field of the PVR_CHANNEL structure in conjunction with a change to your pvr.iptvarchive addon instead of modifying the PVR_CHANNEL structure itself, and subsequently the PVR API version.
While I don’t have IPTV available to me, let alone IPTV with archive support, a very minor changeset would be required IMO. I propose that your pvr.iptvarchive addon sets PVR_CHANNEL::strInputFormat to “iptv/hasarchive” if archive support is available instead of the modification to the PVR_CHANNEL structure itself. Minor constructor changes would be needed in the PVRChannel class to look for this string and toggle m_bHasArchive to true if present. Only a few PVRs even use this field, and it’s mostly (if not completely) useless in Leia since it’s been superseded by GetChannelStreamProperties() / GetRecordedStreamProperties().
My proposed changes are available via a trio of HTML diff files here: https://1drv.ms/f/s!AgEGEEVzGNq-i9VsZEHq2SLOvj4u5A. Two of the diffs bring the API back into alignment, and the final diff “fixes” PVRChannel.cpp to work with my proposed change. A subsequent change to your patch to pvr.iptvsimple to create pvr.iptvarchive would also be required to set the “iptv/hasarchive” PVR_CHANNEL::strInputFormat field based on the return value from IsArchiveSupportedOnChannel().
I hope you seriously consider this set of proposed changes for CoreELEC in order to restore compatibility with the existing Kodi PVR addons, while still giving you the custom functionality you want to deliver to your IPTV users.
I agree with Djp952 about necessary changes. I have no clue about the details, but I do know that his HDHomeRun PVR addon is fantastic for Live and Recorded TV. As it is now, his updates will not install because of the wrong PVR API version. Fortunately, ** Timecutter ** mods DJP’s addon so it will install.
Please consider making whatever changes he suggest, so I can keep his addon updated.
I am running CoreELEC on two of my Amlogic boxes, S905x and S912.
Thank you! I used my own diffs just to illustrate how I thought it could be done, I didn’t want to be presumptuous and try to make the recommendation a formal PR on you since I didn’t know if you guys would be amenable to it.
I know a lot of people that will be quite happy with this; you guys rock for even considering it. I look forward to seeing Kodi accept your changes upstream so everyone can benefit from IPTV archive support. In the event you opt to try ksooo’s recommendation to use the Timeshifting support inherent to the PVR API for the base functionality, please reach out to me (djp952@gmail.com) if you think I can be of any assistance. I implemented that generally successfully, but of course IPTV archive is a lot different than HDHomeRun DVR The hardest part for me was parsing MPEG-TS to come up with reasonably accurate timestamps.
No experience with archive, per-se, just some with getting timeshifting to work in Leia. I have a different situation - there is no ‘back-buffer’ available to me at all.
I could try to get something set up here, if there are any legitimately free IPTV services that allow it (I doubt there is, and wouldn’t want to venture into the wrong end of the pool) to see if I have any ideas, but just thinking out loud, perhaps there is some way to marry the archive with the live stream and come up with a way to tell Kodi what points the user can legitimately seek back/forward to? I imagine the Seek() implementation would be a hell of a thing to put together to handle that!
Do you guys show fully archived/non-live programs as recordings? Like if the user can access old episodes of something that comes through via Recordings in the UI. That would be pretty cool.
My input is likely worthless, not being able to use/see what you’ve done so far, but one other random thought that may be neat for whatever the final implementation ends up as being may be to marry the indicator(s) with Recordings somehow in the EPG so all PVRs can leverage it? Again not really knowing how this works today for iptvarchive, having some type of “you can watch this program that occurred in the past” indicator, regardless of how the PVR will actually make that happen for the user, seems really useful to me. I frequently have to go scroll through Recordings for my daughter to see if we have some episode already recorded or not after she saw it in the EPG.
So yeah, pretty useless to you Very grateful for accepting the temporary change and trying to come up with some way to repay the favor I guess.
