All--It seems running Docker on the NAS eliminates the timeout issue. I suspect a Virus/Firewall update slowed down the Docker connection between the PC/NAS. I eliminated Docker on the PC and added it to the Qnap NAS where I run Channels. I will continue to monitor but think this solved the issue.
The failure is less frequent but still occurring randomly. I am monitoring the Docker log but all points to a timing issue.
latest code / docker container now caches the last good return from: https://i.mjh.nz/frndly_tv/app.json
And also there is now a keep-alive thread that will call a url every 5 minutes and force a re-login if required which should mean when a channel is now requested, its always already logged in and not timeout
5 Likes
Matt,
Loaded new docker.
Keep alive!
logging in....
Logged in!
127.0.0.1 - - [02/Jun/2022 12:56:37] "GET /keep_alive HTTP/1.1" 200 -
10.0.3.1 - - [02/Jun/2022 12:56:55] "GET / HTTP/1.1" 200 -
Seeing Keep Alive every 5 minutes. So far, no errors. Will monitor off/on today.
TNX!
AwesomeâŚ
on a semi related note. On the default frndlytv-for-channels page [host:8183] that displays the Playlist URL and the EPG URL is there a way to have it show a version number or at least the date of the container image. Maybe it is just my inexperience with Docker but I am never sure if I actually updated correctly.
Look under images. You should see time/date there.
Excellent. Thank you, sir!
I have got to say I am finding it to be significantly more responsive between channel changes. Maybe that is my imagination. But I donât remember being able to switch between channels this fast before. Bravo. Obviously havenât had a chance to test start up after being off the Frndly source for an extended period of time, but I suspect it will continue to be just a rapid.
1 Like
Any way to make this optional? I'm slightly concerned about Frndly not being... friendly about this
1 Like
I wouldnât know why they would care. I have left the WX Channel running for days.
1 Like
Ran all day. Perfect. No issues. Does seem faster.
Tnx again.
i could see a potential for the issue still be present
if you requested a channel within the 5 minute window of the token expiring and keep-alive working.
My solution for this is going to be:
-
Work out how long a token lasts for roughly
-
Change keep-alive to always login at an interval slightly less than the above
-
the other endpoints never re-login. It is only done by the keep-alive as that knows the interval and last renew
Currently, every 5 mins it just requests an endpoint that needs a valid token and will generate a new token if that fails.
Maybe someone already can figure out #1 for me based off the logs and the time between logging ins in the keep-alive
1 Like
I turned off the WX Channel on Frndly at 11:03:19
It re authenticated at 12:58:29 :
10.0.3.1 - - [03/Jun/2022 12:58:15] "GET / HTTP/1.1" 200 -
Keep alive!
401
Unauthorized access
logging in....
Logged in!
127.0.0.1 - - [03/Jun/2022 12:58:29] "GET /keep_alive HTTP/1.1" 200 -
10.0.3.1 - - [03/Jun/2022 12:58:43] "GET / HTTP/1.1" 200 -
Almost 2 hours.
Not sure this helps....but no issues with the present Docker after a full 24 hours.
TNX!
I have logged two times it re authenticated today:
12:55 and 18:55 UTC. No issues with Frndly today.
I am guessing it logs out every 6 hours. Will check again at 8:55 EDT tonight.
Sounds like the new docker is working.
I'm not seeing issues here.
I concur with @Jim_FL. Every six hours 1 min. I see log ins at 13:46, 7:45, 1:44, and yesterday 19:43, 13:42, 7:42.
1 Like
I have ended up confusing myself. So a question. Would a keep alive just short of 6 hours mean that a token could expire just after the keep alive, meaning for almost six hours new viewing/recording would still require refreshing the token on demand (like the old setup)? But a keep alive at 361 minutes (6hrs 1min) would mean just a one minute gap? Oh.. my brain hurts.
The keep alive can't be done before expire because the token still expires after 361 minutes. Your implementation currently doesn't actually keep it alive, it checks to see if it is still alive and refresh if it is expired. Which is awesome. So what you are trying to do is get the token refreshed as quickly as you can after it expires.
I decided to try doing this rather than my afternoon Sudoku. I kind of did a chart based on a 6hr 1min Token Life. Maybe this will give a better idea of where to put the keep alive based on our limited data set showing an approximately 361 minute token.
Keep Alive Times and max gaps between expire and refresh. Buffer times (hb) add an additional minute to allow for slight differences between times at Frndly and on the frndlytv-for-channels server.
Standard & Buffer Times -- (Keep Alive Hits Daily)
5* - Gap at expire: 4min (288)
30 - Gap at expire: 29min (48)
31 - Gap at expire: 11min (46)
1hr - 60 - Gap at expire: 59min (24)
1hb - 61 - Gap at expire: 5min (24)
2hr - 120 - Gap at expire: 119min (12)
2hb - 121 - Gap at expire: 2min (12)
3hr - 180 - Gap at expire: 179min (8)
3hb - 181 - Gap at expire: 1min (8)
4hr - 240 - Gap at expire: 119min (6)
4hb - 241 - Gap at expire: 121min (6)
5hr - 300 - Gap at expire: 239min (5)
5hb - 301 - Gap at expire: 241min (5)
6hr - 360 - Gap at expire: 360min (4)
6hb - 362 - Gap at expire: 1min (4)
I was just going to have the keep alive relogging in after 5 hours. So our token is maximum 5 hours old at all times. I wouldn't even check if it's still valid. Login. Wait for 5 hours. Login again.
I can verify the token refreshed at 6 hours 3 times today. My question is, why change what is working? The current run assures the token is valid frequently. It would also restore the token if you had to reboot your NAS for maintenance. Maybe I am not understanding the need to change.
Thanks for your efforts and everyone's feedback.
@matthuisman Ok I see where I got confused. What we are seeing in the logs are just checks every five minutes until it see it is expired and then does some kind of refresh. Which you did say but it didn't click in my head. That's my bad. I didn't think you could do a refresh before the token expired. Now I understand. Well, it was a fun math project anyway.
@Jim_FL He wants to eliminate all expired time. Relogging in every 5 hours would mean 24/7 no expire. Right now there are about up to 4 minutes every 6 hours that the token is expired. That would be eliminated. The current 5 minute thing was basically just a way to find out how long the tokens last. As far as reboots, I imagine right now as it is the container already gets a fresh token whenever it starts.