jks

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

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

Okay, there seems to be a couple of issues going on here.

1) I got screwed over by dropbox. The v1.383 img.xz file has the correct filename, contents and SHA on my laptop dropbox directory. But even after a dropbox sync a fetch of that file from dropbox returns the contents of the previous v1.46 img.xz file (as pointed out by Yuri) for reasons I don't understand. I used the usual procedure to get a dropbox file URL to insert into various places (e.g. Kiwi website, kiwiSDR-download-KiwiSDR-create-micro-SD-flasher.sh script, etc.) But I didn't actually check it because it's never failed before. I think it's okay everywhere now with one exception: The file Beagle_SDR_GPS/tools/kiwiSDR-download-KiwiSDR-create-micro-SD-flasher.sh in the distro on your Kiwi will have to wait for an update to a v1.384 release to be corrected.

2) Jeff mentions he had to manually install a github commit (e90f87d) which is one commit (91cbe70) before the full v1.383 release. But that last commit has to do with the changes to the flasher script and I can't see how it would influence the normal running of the system in any way. But I also have one other complaint in email of an update to v1.383 failing (no details known yet). So more investigation is needed. [update: it was just filesystem corruption that prevented an update from v1.374 to v1.383, and after a manual rebuild it now works fine]. I always test the full release on a bunch of beta Kiwis of different configurations to try and reduce the chances of bricking the world.

The password changes are bit subtle. You have to read the explanation topic on the forum carefully to decide if the password has been changed to the Kiwi admin password (if you have configured one) or the serial number of the Kiwi (written in black marker pen in the white box on the Kiwi PCB, also in the "network" tab of the admin page if you can get there).