Changelog

Prior to the FCC retiring the old Call Sign Reservation System, the FCC would issue a monthly document that showed all broadcast call sign change activities.  

Now with these applications being filed in LMS, they are picked up and supported by REC's eLMS system.  

REC has built a new database that will be used for tracking FCC enforcement decisions.  Those who listen to FCC.today, the podcast know that we refer to these as "dingers".  

The system will track the amounts of forfeitures and subsequent adjustments through forfeiture notices as well as consent decrees.  The system will also track enforcement actions that do not propose a forfeiture such as notices of violation and citations.  

Deployed a new internal application within REC that would be used to enter in information about a natural disaster (such as a hurricane) and to indicate the status of the FCC's Disaster Information Reporting System (DIRS) at the county/FIPS level. 

Modified the REC Disaster Information Page (recnet.com/disaster) from being a static page to including dynamic content including:

ISSUE:

Some WEA alerts on the CAP Tool were showing with skeleton screens and no real information.

ROOT CAUSE:

The issue is with CAP alerts sent that are cancellations of previous alerts.  We have noticed that when some participants send cancellation alert messages to IPAWS, these alerts do not have an <area> section and as such, our systems cannot pick up full details about the alert being cancelled.

FIX:

The internal REC CAP Polling system will now monitor the FEMA IPAWS endpoint for Wireless Emergency Alerts (WEA) and on a temporary basis, the test data endpoint for WEA.  Data from each endpoint will have a unique alert type code in order to distinguish between test and live WEA.  

Validation of this functionality cannot take place until alerts are received either in the live or test data endpoints.  When the code is validated, we will remove the query to the WEA test endpoint and purge the database of all test alerts.  

ISSUE

Some Mexico and Canada allotments are not showing in REC tables used for channel searches (i.e. enac_lpfm). 

ROOT CAUSE

Due to a renewed public interest in our FMmap service, we have updated our FMmap map generators (for both FM and AM) to reflect the use of LMS for FM.  

We have also set up a weekly update that will run on Sunday mornings to refect a snapshot of the database at the time.

FMmap is an interactive map that shows the locations of FM and AM broadcast facilities that are in the database for nations supported by FCCdata.org

https://recnet.net/fmmap

Eliminated the Mastrodon operation, lpfm.social due to a lack of public interest and rising system costs.  

REC/J1 API-based services on Twitter continue to operating normally.

We have fixed an issue related to our programs that use FCC LMS data (as opposed to eLMS data) such as channel searching.  New application records were not properly being added to our version of the LMS raw data.  The root cause was an unannounced (by the FCC) addition of fields to the database files.  This issue has been resolved for now but may happen again if the FCC updates the database schema.

ISSUE

In FCCdata, call signs for some stations are missing from the header (FCC broadcast records).

ROOT CAUSE

ISSUE

FCC.today has not displayed any new pleadings since 1-6-23.

FCCdata has not shown any engineering application activity for TV facilities since 1-8-23.

ROOT CAUSE

The daily LMS bulk data file provided by the FCC has not been updated at the FCC since 1-8-23. 

This issue is impacting all REC systems that directly depend on LMS raw data.  This will not have a direct impact on FM engineering and FM/AM/TV non-engineering applications received through eLMS.  

STATUS

ISSUE:

Not all LMS application listings are appearing for TV stations, including the currently licensed facility.  Some older (CDBS) engineering records were showing as current and were on the default display.  In the Application History, multiple applications are showing with a yellow background (those that were not directly selected).  Long loading time on maps.  

ROOT CAUSE:

Various coding issues and the nature of mapping within the REC universe.

RESOLUTION:

As a continuation of the work started earlier this week, we have now fully re-implemented our systems to monitor Tokyo (Kanto area) railways other than JR East (there were no issues with our JR East monitoring).  

LPFM.us has been updated to reflect the new 2023 listings policy.  Under the new listings policy, a full listing, which includes links, station logo and other robust information pieces are limited to LPFM stations that fall under one of the following categories:

We have fixed our Twitter interface and made enhancements to remove hashtags and URLs from the Japanese results.  This restores our services for the following providers:

• Seibu
• Keisei
• Keio
• Odakyu
• Tokyu
• Tobu
• Keikyu

We have also added Yurikamome and later this week, we will add Sotetsu to the Twitter interface.

We will be doing a code conversion of the Twitter interface soon.