Login at Kodi Home

**alwinus** · (This post was last modified: 2015-10-21, 12:35 by alwinus.)

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.

**ksooo** · 2015-10-20, 07:56

Much appreciated. Will look at the code and give it a try asap.

**Razze** · 2015-10-20, 09:15

Btw. I think these topics might make sense in the non team section. Probably the read only forum?

**alwinus** · 2015-10-20, 10:19

You're right Razze, how can be it moved?

**Martijn** · (This post was last modified: 2015-10-20, 10:21 by Martijn.)

(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

**alwinus** · 2015-10-20, 23:44

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)

**alwinus** · 2015-10-20, 23:47

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.

**da-anda** · 2015-10-21, 10:55

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.

**alwinus** · (This post was last modified: 2015-10-21, 12:37 by alwinus.)

Have added a diagram, hope is usable, has not so much created in my life Smile

**AchimTuran** · 2015-10-21, 20:34

Hi Alwin,

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

**da-anda** · (This post was last modified: 2015-10-21, 20:58 by da-anda.)

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

**alwinus** · 2015-10-21, 21:32

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.

**AchimTuran** · 2015-10-22, 07:42

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.

**alwinus** · 2015-10-31, 09:22

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