Google Maps disabled on aprs.fi temporarily due to a TOS accident

I woke up today to find out that Google Maps are disabled on aprs.fi, and the site is slightly crippled.

Google had noticed that aprs.fi has integrated support for OpenStreetMap map tiles *and* Street View. I hadn't noticed that the combination of Street View on top of anything else than Google Maps is forbidden according to the Maps API Terms Of Service document. Or I had just forgotten about it when implementing OSM or Street View (there was probably a year or two of time between the two, and probably another year or two since I actually read the lengthy TOS).

Google had nicely sent me a few emails to warn about the unapproved combination, first one already on 5th of March. I had moved away from reading emails regularly in Gmail a long while back, but forgotten to arrange for these emails from Google APIs to go to my primary email address. Silly me. Since I didn't respond or do anything about the situation, for almost a full month, they disabled Maps API, which certainly got my attention.

Oh well. OSM support is disabled for now, and I notified Google that aprs.fi is again compliant with the terms. Should be back soonish.

I might put OSM support back later, and remove Street View instead, as OSM is probably more useful in practice at some areas (although admittedly less visual and "cool"). Or maybe make some sort of arrangement where Street View only works if you have Google Maps selected instead of OSM. Have to check with the Google folks if that's OK, there are a few variations we can try. The first thing is to get the main functionality back up, no matter which maps they are.

I'll post updates on Twitter (https://twitter.com/aprsfi) and Facebook (https://www.facebook.com/aprs.fi). Stay tuned.

My mistake entirely, although quite a human one. When did you last read the full text of the license agreement of your new application or mobile phone? :)

Embedded maps disabled temporarily

While investigating the problem with the Google Maps API I've disabled the embedded maps feature temporarily. Sorry for the trouble.

It now returns a blank page, so you'll see empty space where the map should be rendered. No errors should be shown to your web site visitors.

