Jump to content


Photo

Trakt all of a sudden unauthorized

trakt

  • Please log in to reply
22 replies to this topic

#1 shred00 OFFLINE  

shred00

    Advanced Member

  • Members
  • 123 posts
  • Local time: 01:35 PM

Posted 14 March 2018 - 11:38 AM

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 


#2 shred00 OFFLINE  

shred00

    Advanced Member

  • Members
  • 123 posts
  • Local time: 01:35 PM

Posted 14 March 2018 - 11:48 AM

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.



#3 mastrmind11 ONLINE  

mastrmind11

    Advanced Member

  • Members
  • 2738 posts
  • Local time: 01:35 PM
  • LocationLong Island, NY

Posted 14 March 2018 - 01:08 PM

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



#4 shred00 OFFLINE  

shred00

    Advanced Member

  • Members
  • 123 posts
  • Local time: 01:35 PM

Posted 14 March 2018 - 01:11 PM

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.



#5 mastrmind11 ONLINE  

mastrmind11

    Advanced Member

  • Members
  • 2738 posts
  • Local time: 01:35 PM
  • LocationLong Island, NY

Posted 14 March 2018 - 01:18 PM

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



#6 shred00 OFFLINE  

shred00

    Advanced Member

  • Members
  • 123 posts
  • Local time: 01:35 PM

Posted 14 March 2018 - 01:23 PM

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).



#7 Luke OFFLINE  

Luke

    System Architect

  • Administrators
  • 135838 posts
  • Local time: 01:35 PM

Posted 14 March 2018 - 10:51 PM

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.



#8 shred00 OFFLINE  

shred00

    Advanced Member

  • Members
  • 123 posts
  • Local time: 01:35 PM

Posted 15 March 2018 - 08:16 AM

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, 15 March 2018 - 08:21 AM.


#9 pünktchen OFFLINE  

pünktchen

    Advanced Member

  • Members
  • 2143 posts
  • Local time: 07:35 PM

Posted 15 March 2018 - 08:32 AM

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

#10 shred00 OFFLINE  

shred00

    Advanced Member

  • Members
  • 123 posts
  • Local time: 01:35 PM

Posted 15 March 2018 - 09:15 AM

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, 15 March 2018 - 09:16 AM.


#11 paulsalter OFFLINE  

paulsalter

    Advanced Member

  • Members
  • 386 posts
  • Local time: 06:35 PM

Posted 15 March 2018 - 09:26 AM

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



#12 shred00 OFFLINE  

shred00

    Advanced Member

  • Members
  • 123 posts
  • Local time: 01:35 PM

Posted 15 March 2018 - 10:53 AM

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.



#13 Luke OFFLINE  

Luke

    System Architect

  • Administrators
  • 135838 posts
  • Local time: 01:35 PM

Posted 15 March 2018 - 12:54 PM

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.



#14 shred00 OFFLINE  

shred00

    Advanced Member

  • Members
  • 123 posts
  • Local time: 01:35 PM

Posted 15 March 2018 - 01:27 PM

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.



#15 Luke OFFLINE  

Luke

    System Architect

  • Administrators
  • 135838 posts
  • Local time: 01:35 PM

Posted 15 March 2018 - 03:51 PM

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.

#16 shred00 OFFLINE  

shred00

    Advanced Member

  • Members
  • 123 posts
  • Local time: 01:35 PM

Posted 15 March 2018 - 04:12 PM

Are you saying that the plugin doesn't renew until it is asked to by the server?



#17 Luke OFFLINE  

Luke

    System Architect

  • Administrators
  • 135838 posts
  • Local time: 01:35 PM

Posted 15 March 2018 - 04:33 PM

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.



#18 shred00 OFFLINE  

shred00

    Advanced Member

  • Members
  • 123 posts
  • Local time: 01:35 PM

Posted 15 March 2018 - 05:26 PM

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.



#19 Luke OFFLINE  

Luke

    System Architect

  • Administrators
  • 135838 posts
  • Local time: 01:35 PM

Posted 15 March 2018 - 09:02 PM

No I think the plugin will need a background task to handle it periodically.



#20 shred00 OFFLINE  

shred00

    Advanced Member

  • Members
  • 123 posts
  • Local time: 01:35 PM

Posted 16 March 2018 - 07:04 AM

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.







Also tagged with one or more of these keywords: trakt

0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users