Yeah, this forum software sucks. Unfortunately it's part of Valent's website and I don't have complete control over it. I've though about migrating the Kiwi portion of it to different software hosted on kiwisdr.com. But I really don't need another big project right now (I've never done a database move). So I guess we just continue to muddle on.
Anyway, I'm splitting this discussion out of the SSTV thread. Here is the original post:
When my Kiwi came back up after updating to 1.285, it eventually fobbed off a my local user connection on the basis of having exceeding the inactivity timer.
I'm wondering if I tried to engage it just a little too soon after completing the update, as just before that local user connection was honored, it fobbed off a local admin connection request on the basis it was still doing an update... now some nine hours later, both of the two local user connections I set up before going out for the day are still running. Otherwise, why would it have applied the inactivity timer to a local connection?
Of course, once 1.285 was expected, nothing has been tripped up by the FF "fix"... so it could simply have been having one last go at giving me some grief whilst it still could.
73, VR2BG.
And my reply:
An admin page connection should never be denied just because an update is running. It might take a long time to connect, but it should always work. Any user connections will get the "update in progress" error page. Even user connections from the local network.
Running the audio/WF just kills the speed of the update. And having an update running in the background with active user connections would seriously impact the realtime performance of the system (e.g. you'd get audio underruns etc.)
I don't know what the problem is with a local connection not being exempt from the inactivity time. It should have been. I'd have to see the log messages.
Has now been a while & it hasn't happened again. I'm fairly sure that the log snippet I posted previously covered when it had happened.
Somewhat similar, with all the updates to do with GPS as of late, several times when I thought the Kiwi had finished updating, the Kiwi would spit the dummy saying the browsers it had previously been happy with before starting the update had out-of-date JS on them after the update had finished (Chrome 49.something [supposedly last XP version], as well as Chromium on an RPi).
I'm beginning to wonder if perhaps I'm managing to try to do things just a little to quickly after an update finishes.
I had a habit of trying to access the Kiwi before it had completed a software update, doesn't help, slows things down. Consider setting the Kiwi syslog to send messages to an external syslog server, I do that by default and it reduces the temptation. I don't go back to the Kiwi until I can see the normal startup sequence complete on the external syslog server.
Comments
Anyway, I'm splitting this discussion out of the SSTV thread. Here is the original post:
I'm wondering if I tried to engage it just a little too soon after completing the update, as just before that local user connection was honored, it fobbed off a local admin connection request on the basis it was still doing an update... now some nine hours later, both of the two local user connections I set up before going out for the day are still running. Otherwise, why would it have applied the inactivity timer to a local connection?
Of course, once 1.285 was expected, nothing has been tripped up by the FF "fix"... so it could simply have been having one last go at giving me some grief whilst it still could.
73, VR2BG.
Running the audio/WF just kills the speed of the update. And having an update running in the background with active user connections would seriously impact the realtime performance of the system (e.g. you'd get audio underruns etc.)
I don't know what the problem is with a local connection not being exempt from the inactivity time. It should have been. I'd have to see the log messages.
Somewhat similar, with all the updates to do with GPS as of late, several times when I thought the Kiwi had finished updating, the Kiwi would spit the dummy saying the browsers it had previously been happy with before starting the update had out-of-date JS on them after the update had finished (Chrome 49.something [supposedly last XP version], as well as Chromium on an RPi).
I'm beginning to wonder if perhaps I'm managing to try to do things just a little to quickly after an update finishes.
Forum: Understood.
73, Brett/KH6/p.
Consider setting the Kiwi syslog to send messages to an external syslog server, I do that by default and it reduces the temptation.
I don't go back to the Kiwi until I can see the normal startup sequence complete on the external syslog server.