Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Official 5.2 Beta Discussion Thread
The latest version implements the visibility API, and it tries to keep the client connected, with minimal traffic, while not visible. I'm not sure if sleeping counts as part of that or not. I'll have to look at that.

I'll look again at the web widget for the next release, but my initial investigation doesn't make it seem likely. The video guy is an actual HTML element. But there's not an HTML element that represents another, nested, browser window. That would mean it would have to be a separate window, and the ability to create and manage multiple, frameless secondary windows doesn't really seem to be a thing in the browser.
Dean Roddey
Explorans limites defectum
The Mozilla docs imply that going into 'standby' mode is reported by the visibility API. I'm not sure if that is the same as sleep mode on all mobile platforms. And of course the browser on that Kindle may not even implement the visibility API. Do you have any access to the browser console on that guy? If so, add &logmisc=1 to the URL and open a new tab and then come back to the WebRIVA tab, and see if you get a message in the console about having to go background and back to foreground mode. That will indicate if it implements that API or not.

And, if so, you could see if it gets triggered on a sleep. And, while testing that, see if the reconnect is a time related thing perhaps. I.e. force sleep, wait a few seconds, and then wake it up. Does it reconnect in that case, but not if left to sleep for a long time?

And there again, if you have access to the console, add &logwebsock=1 to the URL to get it to log what it sees going on with the web socket connection.

One thing I wonder about is that maybe some of these browsers just kill the web worker if it goes to sleep or stays in the background for a while. If so, then maybe I'll have to restart the web worker upon coming back visible though of course that requires that they implement the visbility API.
Dean Roddey
Explorans limites defectum
(09-27-2017, 08:43 AM)Dean Roddey Wrote: Do you have any access to the browser console on that guy?
You can do remote debugging using ADB per this article: https://docs.aws.amazon.com/silk/latest/...gging.html
When I do the test with switching to/from a new tab there are no background/foreground messages.
When I press the 'power' button I see the screen goes black but the device is obviously still on as the logs have:
Lost socket connection
Lost connection to server, Trying to reconnect..
Opened socket connection
Got login results msg when not in login results mode
Connected to server
Sending ping
and then go back to the top 'Lost socket connection' and watch this repeat over and over.
When I hit the power button again and Silk return I have the "Connecting to CQC message"
If I keep the browser 'alive' by tapping the screen periodically I see "Sending ping" repeat until I let the screen go blank and then the above sequence repeats.

It appears that the remote session keeps the Kindle active and it doesn't go into it's sleep mode.
Mark Stega
OK, the "Got login results msg when not in login results mode" msg indicates something got out of sync. I'll have to look at that. I guess that browser doesn't support the visibility API, so that means the WebRIVA client can't suppress drawing activity while in the background. That may cause it to lose connection if it gets behind the server and it just backs up msgs in the queue until it dies. That may also be why it gets out of sync, I'm not sure. It may run out of some resource.

If you set the &loggraphcmds=1 that will lost drawing commands, so you can see if it is still drawing while it's in the background tab. Change something via the IV or something like that, something that would require a widget on the currently displayed content to redraw.
Dean Roddey
Explorans limites defectum
I sent you a patch to try to see if it helps with the reconnect issue.
Dean Roddey
Explorans limites defectum
I think I've more or less banged the written docs into shape. I'll keep tweaking but it's way better than it was before in terms of providing a map of what needs to be done and multiple levels of detail as to how to do it. I still need to go back through the changes since the last official release and make sure those are represented as well, but that's fairly minor.

I need to redo some videos, and probably make some new ones as well, which I'm not looking forward to. But it has to be done.
Dean Roddey
Explorans limites defectum
I'm working on a new beta drop, which I guess will be the first release candidate for 5.2. Of course as soon as I get such a build and play around with it, I notice things that need fixing. In particular I hadn't updated the quick help links in the /Help section of the AI's browser to reflect the changes I've been making, but also a few other things. So I'm taking care of those first.
Dean Roddey
Explorans limites defectum
I've got a couple of the significantly affected tutorial videos re-done. Probably two or three more need it as well, I need to scan through them. Some of them may be just spot topic ones so not as hard to re-do.
Dean Roddey
Explorans limites defectum
OK, version 5.1.911 is posted.

1. It has a new &reconnspread=x parameter, where x is a value that represents the spread within which the random reconnection time offsets will be generated. I tested this and it definitely worked and they reconnected at fairly spread out times.

2. It has a new IntfViewer::InRIVAMode() command. It's a pure conditional, so only available under the If or If/Else buttons. If you are running in the WebRIVA client, it have a True result, so you can do things specifically for RIVA mode if you want to.

3. The WebServer adds a 'settle time' before it starts listening for connections, so that the various CQC servers will have time to get up and running before the WebRIVA clients can connect. This should help prevent too much from happening too quickly.
Dean Roddey
Explorans limites defectum
Well, it looks like the re-connection issues (when a number of clients are trying to connect after the server comes back up) has been basically handled. And I've pounded about as much documentation as I can stomach, though I'll continue till the end. I definitely want to get some more videos in place. So I'm going to start heading seriously towards a release probably some time next week. Let's get this stuff out there and start climbing the next mountain.
Dean Roddey
Explorans limites defectum


Possibly Related Threads…
Thread Author Replies Views Last Post
  6.x Beta Release Discussions Thread gReatAutomation 26 3,495 05-09-2022, 08:25 PM
Last Post: Shaky
  Official 5.5 Beta Release Thread Dean Roddey 46 14,172 09-23-2021, 03:32 PM
Last Post: jokermac
  Official 6.x Beta Release Thread Dean Roddey 2 1,034 04-16-2021, 05:55 AM
Last Post: Dean Roddey
  5.5 Beta Discussions Thread Dean Roddey 291 72,253 04-05-2021, 04:10 PM
Last Post: Dean Roddey
  6.X Discussions Thread gReatAutomation 1 852 04-01-2021, 03:23 PM
Last Post: Dean Roddey
  Official 5.4 Beta Discussion Thread Dean Roddey 441 167,793 06-15-2019, 02:33 AM
Last Post: Bugman
  Official 5.4 Beta Release Thread Dean Roddey 55 30,331 06-07-2019, 07:02 PM
Last Post: Dean Roddey
  Official 5.3 Beta Discussion Thread Dean Roddey 815 370,919 07-05-2018, 12:44 PM
Last Post: Dean Roddey
  Official 5.3 Release Thread Dean Roddey 27 19,738 07-05-2018, 12:44 PM
Last Post: Dean Roddey
  Official 5.2 Beta Release Thread Dean Roddey 13 14,158 10-09-2017, 06:49 PM
Last Post: Dean Roddey

Forum Jump:


Users browsing this thread: 1 Guest(s)