Work in Progress - Bring binary add-ons classes together

  Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Post Reply
alwinus Offline
Team-XBMC Developer
Posts: 158
Joined: Aug 2008
Reputation: 4
Location: Mönchengladbach
Question  Bring binary add-ons classes together
Post: #1
Working currently on the binary add-on system to bring them more together. Currently are PVR and ADSP present on Kodi with the bigger system, in future comes also the Web Interface to them.

The add-on system classes on ADSP are nearly a complete copy from PVR, this was OK for me on begin but make no sense to have continues like this.

On my branch https://github.com/AlwinEsch/kodi/commits/pvr-cleanup I has now created a combination of the classes with the new "CBinaryAddons" which becomes set by "template <typename T, class C>" to right add-on structure during usage, see commit "[pvr][adsp] bring add-on classes together".

Here it works on test very good and want to make sure that it is also OK from your side.

[Image: MpYgKMy.png]
(This post was last modified: 2015-10-21 12:35 by alwinus.)
find quote
ksooo Offline
Team-Kodi Member
Posts: 814
Joined: Jan 2015
Reputation: 41
Location: Hamburg, Germany
Post: #2
Much appreciated. Will look at the code and give it a try asap.
find quote
Razze Offline
Team-Kodi Member
Posts: 1,582
Joined: Jan 2015
Reputation: 50
Location: Osnabrück, Germany
Post: #3
Btw. I think these topics might make sense in the non team section. Probably the read only forum?
find quote
alwinus Offline
Team-XBMC Developer
Posts: 158
Joined: Aug 2008
Reputation: 4
Location: Mönchengladbach
Post: #4
You're right Razze, how can be it moved?
find quote
Martijn Offline
Team Kodi
Posts: 16,913
Joined: Jul 2011
Reputation: 310
Location: Dawn of time
Post: #5
(2015-10-20 10:19)alwinus Wrote:  You're right Razze, how can be it moved?
Consider it done Smile

If you want it move for public discussion just ping any admin

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
(This post was last modified: 2015-10-20 10:21 by Martijn.)
find quote
alwinus Offline
Team-XBMC Developer
Posts: 158
Joined: Aug 2008
Reputation: 4
Location: Mönchengladbach
Post: #6
The commits are updated, has cleaned up several places and has also added on end 2 other fixes.

On my side are the following conditions fixed with all changes:
- Fixed Kodi crash if PVR system becomes disabled and a channel playback is active
- Fixed audio DSP database initialization error "Audio DSP - CreateTables - failed to get add-ons from the add-on manager"
- Fixed Kodi crash if DSP basic add-on becomes enabled (Hopefully now)
find quote
alwinus Offline
Team-XBMC Developer
Posts: 158
Joined: Aug 2008
Reputation: 4
Location: Mönchengladbach
Post: #7
Also added the CAddonBinaryManager, which is on the moment really small, but for me a place to introduce more in future about binary add-ons and to separate them from other places e.g CApplication or Login sceen.
find quote
da-anda Offline
Team-Kodi Member
Posts: 5,777
Joined: Jun 2009
Reputation: 77
Location: germany
Post: #8
can you share some schema/diagram on what you plan architecture wise? I think it would be a good idea to first come up with a concept that's being discussed with others before actually coding it in order to not have to refactor stuff again once a PR is up.
find quote
alwinus Offline
Team-XBMC Developer
Posts: 158
Joined: Aug 2008
Reputation: 4
Location: Mönchengladbach
Post: #9
Have added a diagram, hope is usable, has not so much created in my life Smile
(This post was last modified: 2015-10-21 12:37 by alwinus.)
find quote
AchimTuran Offline
Team-Kodi Member
Posts: 545
Joined: Jan 2014
Reputation: 13
Location: Germany
Post: #10
Hi Alwin,

do you also use cpluff as basic add-on management?

Latest news about AudioDSP and my libraries are available on Twitter.

Developers can follow me on Github.
find quote
da-anda Offline
Team-Kodi Member
Posts: 5,777
Joined: Jun 2009
Reputation: 77
Location: germany
Post: #11
would it make sense to have a compatibility layer/wrapper in between? Like for PVR add-ons, each time the API is extended, stub functions have to be added to each and every PVR client that do nothing but annoy every dev. Wouldn't it be much wiser to have a compatibility layer in between? It could basically work like this:

- PVR manager checks for activated add-ons and their supported API version
- if API version matches, the add-on is directly instantiated
- if API version differs and core has a compatibile wrapper for it, instantiate that wrapper instead of the add-on and hand it over the add-on instance and configuration

The compatibility layer would then forward all functions supported by the API version directly to the add-on and provide sane stubs for new stuff. And to not end in a flood of compatibility layers we can define a support timeframe (like max 2 Kodi Versions).


As a bonus, if in addition to the incompatible API versions EVERY PVR add-on would be wrapped, we'd have the possibility to run the very same PVR add-on multiple times with different configurations. This ofc requies also changes on settings level, so that an enabled PVR add-on is not automatically instantiated but only available for selection in something like a PVR connection manager. In this manager you could then add any number of connections, choose the backend type (add-on type) for the connection and give it a individual configuration (open the add-on settings dialog and save it bound to this connection).
(This post was last modified: 2015-10-21 20:58 by da-anda.)
find quote
alwinus Offline
Team-XBMC Developer
Posts: 158
Joined: Aug 2008
Reputation: 4
Location: Mönchengladbach
Post: #12
Hi da-anda, yes you have the same ideas like me. To have a compatibility layer make much sense, then also older versions can be used and brings not so much problems if the API changes can not implemented direct.

Also to allow usage of several same add-ons together is planned from me to use of different PVR backends.

The current changes are primary to have for all binaries the same standard functions e.g. UpdateAndInitialiseAddons(...) or RegisterAddon(...)

Hi wisler, changes are not related to cpluff, this are primary for inside kodi it self.
find quote
AchimTuran Offline
Team-Kodi Member
Posts: 545
Joined: Jan 2014
Reputation: 13
Location: Germany
Post: #13
I'm not familiar with PVR add-ons, but for AudioDSP I development a small framework. With that I can adapt to new API versions very fast. AudioDSP "only" needs the processing algorithm. Most code is for configuration and talking with core.

Quote:Hi wisler, changes are not related to cpluff, this are primary for inside kodi it self.
It would be nice to remove dependcies to cpluff and the callbacks. If you want you can talk to FernetMenta. Some time ago I had a discussion with him about this topic.

Latest news about AudioDSP and my libraries are available on Twitter.

Developers can follow me on Github.
find quote
alwinus Offline
Team-XBMC Developer
Posts: 158
Joined: Aug 2008
Reputation: 4
Location: Mönchengladbach
Post: #14
About my cleanup, is not direct related to the above but also Binary add-ons related.

Due to the add of several more addon GUI lib functions and classes was it to complex and not usable for development from third party places. Have cleaned up the code and separated all parts which not required for add-on development to another place.

See the first reworked Version here:
https://github.com/AlwinEsch/kodi/blob/i...I_guilib.h
find quote