Change in the display of information from which device RaceMeter was booted. This is related to the possibility to run RaceMeter also from the SSD disk that will be placed inside (instead of SD card).
Adding the ability to end or start a race directly from the page that displays the results of that race.
Add information about start and end times on the race results page.
Added a race end time display to the main page, where races are also displayed as cards.
Fixed in the racer synchronization settings edit (in the race edit). In the dialog where you set which column from the Google spreadsheet would be loaded into which entry in the racers, the optionally displayed Google spreadsheet column menu was not hidden when closing this dialog.
Modification in the API for sending recorded starts and chip logs from the slave device to the master device. A slightly different format is now sent, which may optionally include information about the maximum ID of the entity being sent. In this case, a check is performed on the master device to see if the import (and processing) has already happened. If it is found that this ID has already been processed, the entire request is considered processed and just the same response is returned as if the records had been processed. This will make it faster for both the master and the slave. The problem used to occur with very slow communication, where although the logs were processed on the master device, the response was sent too late and the slave device did not know about the successful reception and so sent it again. In addition, I also increased the timeout from 5 to 10 seconds. If there is a reset or setting of the counters for sending chip logs or starts (on the slave device), the next upload does not contain the maximum ID information and the batch is always processed on the master device.
The structure of the data that is sent from the slave device to the master device has changed. Originally it contained only records (chip logs or starts). Now the “slave_number” entry contains the slave device number and possibly a “max_id” entry that contains the highest record ID number included in this batch. The original data is then available in the “data” entry. But the REST API that receives the data (chip logs and starts) can also handle the original data structure.
