shred00 13 Posted March 14, 2018 Share Posted March 14, 2018 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 More sharing options...
shred00 13 Posted March 14, 2018 Author Share Posted March 14, 2018 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 More sharing options...
mastrmind11 717 Posted March 14, 2018 Share Posted March 14, 2018 Is this ongoing? I have not had any issues since the "fix" (wherever it occured) happened. Link to comment Share on other sites More sharing options...
shred00 13 Posted March 14, 2018 Author Share Posted March 14, 2018 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 More sharing options...
mastrmind11 717 Posted March 14, 2018 Share Posted March 14, 2018 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 More sharing options...
shred00 13 Posted March 14, 2018 Author Share Posted March 14, 2018 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 More sharing options...
Luke 37067 Posted March 15, 2018 Share Posted March 15, 2018 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 More sharing options...
shred00 13 Posted March 15, 2018 Author Share Posted March 15, 2018 (edited) 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 March 15, 2018 by shred00 Link to comment Share on other sites More sharing options...
pünktchen 1258 Posted March 15, 2018 Share Posted March 15, 2018 Maybe your Emby account is blocked because of your 600 library items that get refreshed every day?! Link to comment Share on other sites More sharing options...
shred00 13 Posted March 15, 2018 Author Share Posted March 15, 2018 (edited) 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 March 15, 2018 by shred00 Link to comment Share on other sites More sharing options...
paulsalter 84 Posted March 15, 2018 Share Posted March 15, 2018 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 More sharing options...
shred00 13 Posted March 15, 2018 Author Share Posted March 15, 2018 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 More sharing options...
Luke 37067 Posted March 15, 2018 Share Posted March 15, 2018 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 More sharing options...
shred00 13 Posted March 15, 2018 Author Share Posted March 15, 2018 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 More sharing options...
Luke 37067 Posted March 15, 2018 Share Posted March 15, 2018 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 More sharing options...
shred00 13 Posted March 15, 2018 Author Share Posted March 15, 2018 Are you saying that the plugin doesn't renew until it is asked to by the server? Link to comment Share on other sites More sharing options...
Luke 37067 Posted March 15, 2018 Share Posted March 15, 2018 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 More sharing options...
shred00 13 Posted March 15, 2018 Author Share Posted March 15, 2018 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 More sharing options...
Luke 37067 Posted March 16, 2018 Share Posted March 16, 2018 No I think the plugin will need a background task to handle it periodically. Link to comment Share on other sites More sharing options...
shred00 13 Posted March 16, 2018 Author Share Posted March 16, 2018 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 More sharing options...
paulsalter 84 Posted March 16, 2018 Share Posted March 16, 2018 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 More sharing options...
shred00 13 Posted March 16, 2018 Author Share Posted March 16, 2018 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 More sharing options...
Luke 37067 Posted March 16, 2018 Share Posted March 16, 2018 That's what the sync scheduled tasks are for, yes. Link to comment Share on other sites More sharing options...
Recommended Posts
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 accountSign in
Already have an account? Sign in here.
Sign In Now