Possibility of sort ordering lists and expanding list items beyond 20

[ghost]

Hi again, was wondering if it's possible to force the sorting of whatever list we synchronize and increase the max number of items beyond 20.

For example I sync to the Top Rated IMDB Movies Trakt list but I usually like to sort by descending release date. Maybe this is already possible to do with custom script tokens?

Also it'd be cool to allow the increase of maximum titles retrieved beyond default 20 for more performing systems (eg.: 50, 100, 150etc). Thanks for all the awesome work!!

[jurialmunkey]

No. The limits are there for a reason.

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/213 https://github.com/jurialmunkey/plugin.video.themoviedb.helper/issues/34#issuecomment-568247204

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

It doesn't matter how fast your computer is because the actual processing of the data is relatively quick. And it doesn't matter how fast your internet connection because the info comes in small text files. What does matter is the speed of the server that provides the API data. You can have the fastest computer and internet in the world and you will still have to wait for the server to provide a response to each request.

The servers provide data to a lot of applications and when that demand goes up they increase rate limiting to prevent being overloaded -- the more demanding apps are in terms of making requests, the slower things go for everyone.

This is why I get annoyed when people are trying to sync lists with 1000s of items to their libraries rather than just adding specific lists of items that they actually might want to watch -- watching a movie a day, it would take you 3 years to watch 1000 movies. Realistically people are probably watching like 1% of the movies they add. It is done for the slightest of temporary convenience for the individual but with an impact which eventually results in massive inconveniences for everyone.

It's important to respect the APIs, otherwise they'll shut-up shop and not provide this data for free anymore.

[jurialmunkey]

For example I sync to the Top Rated IMDB Movies Trakt list but I usually like to sort by descending release date. Maybe this is already possible to do with custom script tokens?

The list will be sorted according to the sort order on Trakt.

However, if you are syncing to library and using the generated smart playlist, then no sorting is applied. I might be able to make it copy the sort method on Trakt, but I can't really think of an easy way to have user selectable sorting.

If you just sync the list once, then you should be able to go into Videos > Playlists and edit the playlist to have the sorting you desire. But if you re-sync it, then that's going to get overwritten.

If you're using it as a widget, a lot of skins provide ways to apply sorting to widgets (e.g. Arctic Horizon allows for widget sorting options).

[ghost]

Thanks for the thorough explanation. I don't use it with integrated library in this case but only as a widget. I force the widget (with titan bingie skin) to sort through release date descending but strangely enough is not working only on the TMDB Helper widget. All others widget sort as requested.

[jurialmunkey]

I force the widget (with titan bingie skin) to sort through release date descending but strangely enough is not working only on the TMDB Helper widget. All others widget sort as requested.

Hmmm, this is strange. Let me have a look an get back to you -- it's possible that it needs a different sort method.

Is it this Trakt list? https://trakt.tv/users/nielsz/lists/active-imdb-top-250 Or a different one?

[jurialmunkey]

You need to sort by "Year" "Descending" -- problem is that those sort methods will only apply per page though, not to the whole list.

Unfortunately the plugin can't see what the "sortby" setting is for the container (otherwise I'd grab that and sort the whole list by it).

If you have a Trakt VIP account, you can copy the items to your own personal list and apply a sorting method. I'll have to think about possible ways to apply client side custom sorting methods.

[ghost]

I'm no programmer but could there be a way to retrieve the raw list without Trakt sorting itself? So to allow custom filtering client side?

Also I was thinking about the 20 items limit in an ethical way: the only reason many users want to go beyond that limit is, I believe, to avoid having the "next page" button to break the flow of a netflix style skin. It's simply a design issue for most (for me at least being a designer by trade).

In the Titan Bingie skin for example it seems it's only the active titles in the page that gets pulled in and as I keep scrolling on titles they get pulled in (they appear and load in a staggered way). So I don't think it loads a bunch of them at the same time? Could this type of incremental item limit have more sense?

[jurialmunkey]

I'm no programmer but could there be a way to retrieve the raw list without Trakt sorting itself? So to allow custom filtering client side?

That's not the issue. The sorting is already done client side. The issue is how does the user indicate how they want the list sorted since the plugin can't "see" what the sortby value is.

There's only ugly solutions -- either it requires a special method added to every skin (so needs special skin support), or it displays all the variations of sorting methods as separate folders and thereby make navigation clunky and difficult.

Also I was thinking about the 20 items limit in an ethical way: the only reason many users want to go beyond that limit is, I believe, to avoid having the "next page" button to break the flow of a netflix style skin. It's simply a design issue for most (for me at least being a designer by trade).

I really wish it were possible for an "infinite scroll" type of situation where the list loads as you navigate right, but unfortunately the Kodi doesn't provide any methods for it.

Lists basically work like so:

• Kodi calls the plugin script and passes it the container URI.
• The plugin interprets the URI and runs the appropriate code to generate the list items.
• Once all the list items have been made, the plugin passes them to Kodi and exits.
• Kodi then fills the onscreen list with the items.

So by the time you see the items and can interact with them, the plugin no longer exists anymore and is reliant on Kodi to call it again to do any further actions.

The "Next Page" item is really just a completely separate folder that runs a new instance of the plugin. It has the same URI as the original list except the page number value is incremented by 1. So when you open this "new" folder, what happens is the plugin calls up the same list (because same URI) from the cache but the items returned are for the next "page" -- i.e. it returns the items in the list at an index between (pagenum - 1) * itemlimit and pagenum * itemlimit.

An infinite scroll would require a special Kodi method calling the plugin after the user scrolls past a certain threshold - then the plugin would return the next page folder using a new special "add to container" method. There's no such method and very few existing devs knowledgeable enough in GUI Lib that also have free time to implement such code in core.

In the Titan Bingie skin for example it seems it's only the active titles in the page that gets pulled in and as I keep scrolling on titles they get pulled in (they appear and load in a staggered way). So I don't think it loads a bunch of them at the same time? Could this type of incremental item limit have more sense?

Nope. It doesn't work like this at all. All you're seeing is the artwork loader trying to catch up with loading the visible items -- Kodi only loads the artwork into GPU memory for the visible items plus a few extras either side because it doesn't make sense to chew up CPU/Network/Disk bandwidth and GPU memory by trying to load all the images in the list at once when they aren't even visible.