The map fails to load for some site visitors, giving an error about Google Maps API being disabled for the site. The error message does not seem accurate, since aprs.fi is nowhere near its usage limits, and an immediate reload of the page typically loads just fine. The error is sporadic, happens to some users all around the world, but not everyone (I haven't seen it), on all browsers (IE, Firefox, iPad, etc). The issue is being discussed on the aprs.fi discussion group.

Some aprs.fi email lost during the past weeks

Oops! For a couple weeks about 50% of the emails sent by aprs.fi have been going to the bit bucket due to a broken configuration on one of the servers. These included sign-up email confirmation and password recovery emails. Sorry about that!

The configuration is now fixed, and I've manually triggered a retransmit of the signup emails for the users who've signed up during the time but haven't yet clicked on the confirmation link.

Real-time telemetry and graph value lookup

I just finished installing an upgrade on aprs.fi. I had forgotten a configuration change that needed to be done with this upgrade, and the web service stopped working at 19:16 UTC. I had some trouble finding the problem, and managed to fix it at 19:38 UTC. That was completely unnecessary, sorry for the trouble. It should have been a routine upgrade requiring only a minute of downtime or so. Data collection was not interrupted.

The upgrade made the telemetry graph page update itself automatically as new values come in from the station, just like the weather page does. Just look up a telemetry station and leave the graph page open and the contents will be magically updated!

The grapher engine got a little upgrade which enables graph value lookups on all graphs. Just hover the mouse cursor above a graph and the labels will display the values reported at that time. While the pointer is between reported values it will display an interpolated value.

The real-time map's data refreshing algorithm got some updates and fixes.

I did a few updates on strings too, and the translations need to be updated. At least on the moving stations page I had to split a very long string to two short ones.

aprs.fi upgrade on Monday 2012-03-19

aprs.fi will be upgraded on Monday 2012-03-19. Some downtime should be expected, starting around 9 AM local time (0700 UTC). If you can find some bugs in beta.aprs.fi, this is the time to report and get them fixed before they make their way to aprs.fi! Here's the long list of changes included in the upgrade. It's so long that, as usual, some new bugs will probably pop up. Please report them on the discussion group and I'll try to get them fixed right away.

Anchor navigation and more AJAX

Achilles (left) and Ajax (right) play a board game with
knucklebones on this late 6th-century lekythos, a type of
oil-storing vessel associated with funeral rites. Photo taken
in Musée du Louvre by Marie-Lan Nguyen, 2011
(CC by attribution, Wikipedia/Wikimedia).

The technical implementation of the navigation in the real-time map has been completely changed. In the new model the map page is not reloaded from the servers and initialized again from scratch every time an user changes the view by searching for a new callsign or an address. This AJAX magic will make callsign searches and other view modifications considerably faster, especially on slow computers and slow connections such as mobile devices. It'll also reduce load on my and Google's servers. And make the browser's bookmark functions and the back button work better than before.

All of the links used by aprs.fi to refer to specific map views have changed, but the traditional ones documented on the linking instructions page will keep working, and I encourage you to use them as before - they're not going anywhere.

Try searching for OH2K and OH2TI one by one again and again, and you'll notice both the improved loading speed, and a nice panning effect. It'll pan whenever the newly searched station is close enough to the current view.

Improved address search

Address search has been improved to make a better use of the data returned by Google's API. A marker for the result is now only shown if the result is accurate (such as a street, or a house number on a specific street).

Address search will also adjust the zoom level - "Finland" or "Pohjois-Karjala" or "USA" should actually fit the specified region in view. The zoom levels come from Google and I can not make it any smarter than that (yes, "USA" will zoom out a bit too much). But it's certainly better than it was (fixed zoom level after address search).

Improved response times

When you make changes to the real-time map view, for example by zooming out or selecting a time range, aprs.fi will now react much more quickly.

New time range back/forward buttons

When a station is tracked, there are now two new handy additional arrow buttons to jump the time range back and forward. If you have selected an arbitrary range, it will jump the same amount back (select a week, and it'll jump to the previous week). Otherwise it'll select the current whole day (UTC 00:00:00 to 23:59:59 - sorry, no local time support yet) on the first click, and the following clicks will jump by 24 hours.

Sharper map graphics on iPad/iPhone

The scaling of the web page was tuned to switch automatically so that map graphics are not blurred on the iOS devices, especially when the device switches between landscape and portrait orientation.

Other small things

Searching for "OH2RDK" will now give a proper "there are other SSIDs available although this one doesn't exist" response.

aprs.fi now uses a new version of the Google Maps API, bringing in some visual updates and speedups from Google.

An old bug which makes stations disappear after a quick zoom-in-and-back-out operation (and some other cases) has been fixed.

The "street view is off by 200 meters" bug is fixed. Also, the map should stay centered when Street View is enabled or disabled.

The ruler tool now displays distances shorter than 1 km in meters to allow measuring short distances.

When a station is tracked on a mobile device, the info balloon does not automatically pop up and block the whole view.

Raw packets view in decoded mode displays the position packet's type (compressed, mic-e...).

Tuned digipeater/igate "heard" map to collect more data and leave less gaps in the map.

Support for new major version of the database server (SQL syntax changes).

CSRF security fixes were implemented in many places.

Some rough corners have been rounded up (literally), and a few shadows have been cast (again, literally).

Does aprs.fi feel slow?

Be sure to try it with a modern, quick browser such as Google Chrome, Safari or Internet Explorer 9. If you're upgrading from Firefox or an older Internet Explorer, you'll be surprised by the difference it makes.

Data collection outage on Sunday, 2011-01-29

aprs.fi data collection was down today (2011-01-29) between 14.20 and 14.55 UTC due to a hardware failure. After finishing my dinner I moved the master service to another server and things appear to be working properly now.


Sorry for the trouble!

aprs.fi closed in U.S. on Wednesday

aprs.fi will join Wikipedia and Reddit, and protest the proposed U.S. SOPA/PROTECT-IP legislation by closing down on Wednesday. (News about Reddit blackout, and Wikipedia joining it.)

The aprs.fi outage will only affect clients in the United States (or those with IP address mapping an U.S. network operator - the targeting is not fully accurate).

Although the law is being made in the U.S., it will break the Internet on a global scale by making sites such as aprs.fi liable for links and content posted by the users of the site. Sites like aprs.fi are commonly run by individual developers or small volunteer teams. Due to the huge volume of automatically published user-generated content (50 packets per second currently!) it would be impossible for me to go through it all before publishing. If some APRS user would post links to copyright-infringing material, even when that material would reside somewhere else than aprs.fi itself, aprs.fi could be shut down in the U.S. and there would not be much that I could do about it. See how difficult it was for a falsely censored music blog to get unblocked under the current legislation.

The law claims to be targeted at pirate web sites, but it won't have any practical effect on criminal file sharing, since those networks can very easily switch to new domain names and IP addresses, or bypass the DNS altogether with modern peer-to-peer technologies. Instead, it will force web site administrators such as myself to pre-censor data (by, for example, removing user-posted links completely). In practice: no home page link shown with your APRS station on aprs.fi. This is just silly – on other sites which depend more on linking out it could ruin the whole show.

If you're an U.S. citizen, you can probably do something about this that would actually make a difference. I'm not there, so I can't (but I voted yesterday evening in Finland's presidential election!). Please read through the material on the Reddit blackout page, there are good "Learn More" and "Get Involved" sections in the end!

Data collection will be running as usual, so Wednesday's data will be available on Thursday.

Now I'm really happy that aprs.fi is aprs.fi instead of aprs.com or aprs.net. And that I'm not living in the UK. The really bad news is that similar laws are being pushed in Europe.

PS. You can get your APRS location from http://www.findu.com/cgi-bin/find.cgi?YOURCALL or DB0ANF. If a life-threatening disaster would happen in the U.S. let me know and I'll open up the site.

APRS-IS packet loss on 2011-11-21

As seen in the statistic graphs, aprs.fi was only receiving about 60% of the APRS packets from the APRS-IS between 2011-11-20 23:40:40 UTC and 2011-11-21 08:25:57 UTC. During this time it was connected to a core server which apparently is not getting a full APRS-IS packet feed for some reason. As  a visible result the packets of about 40% of APRS stations did not get to aprs.fi.

The core server operator has been notified and aprs.fi is connected to another server again. Sorry for the trouble.

New view filters, alerts, out-of-order packet filtering and other features

I've just finished installing a rather large upgrade on aprs.fi. The upgrade comes with a couple of noticeable new features which everyone should get familiar with, a bunch of smaller style fixes and some tiny bug fixes. The web service was down for a while due to the database schema changes and engine upgrades. Only very little APRS data was lost - APRS-IS traffic was buffered during the database maintenance and processed later when the database was up again.

Here's a list of the major changes:

Complex but easy filters:

The old filters (APRS, AIS, Items+objects, WX) in the Preferences have been replaced by a whole new Filter tool button on the right side of the tool bar. It's the one which tries to look like a funnel (I'll have to work on the symbol image to make it more obvious).

