Invalid data checks
https://trakt.tv/movies/wolverine-3-2017
Example shown in the above movie. The page lists a rating average, views, watchers, plays .... this data is really not possible. Is there anything that can be put in place to prevent such data from falsely manipulating data?
Same with "RELEASED March 3, 2017". It is not released, but to be released. Since this data is often added early at the sources of data, maybe have a check and where the date is after current day, display To Be Released and if today or earlier use Released?
On the plays being recorded, I assume what is happening is the same as last.fm and the scrobbles there. The meta data being scrobbled is incorrect and/or the download someone grabbed is labeled said movie, the the actual video is different, junk or some sort of virus. At last.fm, it can detect some of this and displays to the user to correct their meta data. In this case, using their method would not work, but I just show as example of what is being done with similar issue elsewhere.

Please see comments. Text change is live.
-
AdminJustin (Founder, Trakt) commented
Yeah, if an app or scrobbler is relying on name based matching the results won't be as precise. We do give the developers the tools to specifically check fields (i.e. only the title) if they want to, but like you said its ultimately up to them to implement the best logic they can.
-
thwaller commented
Good on the text change. I did think about your statements on the data issues. You are correct completely on the release dates. Two biggest ones I see are the dates in other countries and Screener copies. As to how, there is another issue I would like to add on that. Using Kodi for example, the play can easily be recorded wrong. I have had items marked as played that are not even close. Meaning I watch an episode My Episode from 2015, and it marks in Trakt a movie Movie Sample from 1982. No similarity of date, series name, episode name to movie name, nothing at all. In this case, the onus is on the developer of the scrobbler though. Meaning that if the scrobble is not a valid match, instead of using some sort of fuzzy logic to ask the user exactly what was scrobbled. On the Trakt end, the API could kick back a message asking if you are sure of the match, but this would also need to be handled by the scrobbler.
I think manual watched marks would be much easier to error check, but with an open API, there is not much you can do as the developers are not controlled or monitored. A monitor meaning, for example, that a user can mark a scrobble as incorrect, and Trakt database has record of what executed that scrobble. Yes, errors will happen, but at a certain threshold, the developer is contacted as heads up sort of thing.
In my experience, I would with educated guess say that much of the data errors as mentioned above are due to bad data sent in from scrobblers. There are many errors and warnings that I have experienced on scrobblers that the user is not made aware of and essentially ignored by the scrobbler code.
-
AdminJustin (Founder, Trakt) commented
Yeah, this issue comes up every once in the while. We haven't done anything so far since there are many valid cases with worldwide release dates and early previews. I do agree it would be good to limit it somehow, but I'm not sure what that is yet.
The text change isn't a problem, that is a good idea.