jks

This may be an expected condition. If at the time the Kiwi with multiple users had fewer "good" sats than you were expecting I would need to know if the "acq" status item at the lower left of the GPS page was saying "yes" or "paused". Also, is the "always acquire" switch set to "yes" on this Kiwi?

You're right that this has been discussed before, but I'll recap. There are two phases to begin processing a new sat: acquisition and then tracking once the sat is acquired. The acquisition process is very compute intensive on the Beagle. It requires a large FFT, the code of which is uninterruptible (running for many milliseconds). That has big consequences for the realtime requirements of the Kiwi. With many users connected running a large FFT, unless carefully scheduled, could cause the users to experience broken audio. Tracking is not a problem because that is done mostly in the FPGA with dedicated hardware for each GPS channel.

So there is some code to strategically decide when to do acquisitions.

The variables are:
Did the Kiwi just boot and has never had a solution? (hence no frequency calibration of the SDR part of the Kiwi)
How many users are currently connected? (external users, not internal e.g. WSPR-autorun connections)
Are there more than 4 "good" sats currently? (the minimum number required for new solutions, although this has now changed because the Kalman filter can give solutions using fewer good sats)
Is the "always acquire" switch set on the GPS admin page?

The strategy is:
1) If there have never been any solutions at all (Kiwi startup) then always acquire no matter how many connected users until there are enough solutions for the first few Kiwi oscillator corrections to occur. This is so that any large initial frequency offset due to room temperature can be removed.
2) If the "always acquire" switch is set to "yes" then always acquire no matter what.
3) If there are not too many external users (currently means fewer than two users) then always acquire.
4) If there are not enough sats to potentially generate new solutions (i.e. less than 5) then acquire.

So, what does all this mean? If you have two Kiwis connected to the same GPS antenna and one is full of users and the other is empty then the following can happen. They'll both begin acquiring sats, but the Kiwi with users will stop acquiring when the above conditions are met and just maintain roughly the minimum number of sats required for new solutions. If the users don't connect immediately then both Kiwis will load up to the same number of channels possible (e.g. all 12), but then the Kiwi with users will slowly drop down to the minimum described above as sats go out-of-range and are dropped. This is of course because the acquisition process is not running as frequently as on the Kiwi with no users.

Or what you're seeing could just be a bug I need to fix! lol

This may be an expected condition. If at the time the Kiwi with multiple users had fewer "good" sats than you were expecting I would need to know if the "acq" status item at the lower left of the GPS page was saying "yes" or "paused". Also, is the "always acquire" switch set to "yes" on this Kiwi?

You're right that this has been discussed before, but I'll recap. There are two phases to begin processing a new sat: acquisition and then tracking once the sat is acquired. The acquisition process is very compute intensive on the Beagle. It requires a large FFT, the code of which is uninterruptible (running for many milliseconds). That has big consequences for the realtime requirements of the Kiwi. With many users connected running a large FFT, unless carefully scheduled, could cause the users to experience broken audio. Tracking is not a problem because that is done mostly in the FPGA with dedicated hardware for each GPS channel.

So there is some code to strategically decide when to do acquisitions.

The variables are:
Did the Kiwi just boot and has never had a solution? (hence no frequency calibration of the SDR part of the Kiwi)
How many users are currently connected? (external users, not internal e.g. WSPR-autorun connections)
Are there more than 4 "good" sats currently? (the minimum number required for new solutions, although this has now changed because the Kalman filter can give solutions using fewer good sats)
Is the "always acquire" switch set on the GPS admin page?

The strategy is:
1) If there have never been any solutions at all (Kiwi startup) then always acquire no matter how many connected users until there are enough solutions for the first few Kiwi oscillator corrections to occur. This is so that any large initial frequency offset due to room temperature can be removed.
2) If the "always acquire" switch is set to "yes" then always acquire no matter what.
3) If there are not too many external users (currently means fewer than two users) then always acquire.
4) If there are not enough sats to potentially generate new solutions (i.e. less than 5) then acquire.

So, what does all this mean? If you have two Kiwis connected to the same GPS antenna and one is full of users and the other is empty then the following can happen. They'll both begin acquiring sats, but the Kiwi with users will stop acquiring when the above conditions are met and just maintain roughly the minimum number of sats required for new solutions. If the users don't connect immediately then both Kiwis will load up to the same number of channels possible (e.g. all 12), but then the Kiwi with users will slowly drop down to the minimum described above as sats go out-of-range and are dropped. This is of course because the acquisition process is not running as frequently as on the Kiwi with no users.

Or what you're seeing could just be a bug I need to fix! lol

Since Christoph's new Kalman filter eliminates GPS outlier solutions the accumulated values from a long running shadow map will be a lot clearer. The az/el shadow map below from the gps tab on the admin page is after about 30 hours of running. You can clearly see that I live in a tall apartment building with a west facing view as everything from 0 to 180 degrees is blocked by the shadow of the building (the antenna is on the metal handrail [ground plane of sorts] of the balcony). The "polar hole" is to the south since I'm in the southern hemisphere and I have mountains to the west.

Tremendously cool.

Looks like:
1) I need to learn GNURadio.
2) I need to finally fix the CIC compensation problem (without destroying WSPR decoding this time, lol).

Well, as Stu points out, something is wrong that causes sdr.hu to see registrations packets coming from a public ip address that does not resolve to the same ip as the domain you're attempting to register with. They should match. It doesn't matter if that's a "household" public ip address or one on the end of a tunnel or proxy.

v1.258 is out with TDoA UI and reliability improvements:

v1.257, 258  January 9, 2019
    TDoA UI improvements:
        Added "4" button to zoom buttons at upper left. Zooms directly to level 4.
        Shift-clicking on the +/- buttons zooms by 3 levels instead of just one.
        Added distance scale (in km/m & miles/feet) to map at lower right.
        Added ruler function. Click on the "protractor" icon at lower right. Mouse cursor will
            change to cross symbol. Click on starting map position. Move mouse to ending map
            position and double-click to end ruler measurement. Or single-click to make
            intermediate measurement and continue. Click on icon to clear measurement.
            Don't use escape key as that will close the extension! (this may be fixed in the future)
    
    Admin GPS tab: now says "loading maps..." when display delayed due to map download process.

    By request: URL parameter "no_geo" to disable browser from determining and sending Kiwi the
        geolocation information of the connecting user.
        Use like other URL parameters, e.g. "mykiwi:8073/?f=5Mam&mute&no_geo"
        This will someday become one of the "user preferences" options.

Quite right. I thought I had checked the Javascript files for the update. But the usual problem: one has a stray comma that still works in desktop browsers but fails on mobile browsers. Will be fixed in today's update.

Not sure what's wrong there. One of my browsers shows the pdf in that thread fine and the other doesn't. Here it is again:

Christoph has identified the issues necessary to make 20 kHz Kiwis work with TDoA (in principle at least). One issue was implemented in v1.252/253. Others to follow as time permits.

http://forum.kiwisdr.com/discussion/comment/3621