Let's do a little exercise to get you started!

Deselect the All stations filter, so that no stations are displayed. Then enable the Station type: Weather filter and you'll only see stations transmitting weather data.

Next, continue by enabling Station class: APRS stations. At this point you'll see both APRS stations and weather stations, which doesn't make much sense since all the weather stations are also APRS stations. But it starts to make sense again if you click the red downward-pointing arrow for the weather stations, which throws them to the bottom of the list, in the red "AND NOT" department, effectively removing them from the display.

Now, click on the plus (+) button to add your own fancy filters to the list. For example, it's possible to create a filter which only shows APRS stations using Kenwood radios which are also acting as Digipeaters, but do not have a callsign starting with "OH2". That filter can then be used in the green "display any of these" side of filters (think of logical OR if you're into programming) or the red "but not these" side (think of AND NOT).

Once you're finished designing your favourite filter list, use the Save button to save it to a new named list. The default filter will reset to it's factory settings every time the map opens (so that you'll see something if you get lost with the filters). The filters are saved together with your user account, so you'll need to log in to save them. The upside of this is that you can easily use your preconfigured filters on many computers and even mobile devices!

Personally, I've set up several commonly used filter sets in my named lists, such as "Infra" for network infrastructure: digipeaters, igates, and "Moving" for stations which have their speed larger than 2.

New graphing engine:

Telemetry, weather and station graphs are displayed by a new third-party graphing engine instead of a homebrew one. The new engine reduces load on my servers (and adds some on the web browser's side, but that's OK since there are thousands of those against my 2), generates prettier line graphs, and will enable some really fancy interactive features in the future!

Station activity alerts:

This feature is mainly for digipeater and igate operators. It lets you know by email if your station stops working, or when it starts working again. Very handy especially if you're like me and maintain digipeaters far away from your home and would not otherwise notice when they go "kaput".

Click on the Favourites (star) tool button, then select My stations and bookmarks. Add your digipeaters in the Stations I follow list, and then click Settings for each of them and tune the timings.

Please note that due to APRS-IS duplicate filtering aprs.fi often does not get to know when your igate or digipeater hears a packet and repeats it. It's a good idea to set the "has not heard station" alert for a very long timer such as 24 or 48 hours, and then go down or up from there depending on the amount of false alarms!

An additional duplicate packet filter algorithm:

In addition to the old filtering methods, out-of-order and duplicate packets are now filtered using APRS timestamps embedded in the packets. If a packet comes in that has an older timestamp than the previous packet, it is promptly discarded. This should be a very effective duplicate filter when timestamps are transmitted by the tracker.

The raw packets display can now also display the decoded timestamp when using the Decoded mode.

Facelifts:

Since most people come to aprs.fi to look up a station's position, the callsign search box has been moved up on the right-side panel, and the time range selector has been moved down.

The real-time map displays a nice "loading" image until station data has been first received from the servers.

Buttons now have a prettier and consistent style everywhere. Some other layout and style tunings have been applied, too.

Bugfixes:

The real-time map's content reloading logic has been improved. It should now be more responsive when panning and zooming around. There's still a small bug in there - sometimes stations are not reloaded on the map when the filters are changed at precisely the right time. Oh well.

The sortable tables were not working in many views. Now they are. Click on table column headers to sort, ascending or descending.

PHG overlays are now correctly hidden when zooming out to area activity view.

The duplicate stations API bug was fixed.

As always, some smaller ones were fixed too. I also did some profiling and optimisation of old code, hoping to keep the performance of the code on similar level as before, even though new features were added in the critical code path.

Upgrades of third-party components:

Web server software, some operating system components, database engine, etc.

Post a note on the discussion group when you find a bug - this is such a large upgrade that I'm certain quite a few things don't work quite right from the start.

As usual, there are translations which need to be updated with the new features. Thank you for your ongoing support!

Partial network outage, July 5 - July 6

aprs.fi suffered a partial network outage last night (July 5 21.37 UTC - July 6 5.03 UTC). A gigabit Internet uplink was lost for the duration of maintenance by an ISP and the alternative path didn't quite provide all of the Internet's routes over BGP. Investigation continues.

The outage caused trouble for many to view the site, and some APRS data collection problems. The stats page gives a hint of the scale of the problem: http://aprs.fi/stats/daily

About 50% of the viewers disappeared. It would seem like regular APRS-IS data was collected just fine, but some CWOP data was lost. There are a lot of alternative routes that the data collector can take to get to the APRS-IS, and that seemed to work.

Sorry for the trouble.

Map loading problems last night

A memory table containing all of the last position reports for the past 30 hours or so, used for quickly loading the real-time map view, filled up last night on one of the two front-end web servers at around 2010-04-01 23:35 UTC (2010-04-02 2:35 local time). I woke up, noticed the SMS alert and fixed the problem at 2010-04-02 6:50 UTC (9:50 local time).

While the table was full, replication was stopped, and about 50% of real-time map loads (without a station tracked, just an area view) resulted in no stations displayed. Also, 50% of page loads on the site last night returned a bit old data (the stopped frontend continued to display the 23:35 UTC state!).

No data was lost during the incident, APRS-IS data collection continued normally.

Outages due to upgrades during early December

The aprs.fi service might have some small service breaks during the following few days. I'm upgrading the master server with 4*1TB disks (RAID10, 2TB usable capacity) and doing some other upgrades while I'm at it (including but not limited to the new operating system kernel, switching filesystems, LVM, database engine upgrade, etc). The first two disks already went in tonight and replaced half of the old ones, and the process will continue with data migration from the old disks to the new ones.

The first reboot (due to kernel upgrade) will be on Wednesday morning (around 0600 UTC probably). The web service should keep on running happily, but if the reboot will only take a short while, I probably won't bother to move the APRS data collection master function to the second server during the reboot, and some data will be lost during the boot.

Sorry for the trouble!

Outage on Sunday (502 Bad Gateway)

One of the two aprs.fi web servers got stuck on Sunday afternoon (around 1300 UTC 2010-09-26) and started giving out 502 Bad Gateway responses. About half of the web requests for aprs.fi ended up on the stuck server, so sometimes you got the correct response page and sometimes you didn't. For some reason the automatic failover did not work – in exactly this sort of situation it should magically disable the second server and point all requests to the working one.

I happened to be driving back from the countryside when the problem appeared. After getting home in the evening and analyzing the situation I disconnected the server from the network remotely by shutting down the switch port, so that it would not interfere and that the other web server could handle all of the site visitors. At this point, when the server disappeared completely from the network, the other server automatically took over it's IP address and the service started working perfectly.

The next day, 15 hours after the disconnection, I went to visit the hosting site to bring the server back online, and took a couple of iphone video clips of the servers. First, the primary server (at the moment running the whole aprs.fi site and serving all visitors), and then the secondary server which had just been brought up and was receiving the past 15 hours worth of APRS data from the primary server. It was pretty busy at the time, but it took only an hour to copy over all the missing data from the primary.

After the replay was completed I started up the web service on the second server, too, and the service is now again running in a redundant configuration.

Root cause analysis continues. It was definitely a software glitch, probably something to do with me running a system process under gdb to analyze a SIGSEGV it gets every now and then. It might well have caused some services to freeze. The database didn't hang and continued to replicate until the disconnection, but the web service got stuck and I couldn't log in to the box using ssh, or through the serial console.

I'll also have to fix the health check used to trigger the automatic failover procedure, so that it will work next time this sort of problem appears.

The trip to the computer room gave me an excuse to quickly try out Apple's iMovie for composing a little video. Appears to work, but I guess I still prefer Vegas. There isn't much point in this silly video, but maybe it's interesting for some aprs.fi fans. :)

Opera and Google Maps API v3

As you have probably noticed, the Street View feature has made it to the main aprs.fi site, and the beta site has been shut down (as it didn't have anything special any more). aprs.fi is now running with Google Maps API version 3 (up from version 2).

Besides an all-HTML Street View (which works on mobile browsers without Flash, like the iPhone), the version 3 API has other improvements, and all of the improvements made by Google in the future will go to version 3, not version 2. Stay tuned for more! With the new version the map loads faster on many platforms (especially mobile browsers). There are still some bugs in v3, and some compatibility problems with specific browsers, but the bigger ones should be fixed already.

One currently visible bug is that polygons are not rendering in the Opera browser. What this means for aprs.fi is that things like the track lines, APRS packet path lines and PHG circles do not show up. Symbol graphics are shown, and I suppose that everything else is working with Opera.

This problem could be fixed by either the guys at Opera (since it works in the other browsers), or the guys at Google (since they have managed to make a workaround for Opera in API v2). Now, it seems like Google isn't going to do it, so the Opera fans should hope that Opera will do the fixes instead. Or maybe they can use some other browser in the mean time. Here's a quote from a Google employee in the bug ticket for the polygons on opera:

Opera is not currently a supported browser for the Maps API. Supporting a browser is not just a policy decision. To support a browser we must add it to our automated test suite, and then ensure it passes all tests now and ongoing. So there is an overhead associated with supporting additional browsers. We have to balance that overhead against the volume of requests we see from that browser and decide if the adoption amongst users merits the cost.

We can not support Opera Mini, because it does not have a sufficient level of JavaScript support. This leaves Opera for Desktop and Opera Mobile. Together these two browsers account for less than 1% of the requests we receive for the Maps API v3. Perhaps the strongest argument for supporting Opera is that it would open up the API to a number of new platforms (eg. Symbian, WinMo). However when we exclude requests from platforms for which we already have a supported browser, that number drops to 0.05%. So right now supporting Opera is simply not a good investment of our engineering time compared to working on features that will benefit 100% of the developer and user base.

Consequently I am going to collapse all bugs relating to Opera into this one, and reclassify this as a Feature Request to support Opera. We will continue to keep an eye on this issue and on the adoption numbers, and if a new strong argument arises, or adoption increases, we will revisit it.

The statistics for aprs.fi show quite a bit more Opera users than 1%, but it's still not a lot. I could either throw out Street View and go back to v2 for some time, or stay with gmaps API v3 and ask the Opera users to use some other browser for now. I think I'll go for the latter option. I sure hope that one of the players involved does the required fixes soon.

Slowdown on Friday 26th

Yesterday the aprs.fi APRS feed was slow for about an hour, between 15:00:55 and 16:11:03 UTC. One of the WXQA servers the service connects to was down, and the connection attempts timed out. The timeout was too long, and the connection retry timer was too short, and the connect() attempt is a blocking call, resulting in slow processing of packets. I knew about the potential problem, but hadn't bothered to fix it until now.

In the evening I implemented a 2-second connect timeout and an exponential backoff for the retry timer. First reconnect attempts will happen within seconds, but they will slow down to about 2 minutes between retries. Using a non-blocking connect() would have been the correct fix, but this was a bit quicker. The problem should not appear again in this form.

It seems like no APRS data was lost or missed, it was just collected in a buffer, and processed once the connect attempts started working again. The following graph gives some idea of the relative processing rate changes. At peak about 10 megabytes of data was in the buffer.

Magic UTF-8 support, weighted callsigns and other updates

The aprs.fi service now supports UTF-8 in most APRS packet types, such as messages, comments and status messages. Using UTF-8 enables proper universal messaging for APRS users. The UTF-8 encoding of Unicode is backwards compatible with ASCII, and it can be transmitted without problems on the APRS-IS and the APRS radio frequencies. It does not require the end-user to manually switch between "compatible ASCII" and "unicode" mode depending on the language or destination, since English text (like this) is transmitted in exactly the same way in both ASCII and UTF-8. It also supports all of the special characters in other languages (åäöæø ÅÄÖÆØ ßüÜ). UTF-8 works on findu.com, too.

I strongly recommend all APRS authors to implement UTF-8 encoding in their APRS software for proper internationalization support! To get some UTF-8 testing packets, send an APRS message to the callsign UTF-8, and my testing responder will respond with four messages containing English text, Scandinavian and German special characters, and a few Japanese words.

In addition to UTF-8, I also added a magic recode feature (inspired by the irssi IRC client), which tries to guess the character set of the original packet based on the character distribution. It currently attempts to support ISO-8859-7, ISO-8859-15, CP437 and CP850. Because of the overlaps between these character sets, this feature can not be made to work perfectly - the task is impossible. It's guesswork. To get your characters to show correctly, please transmit them in UTF-8.


Inspired by weighted tag clouds, callsigns shown in the Other SSIDs list are now weighted according to the time of the last position update from that callsign. If the position was updated within 24 hours, the callsign becomes bigger than usual, and the other way around. For example: KJ4ERJ, WB4APR

The position history database table was migrated to a partitioned table. Or rather, the migration was started - new data is being inserted in a partitioned table, and old data is still in the unpartitioned one. This is a very technical change which does not make a lot of difference to most of you folks, but improves things a lot on the server side. I can now delete old history data in 1-day chunks very quickly with a minimal performance hit. Inserting new data requires less disk I/O and smaller memory buffers (thanks to the partitioned indexes).

I've also upgraded aprs.fi to use Ham::APRS::FAP version 1.13, upgraded the web server software, fixed some XHTML syntax, done some performance tweaks on the real-time map, and added support for APRS targets without a current known position (required for receiving telemetry from a station without a known position).

This upgrade was a big one, and required about an hour of downtime. Sorry for the trouble. I hope I didn't break anything this time.

Maintenance break on Saturday 5th of December

On Saturday, roughly between 18 and 19 UTC, I upgraded operating system components and installed security patches. These upgrades required taking the service down for some time, and even data collection was affected for a short while. Sorry for the trouble!

Before the reboot, the master server had an uptime of 681 days. Thanks go to the UPS and the diesel generator - there have been a few small power outages in Espoo during that time.

In the near future I'll be installing a new master server for aprs.fi, the hardware is already waiting for the OS installation in the basement.

I've also bought an 80 GB Intel X25-M SATA solid-state drive (SSD), a very quick flash-based hard disk-like device. The amount of disk I/O operations is starting to become an issue on aprs.fi, so I'm going to try moving the busiest database tables (which are also the smaller ones) on SSD. We'll see how that improves things! It might even allow me to implement some new features (which require additional I/O capacity).

Database upgrades

Today I upgraded the slave databases to a new major release of the database engine. I'd like to use some of the new features to increase the performance of the system.

The upgrade itself, and the necessary conversions, wouldn't have caused any outages, since I can tell my software to do queries on another database server while upgrading one (in fact, they will automatically fail over to another server if one is down). But, as usual, there was something I overlooked, and for a few minutes about 50% of the /info/ page requests failed and complained about problems with looking up nearby cities. I had to improve the stored procedures a bit to get them working on the new database engine version.

Please, drop a note in the blog comments, if you notice any other problems.

Account system upgrade completed

The planned upgrade has been now been done. It only took some 15-20 minutes to resolve the few issues that popped up. More details about the changes can be found in the previous blog post.

If you already have an account on aprs.fi for posting AIS data, and you don't have your login password (it's different from the AIS feeding password, and no, you didn't have one before since there was no such thing before today), try logging in with your email address and any bad password, and you'll get to the "forgot my password" path which lets you reset the password to a new one.

As usual, there are quite a few new strings to be translated. From now on, you'll have to sign up for an account and log in to access the translation tool. I hope you don't mind.

New simultaneous viewers record and related slowness

Seems like we hit a new high of over 1000 simultaneous map viewers today, mostly thanks to Dayton Hamfest, and a popular live Hamfest video feed with an embedded map. They're giving away freebies.

A couple of components started hitting file descriptor limits, which had last been upgraded over a year ago. Too many simultaneous connections per process. This made the site perform very, very slowly. I quadrupled the limits, and the site started to perform quickly again, I hope that's enough for more than a year to come. Well, I have to admit that it would actually be a nice surprise if the site would be so popular that it wouldn't be enough...

I also fixed a bug in the "first heard" algorithm pointed out by Ian, VK1IAN. The digipeater alias GATE was not treated as a special digipeater alias (like WIDE, RELAY and TRACE are), and an igate which first heard a packet with a GATE in the digi path was not given credit for hearing it first.

Another fix that went in was a filter which takes out complete APRS packets which have somehow made their way to the comment field of another APRS packet. Apparently something is loosing CR LF sequences between packets (could be my code...), which causes packets to go into the comment of the previous one. Before I find the actual bug I've added a filter to strip these off.