Jump to content

Trakt all of a sudden unauthorized


shred00

Recommended Posts

shred00

I've started getting these all of a sudden after many weeks of successful Trakt scrobbling.

2018-03-14 01:55:27.548 Info HttpClient: HttpClientManager POST: https://api.trakt.tv/oauth/token
2018-03-14 01:55:27.786 Error HttpClient: Error ProtocolError getting response from https://api.trakt.tv/oauth/token
        *** Error Report ***
        Version: 3.3.1.0
        Command line: /usr/lib/emby-server/bin/MediaBrowser.Server.Mono.exe -programdata /var/lib/emby-server -restartpath /usr/lib/emby-server/restart.sh
        Operating system: Unix 3.13.0.135
        64-Bit OS: False
        64-Bit Process: False
        User Interactive: False
        Mono: 4.8.1 (Stable 4.8.1.0/22a39d7 Tue May  2 22:30:49 UTC 2017)
        Processor count: 2
        Program data path: /var/lib/emby-server
        Application directory: /usr/lib/emby-server/bin
        System.Net.WebException: The remote server returned an error: (401) Unauthorized.
          at System.Net.HttpWebRequest.EndGetResponse (System.IAsyncResult asyncResult) [0x00064] in <5641e4edad4f4464ba58c620a7b8ea48>:0 
          at System.Threading.Tasks.TaskFactory`1[TResult].FromAsyncCoreLogic (System.IAsyncResult iar, System.Func`2[T,TResult] endFunction, System.Action`1[T] endAction, System.Threading.Tasks.Task`1[TResult] promise, System.Boolean requiresSynchronization) [0x00014] in <dbb16e0bacdc4a0f87478e401bc29b6c>:0 
        System.Net.WebException
          at System.Net.HttpWebRequest.EndGetResponse (System.IAsyncResult asyncResult) [0x00064] in <5641e4edad4f4464ba58c620a7b8ea48>:0 
          at System.Threading.Tasks.TaskFactory`1[TResult].FromAsyncCoreLogic (System.IAsyncResult iar, System.Func`2[T,TResult] endFunction, System.Action`1[T] endAction, System.Threading.Tasks.Task`1[TResult] promise, System.Boolean requiresSynchronization) [0x00014] in <dbb16e0bacdc4a0f87478e401bc29b6c>:0 

To be absolutely sure, I have not done anything with Trakt configuration or anything else that should cause Trakt to all of a sudden be 401.

 

The only abnormalities that I can see prior to the start of the 401s on this past Friday are a couple of these:

2018-03-09 19:46:12.372 Info HttpClient: HttpClientManager POST: https://api.trakt.tv/scrobble/stop
2018-03-09 19:46:12.444 Error HttpClient: Error ProtocolError getting response from https://api.trakt.tv/scrobble/stop
        *** Error Report ***
        Version: 3.3.0.0
        Command line: /usr/lib/emby-server/bin/MediaBrowser.Server.Mono.exe -programdata /var/lib/emby-server -restartpath /usr/lib/emby-server/restart.sh
        Operating system: Unix 3.13.0.135
        64-Bit OS: False
        64-Bit Process: False
        User Interactive: False
        Mono: 4.8.1 (Stable 4.8.1.0/22a39d7 Tue May  2 22:30:49 UTC 2017)
        Processor count: 2
        Program data path: /var/lib/emby-server
        Application directory: /usr/lib/emby-server/bin
        System.Net.WebException: The remote server returned an error: (409) Conflict.
          at System.Net.HttpWebRequest.EndGetResponse (System.IAsyncResult asyncResult) [0x00064] in <5641e4edad4f4464ba58c620a7b8ea48>:0 
          at System.Threading.Tasks.TaskFactory`1[TResult].FromAsyncCoreLogic (System.IAsyncResult iar, System.Func`2[T,TResult] endFunction, System.Action`1[T] endAction, System.Threading.Tasks.Task`1[TResult] promise, System.Boolean requiresSynchronization) [0x00014] in <dbb16e0bacdc4a0f87478e401bc29b6c>:0 
        System.Net.WebException
          at System.Net.HttpWebRequest.EndGetResponse (System.IAsyncResult asyncResult) [0x00064] in <5641e4edad4f4464ba58c620a7b8ea48>:0 
          at System.Threading.Tasks.TaskFactory`1[TResult].FromAsyncCoreLogic (System.IAsyncResult iar, System.Func`2[T,TResult] endFunction, System.Action`1[T] endAction, System.Threading.Tasks.Task`1[TResult] promise, System.Boolean requiresSynchronization) [0x00014] in <dbb16e0bacdc4a0f87478e401bc29b6c>:0 
Link to comment
Share on other sites

shred00

Looks like there was also a:

