Opening InputStream Helper info pane hangs Kodi

[dagwieers]

When you open the InputStream Helper add-on information pane (either by clicking the add-on in the "Add-ons / Recently updated" menu, or by following the dependency of a package), your Kodi completely freezes.

This happened to me on LibreELEC v9.0.2 (Raspberry Pi) as well as on Windows 10 Kodi v18.4.

[mediaminister]

This happens with all InputStream Helper versions on Kodi 18 and higher. No problem on Kodi 17, the information pane just shows up.

[mediaminister]

I found out there is a required element missing in addon.xml, I don't know if this is related to the freezing but it's definitely a good idea to fix this: https://github.com/emilsvennesson/script.module.inputstreamhelper/pull/148

[kekukui]

Confirmed on LibreELEC. An update was offered from 0.3.5 to 0.4.1 but I cannot install it because the Kodi UI freezes when the property panel is opened. On the RPi platform, CPU load on one core sticks at 100%. (This is also a bug in Kodi because it should be possible to cancel instead of freezing the user interface.) Same issue exists in 0.4.1.

---

Kodi debug log

DEBUG: LIRC: - NEW 166 0 KEY_INFO devinput (KEY_INFO)
DEBUG: HandleKey: launch_media_center (0xc3) pressed, action is info
DEBUG: ------ Window Init (DialogAddonInfo.xml) ------
 INFO: Loading skin file: DialogAddonInfo.xml, load type: KEEP_IN_MEMORY
DEBUG: CAddonSettings[script.module.inputstreamhelper]: loading setting definitions
DEBUG: CAddonSettings[script.module.inputstreamhelper]: trying to load setting definitions from old format...
DEBUG: CAddonSettings[script.module.inputstreamhelper]: loading setting values

[dagwieers]

@kekukui Please try release v0.4.0, I am confident it works. https://github.com/emilsvennesson/script.module.inputstreamhelper/releases/download/v0.4.0/script.module.inputstreamhelper-0.4.0.zip

[kekukui]

Same problem with 0.4.0.

[mediaminister]

I did a couple of tests with a clean Windows 10 Kodi 18.4 install:

• rename existing add-on script.module.tzlocal to script.module.inputstreamhelper ==> Kodi freezes
• rename script.module.inputstreamhelper to script.module.ishelper ==> Kodi doesn't freeze, but information pane doesn't open

My conclusion is that Kodi gets no or corrupted info from the repo server. I think the following statements are true:

• script.modules with unknown add-on id to the repo server ==> no information pane is showed
• script.module.inputstreamhelper regardless of the version or package content ==> Kodi 18 and higher freezes

[mediaminister]

As a test I renamed script.module.inputstreamhelper to script.module.ishelper and getting the information pane from the context menu of the add-on item just works.

It only doesn't show up when trying to open it from the dependencies menu, probably because dependencies are checked against the Kodi repo.

I conclude this problem is related to the Kodi repo and the 0.4.1 release.

[dagwieers]

When testing v0.4.0 (granted the add-on ZIP was versioned 0.3.5 then) I have not experienced this either, but someone reported that he also sees this with the v0.4.0 release.

[mediaminister]

This was probably because at that time version 0.3.5 was the newest version in the Kodi repo. I tested yesterday with version 0.3.4 and it also freezed. My conclusion is that this problem occurs for all versions since version 0.4.1 is available through the Kodi repo.

[dagwieers]

So we need to report this upstream? Don't forget your debug log! :wink:

[mediaminister]

I found the problem. Kodi stores the addon.xml data from the repo into Addons27.db. When you load the information pane, it processes this data from the database and Kodi freezes when an add-on has itself as a dependency. Most likely Kodi is trying to read the inputstreamhelper database record that is already opened again for processing the add-ons dependencies.

Final conclusion: we cannot use <import addon="plugin.program.inputstreamhelper"/> in addon.xml

I think reporting this upstream is not a priority, we should solve this by redesigning our api functions.

[dagwieers]

That was my assumption from the start. That's also why I said whether this is still needed when we use RunScript(). We can just do from lib import ... or maybe sys.path.append(os.path.join(os.path.dirname(sys.argv[0]), 'lib')).

[dagwieers]

I guess there's nothing stopping us now from release v0.4.2.

[mediaminister]

I think moving addon.py to the lib directory is a more simple solution. I'll create a pull request for this.

[dagwieers]

The only issue I see with moving it to the lib/ directory is that it is exposed to other modules. Which could be dangerous as it will live in the same namespace as other modules. (For that reason config.py is really misplaced there).

I'd rather leave addon.py outside of lib/ (for module plugins in general) and move inputstreamhelper to lib/inputstreamhelper/init.py (and split it up). But that was planned for v0.5.0.

[dagwieers]

And to finish that line of thought, we should get rid of config.py completely and not expect users to modify running code for changing behaviour. Every change of behaviour we want to allow should be going through settings. Config.py must die, die, DIE!.

[mediaminister]

If you can manage to create a pull request for this today, be my guest. I was thinking about releasing 0.4.2 today...

[dagwieers]

Ok, I have the PR ready, but I think we do hit a real bug in Kodi. It is something I have seen earlier as well.

The dependencies of an add-on are never being cleaned up. So if an add-on removes a dependencies in addon.xml, it will not be cleaned up in Kodi.

When we removed requests from the VRT NU add-on, it carried the dependencies to requests, urllib3, chardet, idna and certifi forward, even when we had no dependency to them any longer.

[dagwieers]

Performing select * from addons where addonID == 'script.module.inputstreamhelper'; in sqlite on the Addons database fixes everything.

[mediaminister]

When we removed requests from the VRT NU add-on, it carried the dependencies to requests, urllib3, chardet, idna and certifi forward, even when we had no dependency to them any longer.

When we removed requests, these dependencies were still needed by inputstreamhelper, so we still needed them to make inputstreamhelper work.

I'm ready to test your PR.

[dagwieers]

When we removed requests, these dependencies were still needed by inputstreamhelper, so we still needed them to make inputstreamhelper work.

~That would be correct, but this was after we also removed requests from inputstreamhelper.~

Update: This was because the YouTube add-on also relies on requests and is an (optional) dependency of VRT NU. So it coincides with the removal of requests from inputstreamhelper.

[mediaminister]

So, you're talking about v0.4.1, because v0.4.0 was never added to the Kodi repo and v0.3.5 still needed the requests library.

[dagwieers]

This was during testing, so they were called v0.3.5, but it was v0.4.0 in testing.

[mediaminister]

I think the current Kodi repo add-on version determines the dependencies. We never had a VRT NU add-on in the Kodi repo with a InputStream Helper v0.4.1 dependency....

[dagwieers]

Ok, we'll see. Fact is that the problem remains with this future v0.4.2, and I guess we will find out when it hits the repository then. The problem remains until you clean up the Addons db, that is for sure.

[mediaminister]

And the Addons db gets its stuff from Kodi repo, that's also for sure. That why it kept freezing for all InputStream Helper versions on all platforms.

[dagwieers]

That is not the case when you install from ZIP at least.