Looks good to me. Technically we don't need username/account in the config for these, but I think it might complicated the schema more than it's worth to fix that.

On second thought, it might not be too bad. I think updating the current 'anyOf' in the config would release the requirement for username for these lists:

        'anyOf': [
            {'anyOf': [{'required': ['username']}, {'required': ['account']}]},
            # The 'trending' and 'popular' lists don't require an username
            {'properties': {'list': {'enum': ['trending', 'popular']}}}
        ],

I haven't tested though, not sure if there are any other implications.

Oh, one more thing. IMMUTABLE_LISTS should be updated to have 'trending' and 'popular' in there, so that a good error message is produced if an user tries to edit them.

Thanks for the feedback. I've updated the PR.

Excellent, thanks! Can you update the wiki with the new options as well?

awesome! only thing i'm "missing" is a limiter. How is this solved? How many movies are "trending/popular" ?

okay.. again, why no limiiter ? Is this really working for you @HeikoBornholdt ? Now i have 155k (155 069) items in my list watchlist .. so this broke my watchlist... and because the main-watchlist can't be deleted, this broke my whole trakt account ...

Sorry to hear that. I agree that we need to limit the number of entries.

I am not sure that we should implement a limiter only for trakt or as global feature for any kind of lists.
@gazpachoking What do you think about that?

Yeah, guess a limiter is needed if those lists are so big. Not sure the best way to go. We could make a plugin similar to limit_new which acts earlier and just cuts off the entries at a certain number (limit_new isn't) appropriate for this case since it doesn't act until after filtering, and adds supplemental entries to the backlog.) This wouldn't be optimal for plugins that have to scan through multiple pages for results, as they'd do extra work if they were getting results past those limits. In that case the only good option I see would be to add limit to the plugin itself.

Easiest way to go is probably just add a limit option to trakt_list. Maybe the default should be dynamic, and set to unlimited for regular lists, but limit popular and trending to something sane by default.

Limit option has been added now in #2366

thank you guys for taking the time!

btw. trakt support was really quick to answer my email back and deleted the watchlist for me. next time i use a custom-watchlist for testing i guess :D