Hi TrackTV team,

I know I'm onto a topic that have been discussed already, and I'm trying the shed a new light here, my apologies if this has been already discussed also.

I'm seeing more and more rating on episode that have not been released yet, which is annoying (because it is not very smart) but mostly it is biaising the overall rate of a tv show (unless it gets loads of votes), hence degrading the trust a user can have of TrackTV ratings.

I have seen several other requests that have been denied but none pointing out the negative impact on ratings and user trust. This could also be handled by banning early rater from rating a new show for example ?

Many thanks for your help
KR
François

Hey. Just a question... The time a show is broadcast was being pulled from TVDB, right?

In their new website it's impossible to add that info anymore to new shows. So, weird things happen. Example: this TV Show https://trakt.tv/shows/bailando-con-las-estrellas that I added today, it's broadcast on Tuesdays at 10:35pm. Since I can't put the time on TVDB, Track.tv shows the episode date/time as (using yesterday as example) May 15, 2018 00:00. But, I'm in Portugal then, with the production info correctly added in TMDB, that episode is shown to me with the date/time May 14, 2018 23:00 (11:00pm) because of the time zone. This is: the first episode it's shown to me almost 1 day before it really was broadcasted...

I know this is a problem of TVBD but already plenty people talked about this on their forums and none good response was given (at least, none in the topics I have seen) and, if I try to ask them about this problem, I'm almost 100% sure that I'll get a pseudo-arrogant answer saying something like "that's a Trakt problem, not TVDB's" as I already see plenty of times.

In conclusion, the main reason for me to write you here is to let you know the existence of this problem (if you didn't already know) and, maybe, the Trakt team could talk to the TVDB team to come to a solution for this problem.

Thank you.

The Episode Count in Magnificent Century is factually incorrect. Season 1 is correct with 24 episodes and the correct airdates - Although you do have 25 listed, with the 25 episode having no airdate. However, Seasons 2 should have 39 episodes, not 63 and some of the airdates are incorrect. Season 3 should have 40 episodes, not 92 episodes. While Season 4 should have 36 episodes, not 82 episodes. Although you have Season 5 on there which is also factually incorrect as the show finished after Season 4, therefore Season 5 doesn't exist.
Here at TVDB: https://www.thetvdb.com/?tab=seasonall&id=228921&lid=7 - it supports this, should be 139 episodes in total.

It'd be great to be notified on the Dashboard when there's a special showing happening near me of movies that aren't new releases. There are lots of small, independent theaters that do special screenings, re-releases, or film festivals, or whatever.

For example, I had Vertigo on my Watchlist, and there was a showing at my local theater, and it would've been great if that appeared on my Dashboard.

I know getting to that data is difficult, and a lot of it is probably impossible to get in a usable, automatable format, but there are a lot of showtime sites that probably have APIs, or you could even allow people to add Facebook feeds or iCal links to their favorite theaters, so you gradually build a database of smaller theaters that way.

Recently you had an all around update on comments. Great! Finally!
Yet it wasn't anything like reporting comments, or giving us a way of ignoring certain people. But at least a step in the right direction. But one thing in particular is disappointing here:
It seems you did the same mistake again as you did with last_activity.

In terms of last_activity:
If a user edits any comment, commented_at of that user would change.
But you'd have to sync ALL comments ever written by that user because you have no chance knowing what or how many comments were edited (or in this context unfortunately "commented"_at).

In terms of comments/recent:
Again, editing a comment isn't well-thought-out. comments/recent wouldn't change the position if a user edits a comment. Given the fact that last_activity changed I'd expect that comments/recent updates as well and puts the updated comment at the top.
But it doesn't, it stays where it was before, it orders by created_at only.
That means with comments/recent I can only sync comments at a specific point in time. It's basically impossible to sync once and update as needed.
If comments were changed (and I'd have to assume constantly that's the case) I'd have no idea how many comments were changed and I'd have to call all 141640 comments again (worst case) to check.

And why is it that replies aren't in this endpoint? Don't they count as comments in this instance? I feel your wording is highly inconsequential on several occasions leading to issues on where the API goes.

Then there's the issue with likes. Liking a comment changes that comment as well indirectly. But I have no way of syncing/checking that either efficiently.

You seem to create one endpoint after the other to do basically the same thing just with different responses but the same issues.
That reminds me of v1. I'm not seeing the intricate cogs of your API from within but I see it from the outside and what I see is you're doing the exact same mistakes again you did back then with v1...

All we need is a simple way of getting either all or a specific user's comment objects (where replies are considered as comments) and an endpoint to check for comment changes with the changed comment's ids returned, not the timestamp of the last change. The latter is a completely useless information.
Whereas a comment is considered to be changed when: (un)liked, replied to, edited, user rating changed (where possible), or even created.
Endpoint: comments/changed
OrderBy: updated_at
Page and Limit as usual
Returns:
[{
trakt_id: n1,
likes: m,
replies: m1,
user_rating: n2 || null,
created_at: xy1,
updated_at: xy2,
parent_id: 0 || n3
}, ... ]
(Being nitpicky as I am you could then support /comments/[:ids]/* endpoints to lessen the requests, that's what I would do in your position at least)

How would you go about syncing comments of a or all users with your own API as of now? Including updates.
I don't see how that's possible without missing some crucial information or hitting your servers with redundant requests, doing twice or more work on any side involved.

In the on deck and progress sections, setting to "recently aired" will sort correctly by which show had the most recent episode, but it'll show an episode that is not next-to-watch for me.

For example, if I have a weeks worth of episodes for several shows, it sorts properly, but as soon as one show airs another episode (without being watched yet), the "on deck" will show me the latest, effectively skipping the correct next episode to watch.

Ideally, I'd like a reverse-direction sort of "previously aired" for on deck, showing only my personal next-to-watch episodes sorted by their air date.