[Question] TMDBHelper.ForceWidgetContainer

[inb4after]

Following from this comment about an addition to TMDBHelper, I created a commit to enable TMDBHelper service monitor to use widget containers other than the info'd item inside DialogVideoInfo, which resolved this issue that existed prior.

Unfortunately, this caused some issues, and I'm wondering why they happen and if it's possible to resolve them.

• Performance hit

Opening DialogVideoInfo for an item, choosing other items (Similar/Recommended) and continuing to deeper levels, and returning back to the original item have all slowed down. It takes around 1 second longer and then exponentially slower on deeper levels (on PC) to complete these actions. Is this because TMDBHelper is trying to track all the details for all the widget containers at once?

AFAIK this is how the custom Cast & More overlay tends to load in anyway, so enabling ForceWidgetContainer will definitely make things slower?

• OMDb rate limit is reached very quickly

Often when focusing items in the widgets, especially if that item has not been focused before (and the ratings aren't cached), we get a notification of Connection Error to OMDb - Suppressing retries for 1 minute. In my normal usage of the skin, I have not reached this point where rate limits occur. However, on the new commit, navigating through and opening these newly focused/opened items, it reaches the rate limit almost immediately. Could this be solved by using Container.ListItem.Property(X) instead of Window(Home).Property(TMDBHelper.ListItem.X), or do these methods essentially both use SM, but give the info in different ways for easier skinning?

In my usage, I don't view/navigate lists/widgets (forcing new lookups of details) on the homescreen, so I'm not sure if reaching the OMDb rate limit is a common occurrence.

Thanks.

[jurialmunkey]

Forcewidgetcontainer doesn't do anything special - it literally just changes whether the service monitor uses $INFO[Container({id}).ListItem.Title] or $INFO[ListItem.Title] inside the info dialog to do the lookup. You can see the code here: https://github.com/jurialmunkey/plugin.video.themoviedb.helper/blob/matrix/resources/lib/monitor/listitem.py#L11-L24

Most likely you created a recursively loading loop somewhere by basing list content off a service monitor window property. e.g. if you do something like <content>plugin://plugin.video.themoviedb.helper/?info=recommended&query=$INFO[Window(Home).Property(TMDbHelper.ListItem.Title)]</content> you will end up in a loop because when you highlight the list the title changes, which causes the list to reload, which changes the items in the list, so the title changes again, which causes the list to reload again and so on

EDIT: Also, FYI, OMDb lookups are currently only done by the service monitor - so you can only get metacritic/RT/Awards via window properties. All Container.ListItem.Property(x) are created before the container is filled with items and it isn't worth looking up the entire list on OMDb because you'll very quickly hit the daily limit that way. That's the whole point of the service monitor: It isn't possible to add properties to a ListItem after it is created, so instead the service monitor adds the info it looks up about the focused item to a window property.

[jurialmunkey]

Yep you've definitely got recursive loops. For instance, this list is going to be a problem: https://github.com/SerpentDrago/skin.auramod/blob/Matrix/1080i/Includes_Defs.xml#L327 because you are using &query=$INFO[Window(Home).Property(TMDBHelper.ListItem.Director)]

Anything like that is going to reload every single time you move focus because the property it is based off is going to change. So every move you make is an entire list reloading. And if you focus that list it will create a recursive loading loop. That's why you're getting slow downs and hitting limits - because the skin is endlessly trying to load new lists.

[inb4after]

Yep you've definitely got recursive loops. For instance, this list is going to be a problem: https://github.com/SerpentDrago/skin.auramod/blob/Matrix/1080i/Includes_Defs.xml#L327 because you are using &query=$INFO[Window(Home).Property(TMDBHelper.ListItem.Director)]

Anything like that is going to reload every single time you move focus because the property it is based off is going to change. So every move you make is an entire list reloading. And if you focus that list it will create a recursive loading loop. That's why you're getting slow downs and hitting limits - because the skin is endlessly trying to load new lists.

Thanks once again for the thorough explanation! It does make sense to me now and we can try to work around this. I found some other variables which use the window property and disabling these, as well as the content variables you mentioned fixed OMDb rate limiting, although it does happen eventually with normal focusing, but at least not instantly!

https://github.com/SerpentDrago/skin.auramod/blob/5475af908fc20be7bdb68fc50b1768a3342f3cea/1080i/DialogVideoInfo-Includes.xml#L1685

https://github.com/SerpentDrago/skin.auramod/blob/5475af908fc20be7bdb68fc50b1768a3342f3cea/1080i/Includes_Labels.xml#L49

One issue however is the More Info widget, where the visibility depends on Window(Home).Property(TMDbHelper.ListItem.RottenTomatoes_Consensus) and all the details inside this screen are loaded from window properties. The variables here must be disabled or we get the OMDb rate limit. However, we naturally lose all functionality of this widget if we navigate into a deeper level away from the parent item.

To make this work, would we have to remove this widget, create a completely separate overlay that toggles on a button "More Info" and disable all the window property lookups in the new overlay if More Info overlay is not visible?

[inb4after]

I've used a workaround of changing the More Info visibility condition to ListItem.DBTYPE=movies (as TV shows don't have critics consensus) which allowed reworking of window property code that would cause the performance hit and OMDb rate limit issues!

Thanks for your help on this issue, I would not have been able to debug the problem like you expertly did here!

[jurialmunkey]

BTW - The number of window properties you use doesn't make any difference performance wise. The service monitor is an off or on type of thing - either it does the lookup for the focused item, in which case it fills all the window properties; or it doesn't and the properties are blank. It doesn't care whether you actually use the properties or not.

If you're having performance issues with a section that just displays window properties as normal labels, then that's some other skin issue. If you've got plugin <content> reloading that will cause performance to dip, but the performance hit caused by the service monitor should be consistent because it is always running regardless of whether you use it (unless of course you specifically disable it).

In terms of OMDb "suppressing retries" connection issues. These occur if multiple requests to OMDb return a 4XX error code in short period of time - TMDbH stops asking for data for a while because there's no point flooding the server with requests if we aren't getting data back. 4XX errors general happen because either:

• Hit OMDb daily request limit of 1000 requests (it treats a rate limit the same as invalid API key and sends a 401 code).
• Too many requests in a short period (so server rejects to prevent DDoS attacks).
• Server issues (e.g. maintenance etc.)

If you hit your limit, you hit the limit and OMDb isn't going to work for 24 hours (though anything cached is still going to work). If the down time is considerably shorter then you probably just got temporarily booted because the server can't keep up.

[inb4after]

Gotcha. The bugs were noticeable, the widget sidemenu label would continuously appear/disappear depending on the focus in other widgets.

It was definitely the skin looping the visibility of More Info when focus changed (as the visibility condition was based on the critics consensus home window property), which must have caused both of these bugs, rather than the home window properties inside More Info. 👍

[inb4after]

@jurialmunkey

In redesigning the home layout, I've run into the reverse issue with service monitor where ForceWidgetContainer makes no difference and I'm hoping there's a easier workaround or solution for this instead of adding more includes/using container listitem infolabels instead, for specific containers such as the spotlight.

Spotlight focused, spotlight meta shown on spotlight: https://i.imgur.com/UfFYN18.jpeg (expected)
Widget focused, widget meta also shown on spotlight: https://i.imgur.com/jhW9OZA.jpeg (bug)

Could the service monitor theoretically support multiple containers in this way, or is this a Kodi limitation?

Thanks in advance for any advice on this