EDIT: I've had two offers of help, and one of them pointed out a possible issue already. I'm hopeful that it's already at least partially resolved, and may be fully resolved later today.

I'm aware of the site performance issues. It appears to be some kind of issue with TLS, probably a configuration problem in my Apache setup, but I've yet to be able to track down the problem because the server log files don't seem to want to tell me anything about it.

Is there anyone reading who knows how to manage configurations like this? The setup is Ubuntu 22.04 with Apache. I'd appreciate any help you might be able to provide; I expect someone who knows better what they're doing to be able to solve this pretty quick, but I'm flying blind. Please feel free to e-mail me via the contact info on the Contact page.

It's been a long time coming.

If you've ever looked at the Longley-Rice coverage maps in or near Des Moines, IA; Providence, RI; Florence, SC; or Gainesville, FL; you've probably noticed that they have odd diamond-shaped areas where the maps just look wrong. What's wrong is that the SRTM-3 data that is used by SPLAT to create those maps has diamond-shaped holes in it in those places. Using functions SPLAT has for handling it, I had patched in other lower-resolution data, and while it helped, it still wasn't really correct.

Yesterday I got a question from a friend about where the SRTM-3 data had moved to, since the links on the SPLAT webpage are dead now. I went looking and found it, but then I noticed a message that said the data had been updated in 2015 and now had some of the holes in the data have been patched. I grabbed the files that cover the Iowa hole, which was the worst of the four, and reran one of the maps. Sure enough, the hole there is now patched and the maps came out looking correct.

I'm in the midst of rerunning the maps that were impacted by that issue in Iowa. As of this writing, I've also grabbed the patched terrain for the South Carolina hole, and tested it on WBTW to prove that hole is also patched. Once I'm done with Iowa, I'll move on to South Carolina. I also intend to fix the maps in Florida and Rhode Island, but I'll do those after South Carolina is done. I'm going in order of how offensive I found the missing data to be; Iowa was clearly worst, but the other three are all somewhat minimal just because of how close to sea level the terrain is in those places. I personally found the South Carolina one to be most jarring, followed by Florida (pretty flat), followed by Rhode Island (decent portion of the diamond was in the ocean anyway).

It's going to take some getting used to the fact that those maps are now correct. It's been wrong for literally the last 15 years and I'm very used to it. I also want to note that there is at least one additional hole that I'm aware of in the US, in southwest Texas, but as I recall there are few or no TV stations that reach it, so I'm not sure if I'll need to do much there.

Finally, there was also a separate flaw in the terrain near the Salton Sea in California. I've tried replacing the terrain data with newer data here as well and the issue appears to be resolved per the KESQ map I ran. I'll be rerunning maps in that area as well.

UPDATE (2/16/2023 at 3:08PM ET): So the Iowa maps should be done. Let me know if you spot any I missed. I am in the midst of rerunning the Yuma stations impacted by the Salton Sea issue. I reran WBZ to test the Rhode Island fix and am happy with it. I reran WUFT and WXGA to test the Florida fix and I'm not as happy with that one. I'm going to think on that one a bit and focus on the other areas before deciding what to do there. In any event, expect to continue to see replacement maps near Florence, Providence, and Palm Springs in the coming days.

I wanted to let everyone know that earlier today I shipped the new server off to its new home, and it is tentatively scheduled to arrive there on Wednesday. So sometime Wednesday (or later in the week), expect some down time as the server is swapped out and I do the final steps to migrate to the new server. I've done the initial setup, but will need to copy over the most recent version of the database and things like that before it can go live, and it's going to be an in-place exchange of the temporary server for the new one, so there will be down time while the database is restored onto the new server. But once RabbitEars is moved to it, we should be set for a very long time.

Next, I previously promised that I would provide more details on the RabbitEars hosting situation, and I think now is as good a time as any. Our generous host is the founder of Silica Broadband in Prospect, KY. He's a long-time member of Satellite Guys who started Silica Broadband several years ago. It is a fiber ISP in the area, but also provides web hosting out of its Kentucky facility, and he wanted to help out by providing RabbitEars with a new home. I am extremely grateful for his help, and I am especially pleased to be working with someone who understands what RabbitEars does and appreciates its value to the OTA community.

Finally, I thought everyone would like to know more about the server that RabbitEars will be using. I've built it myself from new parts, and it has an AMD Ryzen 3700X processor, 32GB ECC RAM, 2x2TB WD Red M.2 SSDs in RAID-1, and runs Ubuntu Server 20.04. To say this is an improvement over the old server would be a vast understatement. The old server had a 2009-era Xeon in it, 16GB RAM, 2x2TB hard drives in RAID-1, and ran Ubuntu 16.04. The benchmarks I found indicate the new CPU performs about 10 times better than the old one, and RAM has never been a limiting factor for RabbitEars.

Exciting times await. I'm looking forward to a faster and more reliable RabbitEars!

As you know, RabbitEars has been hosted by Scott at SatelliteGuys for a number of years now since he had a decent amount of excess capacity after his site last moved servers back in 2011. With various changes to both hosting prices and traffic patterns in the past few years, SatelliteGuys no longer needed the excess capacity that it had, and earlier this month, Scott relocated the site to new hosting elsewhere on leased, rather than owned, hardware.

Unfortunately, with this change, RabbitEars could not come along for the ride. I am extremely grateful to Scott for so generously hosting RabbitEars at no charge for so long, and I certainly understand the desire to reduce costs while simultaneously improving his own site's performance with newer hardware. Scott has been very helpful in helping find RabbitEars a new home, and with his help, someone has offered to take on RabbitEars. I will announce more in the future.

But as currently planned, we're looking at a two-step move process:

First, so that Scott can stop paying for hosting that is now only used for RabbitEars as quickly as possible, the new host is going to set up a temporary server which RabbitEars will move to as soon as is practicable. I am hoping this will not result in any down time, though we will probably disable the Live Bandscan and the Signal Search Map on the old server when we start the move process, meaning some data may be lost or functionality unavailable until the various scanners figure out there's a new server to send to.

Second, I will most likely be building a server to host RabbitEars. The new host has graciously offered to let us host a standard desktop machine rather than a rack-mount, which brings hardware costs out of the stratosphere. I can build new instead of buying used as I had been anticipating, which is great in terms of performance and reliability. But this will necessitate a second move at a later date from the temporary server onto the new one. Hopefully this second move will be less disruptive than I anticipate the first will be given the machines will be in the same building rather than in different states, but it may still cause some disruption.

The specific date is not yet known, and the move will likely come with little warning. I apologize in advance for that.

Please bear with us as RabbitEars makes this move. Your patience is appreciated!

UPDATE 3/1/2021: The move has not yet happened. We had a false start yesterday, but ended up having to delay the move.

I won't promise the code is 100% correct yet, but it should be relatively close. The long-awaited and much-requested ATSC 3.0 listing page is now available:

https://www.rabbitears.info/market....

Let me know if you have questions, comments, or suggestions.