[h0d3nt3uf3l]

Hi all,
on the youtube-plugin I have the problem, that the login will abort after exactly 30 seconds. The error occured between Kodi 17 nightly from 2016-05-13 and 2016-05-28.
Are there any new "features" that will remain a sleep for more than 30 seconds? There is a looping sleep for checking if data is received for 120ms. It's looping for 10 minutes if there are no data
received normally. But like I wrote, this loop will be aborted after 30 seconds. Not with a simple abort or the loop will be left normally, the addon just will be reseted without any information.

Hope you can help me because I don't find the bug in the addon

[nickr]

debug log (wiki)

[h0d3nt3uf3l]

Sorry.
http://pastebin.com/nepQD9Zh

[h0d3nt3uf3l]

Anybody an idea? This issue is very annoying

[JinJin]

Hi,

i need to push this as im having the same problem with dialog.input().
Kodi is killing the python script while trying to enter my credentials.

"script didn't stop in 5 seconds - let's kill it"

As stated above from h0d3nt3uf3l you can reproduce it with the youtube addon.

[FernetMenta]

Scripts executed from PluginDirectory are supposed to return within 30 seconds or they are considered dead and are killed. Assume the script dies, Kodi has to take some actions. Feel free to propose better solutions.

[JinJin]

Thanks for the reply.
Is it possible to simply exclude or increase that timeout for xbmc.dialog?

[FernetMenta]

No, because Kodi does not know that the plugin has launched any dialog. PluginDirectory is supposed to fill in the items. Kodi executes the plugin script asynchronously. If the plugin calls back into Kodi and opens a dialog Kodi can't know.
Why don't you store login credential in the plugin's config settings?

[JinJin]

Well of cource thats possible,
but the dialog actually becomes useless with the timeout.
You will not be able too search anything @ youtube if you're too slow entering the search query when using a remote for example or just have the search box open for awhile and then enter something.

[FernetMenta]

Well of cource thats possible,
but the dialog actually becomes useless with the timeout.
You will not be able too search anything @ youtube if you're too slow entering the search query when using a remote for example or just have the search box open for awhile and then enter something.

what would you consider an appropriate timeout here?

EDIT: maybe I find a way to disable timeout if plugin opens a dialog. Need to dig into the code.

[anxdpanic]

I've ran into issues with this timeout testing with the latest osmc nightlies on rbp2 (16.8-083 was the last without the issues).

A much higher value would seem appropriate if I'm understanding the scope of this timeout fully. It occurs where quite a few scenarios could take a good amount of time on lower end devices or slower internet, especially with a resource heavy skin or being possibly busy with a background process.

- an http(cloudflare)/smb etc request (have their own timeouts which would be no good past 30 seconds - parsing)
- requests to multiple sources creating a single list (ex. twitch/youtube/personal site) will likely timeout on occassion
- a first run sqlite database upgrade on rbps could timeout especially if vacuum'd
- user input that generates a list could easily timeout on awkward input devices
- clearing live previews from sqlite inline with directory listing (especially with vacuum) would timeout on rbps (twitch addon)
- parsing with beautifulsoup is likely out of the question on the rbps (especially if it's content served from slow source)
- retrieving metadata for directory items from an external source (eg. trakt (and back to http timeout length issues)) / metahander / cached sqlite results on rpbs
- possible multiple requests for metadata (list of content with base metadata and separate request for additional metadata per item (eg. trakt movie list + trakt cast per item))
- oauth

I'd suggest 5 mins(bad circumstances/oauth) and, maybe expose as an arg to DirectoryItems/advancedsettings

[FernetMenta]

It won't run into timeout anymore if the script is waiting for user input:
https://github.com/xbmc/xbmc/pull/10080

A timeout of 5 min is not appropriate. No user would wait that long with a not responding UI.

[FernetMenta]

To be more precise on this. Kodi now checks if a modal dialog is running when waiting for the plugin script to get finished. If you want to prevent Kodi from killing the script, you can launch a dialog. Maybe a dialog with a cancel button that notifies the users that this operation may take a while.

[JinJin]

Nice, thank you very much

[anxdpanic]

Thank you

Can I still suggest a timeout of at least 60 seconds?

My thinking being; a common add-on flow is a single http call, parsing and doing something with the data, adding items, resulting in the item list. With the current 30 seconds + dialog, a good amount of add-ons will likely need updating to add the dialog to ensure consistent user experience due to internet/device considerations. Allowing 60 seconds total, 30s (low end of web browser default timeout) + 30s (parsing, adding items, etc.) seems like decent balance for user experience and alleviating some the possibilities of the last issue with the timeout that I see.

The timeout doesn't terminate the plugin/script, which it probably shouldn't if it's unaware(possible db, file corruptions). Degraded user experience and/or starving low end systems of resources could be caused with the same common flow above, no dialog added by developer, and a socket timeout/task greater(or held up due to a running service) than the timeout and the user now selecting another option potentially compounding things. Selecting something after a timeout on my rbp2, it becomes near unresponsive and a second timeout is likely and so on.

And can information regarding the timeout be posted in http://forum.kodi.tv/showthread.php?tid=250936 or somewhere add-on developers can be made aware of it?