jks

Yep. Currently the ITU region setting only has effect for defining the NDB band bar and the 80/75m band overlap (which has problems of its own). It is not used for 160m (Fstart), 40/41m, 30m (Fstop) etc.

Is this Kiwi available from the Internet so I could connect (I don't need any passwords) and take a look?
"Being available" doesn't mean it has to be a publicly listed Kiwi. Only that port 8073 on your router is set to map to the Kiwi and that you can tell me your public ip address.

Oh yes, and based on recent experience I guess we now have to ask you: is your ISP Comcast?

Also, is there WiFi involved anywhere in the path between your Kiwi and the machine running the browser? Does the same thing happen on some other device like a tablet, cellphone etc?

I know this sounds like entry-level tech support, but seriously, try power cycling all your network equipment. I used to have a WiFi bridge connection between my development Kiwis and my laptop due to the physical setup here. About twice a year my Internet router or the TP-Link bridge would lose its mind and the ping times randomly go to several seconds for no apparent reason. Power cycle fixed it, but only after half my hair had already been pulled out trying to find out what was wrong with my code. Needless to say I found a way to run an Ethernet cable.

but it still doesn't show up on the map

Which map? rx.linkfanel.net (aka map.kiwisdr.com)? Or the map section of sdr.hu?
If your Kiwi is listed on kiwisdr.com/public (aka rx.kiwisdr.com) then it should appear on the rx.linkfanel.net map since the kiwisdr.com listing site is where linkfanel.net gets its data from currently.

As you point out sdr.hu is an entirely independent (and now optional) registration path. It is quite possible that there might be an intermittent connection issue with sdr.hu, yet people are still finding your Kiwi via {rx,map}.kiwisdr.com rather than saved browser history.

What exact error message is sdr.hu returning in the log when the registration attempts from your Kiwi fail?

Update: I'll answer my own question. Your Kiwi is reporting this:

Wed Apr  1 01:57:01 00:49:07.685 ....      sdr.hu registration: DOWN

So that's a problem we've seen from sdr.hu before. And it's something Andras will have to fix since we have no control over his site.

At the moment I can't connect to http://71.197.249.8:8073
It just times out. If you hover over your purple icon on rx.linkfanel.net it says "Last online: 7 hours ago".

So I think you've got incoming connectivity problems. Now I was able to get in fine an hour ago to check your log messages. So it hasn't been completely down. On the admin "network" tab if you click the "check open port" button do you get a status of "YES" to either of those paths? That button makes a request to kiwisdr.com to check connectivity to your Kiwi (in the incoming direction) using both the DNS-based and IP-based paths.

Re: links on kiwisdr.com pages to forum for more info about password changes. You're absolutely right -- these links are totally broken. Were they ever set correctly in the first place? I don't know. It almost looks like I had set a placeholder link and then forgot to go back and edit the content. I'm always pretty good about checking links in hand-edited html because they are so easy to get wrong. Anyway, should be good now.

If you haven't already started making customizations to your Kiwi configuration and you want to try the regular install procedure then just do this: Re-flash to v1.2 using your sd card (with the Ethernet disconnected just for good measure). Then after the re-flash powers down remove the sd card, reconnect Ethernet and power up.

You should be able to ssh in using the root account and a blank password since the v1.2 image will be running for the hour it will take for v1.384 to be installed. Upgrading from v1.2 doesn't have a nice log file you can follow to see the process. But you could do a successive "ps ax" (or your favorite variant) and get a rough idea of what's going on. There will be an initial period of apt-get activity as many Debian packages are installed, the largest being the Clang compiler suite. Eventually clang will get invoked on the Kiwi sources and that will take the balance of the time. Things will be very slow during the compilation of the DRM sources as they are written using true, extensive C++ constructs which cause the compiler no end of heartburn (me too as I was trying to wade through that stuff, lol). At the very end a bunch of time is spent coalescing all the data files (.js, .html, .jpeg et al) into the in-memory image file which is done via a pearl script that generates these huge inline C data files. After that the usual "make install" behavior that moves all the binary files into place.

Then a reboot to (hopefully) v1.384 when the one-time password changes will be applied where the root password will be set to the Kiwi serial number since there was never a point in this whole sequence where a Kiwi admin password was set manually. Same for the "debian" user account password.

I have done this procedure a number of times now and it's always worked. So I'd be keen to understand any case where it doesn't.

Cheers,
John