2018-03-09 19:00:38.489 Error HttpClient: Error ProtocolError getting response from https://api.trakt.tv/sync/history
        *** Error Report ***
        Version: 3.3.0.0
        Command line: /usr/lib/emby-server/bin/MediaBrowser.Server.Mono.exe -programdata /var/lib/emby-server -restartpath /usr/lib/emby-server/restart.sh
        Operating system: Unix 3.13.0.135
        64-Bit OS: False
        64-Bit Process: False
        User Interactive: False
        Mono: 4.8.1 (Stable 4.8.1.0/22a39d7 Tue May  2 22:30:49 UTC 2017)
        Processor count: 2
        Program data path: /var/lib/emby-server
        Application directory: /usr/lib/emby-server/bin
        System.Net.WebException: The remote server returned an error: (502) Bad Gateway.
          at System.Net.HttpWebRequest.EndGetResponse (System.IAsyncResult asyncResult) [0x00064] in <5641e4edad4f4464ba58c620a7b8ea48>:0 
          at System.Threading.Tasks.TaskFactory`1[TResult].FromAsyncCoreLogic (System.IAsyncResult iar, System.Func`2[T,TResult] endFunction, System.Action`1[T] endAction, System.
        System.Net.WebException
          at System.Net.HttpWebRequest.EndGetResponse (System.IAsyncResult asyncResult) [0x00064] in <5641e4edad4f4464ba58c620a7b8ea48>:0 
          at System.Threading.Tasks.TaskFactory`1[TResult].FromAsyncCoreLogic (System.IAsyncResult iar, System.Func`2[T,TResult] endFunction, System.Action`1[T] endAction, System.

Link to comment
Share on other sites

mastrmind11

Is this ongoing? I have not had any issues since the "fix" (wherever it occured) happened.

Link to comment
Share on other sites

shred00

Not sure what you mean by "ongoing".  Emby being unauthorized to my Trakt account is the present state.  I am quite sure I could rectify that by re-authorizing and getting a new PIN but I'm just as interested in preventing this from happening again so I have left it as is in case there is any more information or debugging to be done in this broken state.

 

It's only coincidence that I noticed it so quickly after happening.  I could see this being ongoing for months before noticing since I don't regularly visit the Trakt portal.  So I'd really like to prevent that.

Link to comment
Share on other sites

mastrmind11

Not sure what you mean by "ongoing".  Emby being unauthorized to my Trakt account is the present state.  I am quite sure I could rectify that by re-authorizing and getting a new PIN but I'm just as interested in preventing this from happening again so I have left it as is in case there is any more information or debugging to be done in this broken state.

 

It's only coincidence that I noticed it so quickly after happening.  I could see this being ongoing for months before noticing since I don't regularly visit the Trakt portal.  So I'd really like to prevent that.

yeah, thats why I asked, the last time this happened the only reason I noticed is because of a post in the plugins forum about it being broken.  If it can be reproduced, then my follow up is how long has it been working prior this in case it's something the rest of us need to watch out for it.  thanks

Link to comment
Share on other sites

shred00

Oh, by "ongoing" do you mean the situation of getting errors reported back from the Trakt website?

 

That I don't know (but I highly doubt) since my Emby server is not even getting past authorisation any more.  Did the situation where Trakt was reporting errors on their end somehow wipe or corrupt the authorisation credential that Emby has?  Put another way, just because Trakt had some kind of temporary service interruption, if it's subsequently been fixed, why should Emby still be reporting 401s trying to authenticate?  Did Emby wipe or reset the credential in some way when it was receiving the errors from Trakt?

 

Ultimately, Emby cannot need to be reauthenticated just because the Trakt services have a hiccup.  Particularly so when these authentication errors happen so silently (i.e. buried in a log an nowhere else).

Link to comment
Share on other sites

I would try it again tomorrow just in case there was some kind of network blip on the trakt side. If not then we'll go from there. Thanks.

Link to comment
Share on other sites

shred00

There seems to be a misunderstanding.  The "blip" happened last Friday not yesterday.  Every day/every time since then that Emby has tried to scrobble or otherwise authenticate to Trakt, including up to now (6 days later) I have been getting 401 errors.  Those 401 errors are not going to go away until I re-authenticate my Emby server to my Trakt account.

 

So the issue here is that Emby somehow lost the authentication token it had for Trakt when it got errors from the "blip".  That shouldn't happen.  I shouldn't need to re-authenticate Emby every time there is a "blip" at Trakt.  I didn't have to re-authenticate the long-standing web session I have had open to Trakt when they had their "blip".

Edited by shred00
Link to comment
Share on other sites

pünktchen

Maybe your Emby account is blocked because of your 600 library items that get refreshed every day?!

Link to comment
Share on other sites

shred00

Maybe your Emby account is blocked because of your 600 library items that get refreshed every day?!

 

This is definitely not the case.  Emby and Trakt have been working for months until this "blip" at Trakt and it's only after that "blip" that Emby seems to have forgotten the Trakt authorisation token.

 

There is a direct correlation between the blip and the authentication failures.  There is no correlation whatsoever between Emby thinking everything in my library has been updated every 24-48 hours and any issues with the Trakt plugin.

Edited by shred00
Link to comment
Share on other sites

paulsalter

What does it show in the Trakt.xml file

 

C;\Users\NAME\AppData\Roaming\Emby-Server\plugins\configurations

 

As far as i can see, my renews the authorisation once per month and updates in here

Just wondering if a blip on Trakt when it tried to do this, so before it tries it again (the next month), the token has expired

Link to comment
Share on other sites

shred00

Ahh.  Interesting.  Very useful information about the Trakt.xml file.

 

I seem to have 4 entries in mine.  They all look like the same general configuration but with different LinkedMbUserId values.  Each has a similar expiration except one:

      <AccessTokenExpiration>2018-03-09T15:57:02.599855-05:00</AccessTokenExpiration>
      <AccessTokenExpiration>0001-01-01T00:00:00Z</AccessTokenExpiration>
      <AccessTokenExpiration>2018-03-09T20:39:24.884Z</AccessTokenExpiration>
      <AccessTokenExpiration>2018-03-09T20:53:33.792835Z</AccessTokenExpiration>

But three do have an expiration date on the date the "blip" happened.

 

Perhaps the algorithm/process for renewing needs to be hardened so that it doesn't wait for the very last minute to renew when it might be unable to.

 

Perhaps at 75% of the way to the renewal date (3 weeks if it is monthly as you suggest), it should start trying to renew and continue to retry at frequent intervals if it fails the first time.

 

This is how DHCP works, FWIW, except that it starts trying to renew at 50% of it's lease time, exactly for this sort of reason.  It gives the client plenty of time to try to get a renewal in the case of failures to do so initially.  It was a very good design decision.

Link to comment
Share on other sites

Yes maybe that is the issue, that it needs to be renewed before expiration otherwise the user has to redo all the authentication. Currently it is not an active plugin, in the sense that it doesn't do anything unless called upon by the core server.

Link to comment
Share on other sites

shred00

But surely there is code that gets run at some point to renew the authentication, even with it not being active or else everyone would have be manually renewing all the time.

 

That code just needs to start running when the expiry is a week or less away instead of waiting for the expiry to be (near) zero away.  As long as the logic is "less than 7 days" (instead of (near) 0) whenever the renewal codepath is run, it should have plenty of opportunity to run in that week and find the Trakt services up and complete a renewal.  At that point it will not be less than 7 days and will just keep skipping renewal until it is less than 7 days.

Link to comment
Share on other sites

No, it sounds like that will need to be added. It does have renewal but only when called upon, and by then it could be expired.

Link to comment
Share on other sites

The only time the plugin talks to trakt is in response to some kind of server event - e.g., user watches something, marks watched, etc. Or running a scheduled task manually. It's during these operations that it will also renew but if there's a gap in between your activity then it could be expired already by then.

Link to comment
Share on other sites

shred00

So people have to watch a "minimum" amount of content otherwise they could create a gap over which the credentials expire?

 

What's the minimum?  I.e. how long of a gap will cause the credentials to expire?  IOW, how far ahead of expiry are they being renewed, during one of these "server event" updates?

 

If credentials are only being renewed during other normal communications with the Trakt server, they have to be getting renewed some amount of time ahead of expiry otherwise they would end up always expiring.  So the plugin must be doing some kind of evaluation of how soon credentials are going to expire every time it communicates with the server so that it can renew them before they do expire as it does it's normal business, because as you say, the plugin is not "active" and so it must be "opportunistic".

 

So how soon ahead of expiry is the plugin doing this opportunistic renewing?

 

On the other hand, maybe this token renewal is just not working at all.

 

Looking through my backups, the token that expired last Friday was obtained on January 9, 2018.  That was exactly two months prior to the expiry date.  Before that, the Trakt.xml file didn't seem to have tokens but instead had Username and Password elements in the file.  Is this business of tokens new in this plugin, appearing some time between between Oct. 16, 2017 (when my Trakt.xml file had a Username and Password and January 9, 2018 when I started having a token?

 

So I actually have not seen a functioning token renewal and it seems more than coincidence that all of this went off the rails (and Trakt had a "blip" -- which was maybe no "blip" at all but just the process of the token becoming expired) at the same date/time that the token was set to expire.

Link to comment
Share on other sites

shred00

Well, I guess that is one way to solve it.

 

But given that opportunistic renewal must be the way it's working now, I'm not sure why the window to start trying to renew can't just be made bigger.  If it indeed is doing opportunistic renewal.

Link to comment
Share on other sites

paulsalter

Reading the last few comments, would the scheduled tasks avoid getting this error?

 

I have the sync with trakt set for every morning at 6am (this sends any missing scrobbles if trakt is down during watching)

also have the import from trakt set for every 3 hours, sets new items as watched if already seen them

Link to comment
Share on other sites

shred00

import from trakt set for every 3 hours, sets new items as watched if already seen them

 

Just as an aside, since you mentioned it, the goal of this sync is to update the watched status in Emby for things that were watched outside of Emby where however they were watched, their watched status was updated to Trakt?

 

I.e. If I watch an episode of the walking dead outside of Emby, as long as whatever I watched it on can tell Trakt that I watched it (or I tell Trakt I watched it through the Trakt web interface), Emby syncs this from Trakt so that Emby can reflect that I've watched it, yes?

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...