Plugin.video.themoviedb.helper: Request - Number of items in a list / page size limit

[dinkysniff]

Hey jurialmunkey,

Wondering if it's possible to remove the number of items in list page limit?

The purpose is to make tmdb helper source of widgets without having 'Next Page' appear. This would be extremely useful especially when working with longer lists as source for widgets. Currently set at 20 items and would be great to have an option in settings to make this 50 / 100 / no limit.

Thanks

P.S. fantastic add on!

[jurialmunkey]

No. The limits are there for a reason.

TMDb lists are hard coded server side to provide 20 items per page.

Trakt lists can be expanded but I won't do that since Trakt lists require 3x individual lookup PER ITEM (one to get details, one to get fanarttv, one to get watched status). That means a list of 100 items is going to take a very long time to load (300 individual api requests for one list for one user!). Also, some Trakt lists have 10,000+ items -- that's a very quick way to get my API keys banned.

Covered this point many times before:
https://github.com/jurialmunkey/plugin.video.themoviedb.helper/issues/56
https://github.com/jurialmunkey/plugin.video.themoviedb.helper/issues/91
https://github.com/jurialmunkey/plugin.video.themoviedb.helper/issues/65
https://github.com/jurialmunkey/plugin.video.themoviedb.helper/issues/34#issuecomment-568247204

[SerpentDrago]

Jurial to expand on this point . now i know your not the skin shortcuts dev or anything . but you are a dev and i always wanted to float this one by you .

I think the major issue is people in a widget especially would love to be able to "load the next page" without it then going into inside addon library view modes. to load the next set of 20 items IN that widget .

Say you got a widget on home screen . you hit the 20th item in the list and the next page button . would there be ANY way widgets could be programmed to load the next 20 items dynamically refreshing that list without say reloading the entire hub / home screen .

Do you get what i'm saying ?

If that could be done somehow / skin side / new addon / addition to skin shortcuts . something . I think this would be revolutionary and prevent the need for people wanting more then 20 items in a list

[dinkysniff]

Thanks SerpentDrago, that's a much better way of explaining what I meant. A dynamic refresh of the next 20 items would be ideal rather than taking you out of the widget and back into the add-on.

Jurialmunkey, appreciate all the work you do. No sweat if this can't be achieved.

[drinfernoo]

@SerpentDrago I've had this concept in a back corner of my mind for a bit now as well, and the only thing I can come up with is that there would need to be significant changes at a number of levels, or some combination of them; between Skin Shortcuts, Kodi's skinning engine, Kodi's Python runtime, and the plugins themselves.

