Isn’t this just double added after the performed deletions?
aha, I missed that, as that wasn’t mentioned in the first post ![]()
The plays are 13 seconds apart, sent by 2 different apps. You can see the exact date in the HTML code or via your API data.
data-date="2024-07-01T16:29:17Z"
data-date="2024-07-01T16:29:04Z"
As long as it’s not multiple movies of different titles with the same watch date/time. I’m putting all my unknown watch dates under January 1, 1950 at midnight.
Maybe this is a seperate bug, but reading the forum it seems everyone is being pushed here. My views were removed but there is no wy they were duplicate. Example
I watched this entire show and each episode I know I manually checked on the website because I watched them sitting at my computer. There was no app or anythign checking for me. It was me checking.
BTW this happened to ALL my shows. I already re-checked some (had to do “on air date” instead of when I actually watched them)
Here is what I’m seeing for example for survivor. I have definitly watched and checked manually every episode of that show.
EDIT: This has been fixed by the higher ups. I was special, nothing to do with “duplicate watches”
I hate the change!
I have used the “release date” to mark as watched more than once… For me wasn’t a duplicate. And now I lost a lot of views I marked as “release date” in this almost 10 years member
… And I know I’m not alone on this.
You could at least consider that all “release date” is not a duplicate.
I love this site. I spend hours here. But every time you guys “change the rules” I fell betrayed. ![]()
Yeah, I’m in the same boat. We were told to use Release Date when we don’t know the date, and I’ve done exactly that to mark multiple views, and now they’re all gone.
Most movies predate Trakt, so how in the world should I have marked them to keep the data safe?
I really enjoyed looking back on old movies and seeing how many times I had watched them, and what movies I had watched the most times.
After 12 years of building my data like this, it’s been erased in seconds due to making your data more accurate.
![]()
There were so many better ways to do this. Making it optional or just filtering it on the backend. You should never delete data that you don’t understand. If you wanted to not count duplicates in your data, just filter them out instead, and leave my data alone.
But I guess it was never my data to begin with, at least that’s clear now.
Thanks for all the memories Trakt, shame you deleted them though. I’m out.
It is a holiday in the US, but we’ll be discussing the release date duplicates early next week to see what can be done.
For context, we are talking about tens or even hundreds of millions of duplicate records. To increase performance and reduce the data size, it can’t just be filtered out unfortunately.
In general this is fine. The issue is multiple plays for a single movie/episode added on the same release date and time.
I get it, I didn’t know the data issue was that large, but to punish good data (and users) to remove bad data is a step too far, especially (basically) without any notice.
Thank you for responding and looking into a possible solution though. (The saying “Good guy Justin” holds up it seems.)
I’ll do my part and think of some possible solutions:
- Since you know the origin of the entries, why not leave manual entries alone all together? These cannot possibly be a large part of those millions of duplicates, and I would think the number of 3rd party tools used to add legitimate duplicates are very low.
- Entries that predate Trakt should be left alone. This should basically be the same entries as above, but maybe you don’t have origin of all the entries, so maybe this makes sense anyway. 3rd party tools adding historical duplicates would probably be less of a problem, if any. This wouldn’t help me 100% though, since there are definitely movies from the past decade that I just don’t know when I watched, thus using Release Date. This also wouldn’t help newer users, not all of us were here from the start.
- Make a tool to let the users clean (or restore) their duplicate data. Might be a big ask, but I’m adding this since your own developer said that it was a viable thing to do (but alas, it is not viable for little old me, I’m just a script kiddie).
I’m sure you have more/better ideas yourself as you know the data, but I’ll add more ideas if I think of them.
Have a nice holiday.
Nice one
![]()
What, if anything, came of this discussion? Since Trakt adamantly refuses to support plays without a timestamp (requested in several places over the years, now canonically here), the best workaround we all had to track things from before we joined the site was to pick some past date.
This deduplication has wiped out all of the extra plays I added for shows or movies I watched repeatedly, for example reducing my play count of every pre-Discovery Star Trek series from 4-5+ to 2 or 3. I could go back and re-add things with the times incremented by 1 minute for each repetition, but I’d like to find out if there’s any forthcoming solution first.
I’m still wondering the same thing, I had hopes from Justin’s response, but then they went back to radio silence, which was a complete disappointment.
With this change, and now Trakt putting a lot of time and effort into a (horrible) redesign instead, I’m starting to look for alternate options unless there is some information about their upcoming changes.
At the moment, all the recent changes doesn’t feel like Trakt any longer, so I fear they’re changing the course into a place I have no interest in following.
A total bummer, of course, but they can do what they want. But them having such completely awful information about their upcoming changes are just astonishing me every single time.
Just talk to your users. Communicate. How hard is it… ![]()
I’m glad this is baseline now, thanks. I can finally retire the script I had for cleanup (which at times had quite a lot of monthly visitors). As Justin pointed out, there was a lot of crap data around.
As for duplicate plays at the time of release? I get that it sucks for repeat past viewings but it’s not correct data either. The site should at least block being able to add those duplicate plays though - would make things more transparent.
Wow, what a horrible, terrible decision. If I don’t know when I exactly watched something, but I do know I’ve watched some movie or episode once, 3 times, or maybe more, then I have checked in that movie or episode 3 times on ‘release date’. Now it’s all gone. It’s as if millions of voices suddenly cried out in terror and were suddenly silenced.
Thanks a lot for considering human use cases as opposed to media center apps I’ve never used, which you definitely have logs of which you could’ve cross-referenced with in order to apply deduping in a targeted way. You could’ve also simply checked if these duplicate check-ins happen to be exact matches to the release date or a previously set release date to prevent false positives.
But I want to keep all my duplicates!
There isn’t a valid reason for allowing plays with the same watched date and time. You can only realistically watch a movie or episode once at a specific date and time.
This is poor reasoning, there’s a perfectly valid reason above for you. Barely any user ever actually watches something on the exact selected time of release, so with your above reasoning you should’ve started by removing that checkbox. You don’t have an “unknown” option and instead of implementing one you do this kind of destructive action and then think of poor counter arguments in advance. I deduced it over the past months as I noticed repeated check-ins with ‘release date’ selected would not appear. And I noticed many movies or TV shows I have watched more than once were now marked… as only viewed one time. I know Trakt has caching issues and connectivity issues now and then, but this was too consistent of a bug to not trigger my suspicions. Sadly, I was right.
The correct way to make behaviour altering changes like this is to make a change going forward and make it clear in the UI. You haven’t even bothered yet to add a new ‘check-in time already exists’ error. You could’ve targeted the unlikely use case where someone has checked in to the same thing over 10 times, especially when these 10 actions were taken within 10 seconds or whatever you could suspect buggy media center apps behave like. But you forgot that users use this platform for tracking, just because you never bothered to check in things you’ve watched before you joined or started Trakt.
Executing untargeted destructive actions just to save meager kilobytes is not worth it. This makes the platform unreliable. Also this textbox is tiny as hell (why even block resizing it), but I think I removed most of my cursing. Typing it in helped with the months of frustration. I really like Trakt, but what a poor decision this was. I needed to rant. I hope some of it can be considered useful feedback. Fuck.
Seriously. Let us know what is the benefit of knowing you watched say The Boy S01E10 on 1/1/2023 8:46pm ten times. Or captain marvel on 5/8/2020 10:10pm 50 times???
Why does this site exist? To track what I’ve watched, how often I’ve watched it and when I’ve watched it. It’s fine if you don’t rewatch anything, if you don’t care about your watch statistics, hell maybe you are here just for reviews or meming on the forum. All good. Many users have many use cases. Yours is as valid as mine.
I get that it sucks for repeat past viewings but it’s not correct data either.
I try to check in at the correct minute. I’m willing to bet you’re nowhere as precise as I try to be, so I really do appreciate your appreciation of correct data.
If I can’t pinpoint the when but I am forced to choose a when, then I’ll go with the one date I know is a placeholder: release date. The amount of times watched will be correct and, let’s be honest, that (hours/number of times watched) is more important to most users than getting the precise minute correct.
If Trakt is unable to determine whether adding x repeat watches was a manual action or done by an unreliable third party app, they should not conduct destructive deduplication. It’s as simple as that.
You’re absolutely right. I’m now afraid that if going forward I pick release date, then uncheck the release date box, then add 1 minute to it… 10 years from now Trakt will decide:
You can’t possibly have watched this movie twice with just one minute difference? was your left eye out of sync? why would you possibly want these check-ins?, I’m going to nuke your check-ins that overlap with each other or with anything else since you can only watch one thing at a time
To prevent this particular [admin action use case] I will pick a year that doesn’t ruin my data and a different day for each watch… Say I’ll check in at the first year available, 1950. Will they decide tomorrow that:
Your birthdate doesn’t match your check-in. You weren’t alive. This 2030 tv show wasn’t even out. You’re probably not a time traveler. I’m gonna nuke your check-ins again!
The unpredictable factor here are not our check-ins, but future destructive changes by staff. At some point one of them is going to argue that check-ins before Trakt went live are impossible, and finally someone will put forth:
imagine how many gigabytes we can save if we just wipe all check-ins before [user account creation date]
I suspect making dates optional saves more kilobytes.
Oh please.
That is totally valid. Granted not for movies. But for tv shows. Maybe a few minutes off due to commercial breaks.
Lots of people care about accurate data and timestamps. I’ve barely added anything before account created date. Except some tv shows I watched as they aired.
You don’t win anything by having 10 plays of Harry Potter. Not even bragging rights.
This is an interesting take. I thought of the change more so as a clean up of the platform, but I honestly agree that if I had watched something more than once I’d want to recall it.
And you can still mark multiple watches with no problem. Just marking these watches all at the same time or even a couple minutes apart - makes no sense at all.
This change was a good call to prevent accidental duplicates
