Please see this previous content report.

sorry, but I don't understand the logic behind this.. and I noticed many people doesn't too.

Please see where it's stated at https://www.themoviedb.org/bible/tv/59f743289251416e71000037#5b71c6b4c3a3684161000001 that "Long-running series with continuous episode numbers (e.g. 867, 868, 869) are added as a single season."

What TMDB calls seasons are only for dividing up episodes when the numbering resets to episode 1. How they were produced is not relevant; TMDB goes on how they're numbered.

If you were to divide the episodes into seasons, then the episode numbers of the second season would be wrong because they don't start at 1.

I think this is an issue where we're debating whether the absolute numbering is more important than the relative ones.

Personally speaking, the absolute numbering is pretty irrelevant to me and I'm guessing most other users (since like 95% of other source providers use relative numbering for seasons). Unless you can point me to a usecase where the absolute episode number is the more relevant one to use.

My suggestion is that the current guidelines seriously needs reviewing and updating so that if a series is canonically known to have another season, then we should follow that convention to avoid any confusion amongst the community as well as external API integration issues which expect to work with multiple seasons.

And if they'd like to have that piece of extra information as to what the absolute episode number is, they could easily calculate it off the season episode count or the database/backend updated to support a new "absolute episode" type field. It could be programmatically calculated if it's easier on the backend. We could even introduce an "episode offset" field for each season or series (which can then be used to display an absolute episode count regardless of if the series is split into seasons or its own show), and then the UI/app in question determines what to do with the additional episode count information.

I'd argue that makes more logical sense than the current plans of getting Travis to merge older series into a monolithic single season (and potentially break other existing integrations which currently work fine since they were expecting multiple seasons).

Ultimately, I think there should be a solution that should work for everyone (both the mods and the community) without the continuous arguments or breaking existing API integrations/behaviours.