I currently do something "similar" (also "similar" to how add-ons can refresh widgets like "Next Up" and the like... by updating the contents at the path the widget points at, and then updating the library. For AutoWidget shortcut groups, their URI doesn't ever change, but the contents of the menu do, so the widget updates whenever that happens, because the path hasn't changed.

The trick is that if a path has something like plugin://plugin.video.example/abc, and the items that get populated by that call get changed, then the widget will update without a skin reload. I'm not sure, to be honest, if this is an "feature" of Skin Shortcuts or Kodi core, but I'm certain that they work together to make it work.

In the case of "paged" lists and such, they typically have a URI parameter like page=1, and the number is incremented per-page. Unfortunately, that is then a different path, and won't update fluidly. If plugins were to change their paradigm so that the current (or next, maybe?) page was persisted in a way independent of the URI, then this type of thing _may_ be easily doable.

@jurialmunkey I'm actually interested in your thoughts on this idea, as well 😉

[jurialmunkey]

@drinfernoo

The trick is that if a path has something like plugin://plugin.video.example/abc, and the items that get populated by that call get changed, then the widget will update without a skin reload. I'm not sure, to be honest, if this is an "feature" of Skin Shortcuts or Kodi core, but I'm certain that they work together to make it work.

Widget containers don't update when content changes. Plugins exit after load, so there's nothing monitoring for changes. Every "reload" is Kodi spawning a new plugin instance.

What really happens:

1. User stops media playback or updates library, both which trigger Kodi to refresh ALL containers.
2. Kodi creates a new plugin instance for EVERY container by passing the URI and container handle.
3. The plugin reads the URI and runs the relevant code to create the list items.
4. The list items are passed to Kodi with the container handle and the plugin exits.
5. Kodi clears the old items from that container handle, and then adds the new items.

It looks like only containers with new items are updating because the container isn't cleared until point 5 (whereas reloadskin clears containers at point 1). In reality, every single widget has re-run its code and reloaded all the items -- this is why caching in plugins is so important.

The other thing that causes a container reload is if the URI changes. For plugins that use &key=value type paramstrings, you can leverage this fact by passing a fake param not normally used by the plugin to refresh the container on a certain condition.
For instance, this path will update every hour because System.Time(hh) changes every hour:

plugin://plugin.video.themoviedb.helper/?info=popular&type=movie&dummyreload=$INFO[System.Time(hh)]

If you use something like $INFO[Window(Home).Property(WidgetReload)] instead, then you could trigger a refresh by changing that property.

In the case of "paged" lists and such, they typically have a URI parameter like page=1, and the number is incremented per-page. Unfortunately, that is then a different path, and won't update fluidly. If plugins were to change their paradigm so that the current (or next, maybe?) page was persisted in a way independent of the URI, then this type of thing may be easily doable.

Not possible since every refresh is a new instance. The only way to reliably keep track of the page is by using a parameter.

[drinfernoo]

Widget containers don't update when content changes. Plugins exit after load, so there's nothing monitoring for changes. Every "reload" is Kodi spawning a new plugin instance.

Of course; that's why I trigger a library update afterwards, but I'd love if it didn't need to refresh all containers at the same time.

It looks like only containers with new items are updating because the container isn't cleared until point 5 (whereas reloadskin clears containers at point 1). In reality, every single widget has re-run its code and reloaded all the items -- this is why caching in plugins is so important.

I'm aware of this as well. Again, a bummer of doing it the way I do.

The other thing that causes a container reload is if the URI changes. For plugins that use &key=value type paramstrings, you can leverage this fact by passing a fake param not normally used by the plugin to refresh the container on a certain condition. For instance, this path will update every hour because System.Time(hh) changes every hour:

So you could conceivably update the path with the URI for another page, without triggering a Skin Shortcuts rebuild?

If you use something like $INFO[Window(Home).Property(WidgetReload)] instead, then you could trigger a refresh by changing that property.

Not possible since every refresh is a new instance. The only way to reliably keep track of the page is by using a parameter.

If an add-on was so inclined, couldn't it run logic to update a property, in that way, to indicate the page that should be displayed? And then, updating the property would update the displayed page.

[jurialmunkey]

@SerpentDrago - It's an interesting idea, and it might be possible.

You wouldn't be able to return back using the back button -- there would need to be a "previous page" item. Not that big a deal, but is a little annoying.

I'm also not sure if the page would reset or not if Kodi triggers a container refresh. If it does reset, it would be annoying if you're navigating. However, if it doesn't reset, the items shown in the page could still change (e.g. new releases are added which bumps the list down). Also, then the only way to get back to the start is either manually navigating back each page or by reloading the skin.

I have an idea of how to implement -- it just depends on how well it works.

[SerpentDrago]

sounds good , i think you can see the value if it can be done.

[jurialmunkey]

@drinfernoo

If an add-on was so inclined, couldn't it run logic to update a property, in that way, to indicate the page that should be displayed? And then, updating the property would update the displayed page.

Since you can have multiple widgets, each container would need a uniquely named property.

That won't work because each the new plugin instance won't know what the old plugin instance named the property.

• Can't get the property name from URI since Kodi converts $INFO[] before passing the URI.
• Can't use container handle since each refresh is a new handle.
• Can't use container ID since you can have multiple containers with the same ID or no ID
• Can't use other URI params because two widgets of the same type will have same property.

You could do it from the skin side. Add the page param and property to the end of the URI, hide the normal next page item and instead have a custom next page item which updates the property -- but that's a pretty ugly approach which would require bespoke code for each plugin.

[drinfernoo]

@jurialmunkey While I agree it's not necessarily an easy approach for add-ons to implement, AutoWidget actually works almost exactly like that.

Each AutoWidget path has a UUID passed as an URI parameter, and when the widget is "initialized", AutoWidget finds it and saves various details about the path (and where it was found) into a JSON file.

That file is then used later on to figure out which widgets to refresh, and how to do so.

Any add-on could implement similar logic inside their own paths... but it was far from a simple task.

[jurialmunkey]

You have the opposite problem with a UUID hash -- it will only work for widgets created by skinshortcuts or via normal browsing. It won't work for anything included with the skin such as info dialog lists or custom windows as these need to be hard coded and so won't have a UUID param generated. The skinner could make UUID, but it does make things more complex.

Also, if we're only talking about updating the container with the next page, a much simpler method already exists. You can tell Kodi to update the existing container by setting updateListing=True when calling the endOfDirectory method -- EDIT: Scrap that - updatelisting only works in the library.
https://codedocs.xyz/AlwinEsch/kodi/group__python__xbmcplugin.html#ga52a8af0460894fa918c6a20d8d77fff6

[drinfernoo]

@jurialmunkey, above you said:

If you use something like $INFO[Window(Home).Property(WidgetReload)] instead, then you could trigger a refresh by changing that property.

And I'm attempting to do just that, using an $INFO[Skin.String(...)]... Is that not doable?

It seems that the path is updating correctly, but the widget won't update unless I update the library or reload the skin.

[jurialmunkey]

Depends on how you're adding it to the path.

It needs to result ultimately in a skinshortcuts-includes.xml file where the widget has a content tag like so
<content>plugin://my.plugin/?info=foobar&amp;property=$INFO[Window(Home).Property(MyProp)]</content>

If the path in the content tags changes, then the container updates. Because the skin evaluates $INFO[(...)] every X cycles, changing the property value will cause the container to update because it essentially has a new value.

e.g. if MyProp = Alien the path evaluates to:
<content>plugin://my.plugin/?info=foobar&amp;property=Alien</content>

and then setting MyProp = Predator, it changes the path when it evaluates to
<content>plugin://my.plugin/?info=foobar&amp;property=Predator</content>

It shouldn't matter what info label is used. However, you really shouldn't use skin strings in general for this type of thing unless the value absolutely needs to persist when kodi exits and restarts. Skin strings need to be written to disk in userdata/addon_data/skin.name/settings.xml whereas window properties are essentially just variables in-memory.

[drinfernoo]

Ah, I see! It seems when I was passing my URI, it was encoding the $, [ ], and ( ) in there 😅 Having fixed that properly, updating the property does cause the widget to update :+1: