Trakt lost its config

[Samkook 19]

I went to my trakt account today only to realize it had been deactivated for inactivity and I lost everything on there that accumulated over the past 6 years or so.

I then went to check in emby and the pin was gone from the config somehow.

So basically my question is wtf happened? Why was my config wiped with no warning.

[Luke 42533]

Hi, that's strange. Are you able to configure the pin again?

[Samkook 19]

Yes, I've entered it again and it's still there.

[Luke 42533]

On 2/23/2026 at 2:30 AM, Samkook said:

Yes, I've entered it again and it's still there.

@Samkookhow exactly did you try to do this?

[Samkook 19]

Using the "Get PIN." link below the editbox I'm assuming, don't remember exactly, but looking back to that config page, that's what I would have done.

Before that, it was years ago since I did it(takes at least a year for a trakt account to get wiped beyond recovery).

[Luke 42533]

@Samkook can you give it another try?

[Samkook 19]

Give what another try?

The config got lost mysteriously sometime these past few years without me realizing and doing the config again worked fine so I'm not sure what you're asking me to try at all.

When I said still there I meant that the PIN is still saved in the config, in case you thought I meant the buggy behavior was still there. Nothing is getting saved to trakt, but I'm assuming that's because absolutely everything got wiped and I'd have to run the first time sync to make it work again, I just didn't bother since it's pointless now that I lost all the data, I'll have to find a more reliable alternative to store watch status even for files I delete.

Edited March 23 by Samkook

[Luke 42533]

@Samkookplease try redoing the trakt pin again and see if that helps. Thanks !

[Samkook 19]

You clearly either didn't understand or read what I said.

 

The config went away on its own once, but now it's fine.

 

I just lost all of my trakt info because of it though, that can't be fixed.

Edited June 1 by Samkook

[Samkook 19]

My guess is that when the plugin moved the config to the users, it wiped it with no warning instead of moving it.

[Luke 42533]

1 hour ago, Samkook said:

My guess is that when the plugin moved the config to the users, it wiped it with no warning instead of moving it.

OK I'm sorry, you are right that I didn't understand your issue. There was a migration that would migrate the settings to the first admin user on your server.

Eventually, probably about six months after the 4.8 server release, this migration was removed as part of a simplification of the plugin code base.

[Samkook 19]

Sounds plausible that I could have missed that.

Not keeping migrations forever(they don't need modification so why would you not keep them and just check the version db to know if they apply or not, eliminating all migration problems from different versions?). Sounds like a terrible idea and it explains why I've had so much trouble in the past when updating. Going from v3 to 4 was a giant nightmare that took me weeks to make work without losing my precious view data(and that problem was the reason I had to install the trakt plugin and kept it has backup).

Edited June 1 by Samkook

[Luke 42533]

Did you take a long time to move to 4.8 once it was released?

[Samkook 19]

Like I said, it's plausible, but it's not like I know when each update get released and when I actually update. The freebsd official package had been held back for a while too at some point so that might had something to do with it.

But for a multitude of reasons, people might held back updating for an undetermined period of time so not supporting migrations forever is just bad.

Edited Tuesday at 05:01 AM by Samkook

[Samkook 19]

For the people disagreeing with my previous post, not supporting migration forever means there's little value put on peoples data since that's a guaranteed loss of it and data is the most important thing for users.

The cost for the devs is also very small since the migration is basically frozen in time, it only applies to a specific set of data that will never again change since each migration missed should be applied sequentially so it won't ever need maintenance.