RunScore 9.0.1 is a major race-day stability patch. We've eliminated the reported mid-race crashes, made the system highly resilient to bad internet and hardware disconnects, and added protections so simple human errors no longer take down your software.
\n\nC: drive to prevent \"ghost\" data errors and corruption.β¦and over 25 more fixes! We resolved complex file-parsing errors, improved how Windows pop-up prompts behave, overhauled our \"BugSplat\" crash reporting so we can fix future issues faster, and streamlined your initial hardware setups. This is the most stable version of RunScore ever built.
\nFixed Print & Input Prompt Crashes: We have resolved a bug where RunScore could crash when displaying an input box (such as when a listing file asks \"FROM PAGE NUMBER\"). This was due to a technical conflict in how the software requested the pop-up window from Windows. The system is now much more robust when handling these \"question mark\" commands, ensuring your print prompts and data entry boxes appear reliably without interruptions.
\nImproved Error Messaging Reliability: We fixed a frustrating bug where certain error alerts, meant to warn you about a problem in your setup, would actually cause the software to crash instead of displaying the message.
\nSmoother Setup for New Laptops: We've fixed a frustrating \"Invalid Baud\" error that appeared when setting up external timers on new computers. Previously, RunScore would try to validate settings for all eight timer slots at once, even the ones you weren't using! The software is now smarter: it only checks the timers you have actually set to \"Start.\" Furthermore, if you are using a modern network (TCP) connection, it will no longer nag you about \"baud rates\" (which only apply to old-school serial cables). This makes your first-time hardware setup much faster and more intuitive.
\nImproved RSClient Connectivity: We have refined the connection process between the RSClient and your main server, specifically for new computers. We fixed a logic error that caused the software to claim a server address was \"missing\" even immediately after you typed it in. Additionally, we fixed a bug that prevented the connection window from reopening if you hit \"Cancel.\" You can now freely open, close, and retry your connection settings without being locked out. This ensures a stress-free setup when configuring your announcer and results screens on a fresh laptop.
\nStable MyLaps Shutdown: We have fixed a crash that could occur when closing a race or disconnecting a MyLaps timer. Previously, stopping the timer connection at specific moments (like during an initial setup or mapping prompt) could cause RunScore to close unexpectedly. The software now handles these disconnections gracefully, ensuring you can wrap up your event or change hardware settings without any \"BugSplat\" errors.
\nFixed \"Next Bib\" (F4) Crash: We have resolved a bug that caused RunScore to crash when pressing F4 to find the next available bib number. This crash typically occurred if your database was set up with a long text field (like a Name or Address) as the first searchable item in your list. RunScore now handles this setup correctly. More importantly, if your database configuration isn't quite right for the \"Next Bib\" feature to work, the Runtime Validator will now give you a clear warning telling you exactly which field needs to be adjusted.
\nNetwork Share Protection & Performance Warning: To protect your race data and prevent system crashes, RunScore now detects if you are hosting a race on a network share (such as a shared office drive or a UNC path). Real-time race timing requires extremely fast, low-latency disk access. Running a race over a network can cause \"ghost\" data errors, performance slowdowns, and crashes when remote screens try to connect. If RunScore detects a network-hosted race, it will now provide a warning dialog with best-practice advice. For the best experience and 100% data safety, we always recommend copying your race folder to your local C: drive before you begin timing.
\nFixed Crash on Race Close or Erase: We have resolved a rare but frustrating crash that could occur if you clicked an event selection or results button at the exact same moment you were closing or erasing a race. Technically, the software was trying to process your click for a race that had just been \"packed up\" and removed from memory. We have added a new safety guard that allows RunScore to recognize when a race is no longer open and simply ignore any \"in-flight\" commands, ensuring the software remains stable even during rapid screen changes.
\nRemote Race Stability Fix: We have resolved a complex \"sync\" issue that could occasionally occur. In some cases, if a specific file was missing on the server, the Server and Client would get \"out of step\" in their conversation. This led to a \"cascading\" error where the client might accidentally save the wrong data into your entry form, resulting in a \"Failed to read field type\" error when trying to view participants. We have implemented a new Message Framing system. Think of this like adding clear punctuation to the end of every sentence the computers speak to each other. Even if there is a network glitch, the Server and Client now have a foolproof way to stay in sync, ensuring that remote race opening is rock-solid every time.
\nEmpty File Stability Fix: We resolved a crash that occurred when RunScore encountered an \"empty\" configuration file (like a DIVISION file with no text in it). Previously, the software would mistake this empty file for a valid one and crash while trying to read it. The system now correctly identifies these files and handles them safely.
Fixed Browser Refresh on Remote Stations: We have resolved an issue where the main participant list (Browse window) on a remote computer (RSClient) would not update automatically after you added a new entry. Previously, if you were typing in new participants on a secondary laptop, you would have to manually refresh the screen to see the names you just entered. Now, as soon as you hit F10 (Save & Close) or F12 (Save & New), the list will instantly refresh to show the new data and automatically scroll to the new record. This ensures that all stations always have a \"live\" view of the race database.
\nFixed Typo-Induced Crashes (Birth Dates): We have resolved a bug where RunScore could crash if a participant's birth date was entered as being after the race date (for example, accidentally typing \"2027\" instead of \"1997\"). Instead of closing unexpectedly, RunScore now handles this typo gracefully. The Runtime Validator will flag the specific record for you to fix, and the software will continue processing the rest of your participants. This keeps your registration and results flow moving even if there are data entry errors in your database.
\nAccurate Error Reporting for Online Downloads: We have fixed a bug where the Runtime Validator would point to the wrong record number (often \"Record 0\") when reporting data errors during an online download.
\nFixed External Timer \"Event(TM)\" Crash: We have resolved a bug that caused RunScore to crash when selecting the Event(TM) option in the External Timers setup (common for Time Machine, iPico, and MyLaps users).
\nEnhanced Stability for Cloud & Timer Syncs: We have resolved a crash that could occur when RunScore needed to ask you an \"event mapping\" question (like \"Which event should this data go to?\") while a background task was running. Previously, if a background process, like a cloud download or a timing hardware feed, tried to open a pop-up window at the same time the main interface was busy, it could cause a conflict that crashed the software.
\nFixed Role Table Crashes & Menu Availability: We have resolved a technical \"memory conflict\" that could cause RunScore to crash when editing user roles or permissions. Previously, changing a role's name could occasionally \"confuse\" the computer's memory, leading to an unexpected shutdown. We've redesigned how these tables are managed to be much safer and more efficient. Additionally, we've \"unlocked\" the Clients and Roles table menus so they are always available for editing, even if you aren't currently connected to a remote timing server.
\nImproved \"Black Box\" Crash Reporting: We've upgraded RunScore's internal \"flight recorder\" (BugSplat) to be more consistent. Previously, certain types of rare errors would cause the software to close without sending us a detailed diagnostic report. We've standardized the reporting system so that if a crash occurs, the software will always capture the necessary information to help our team fix the issue quickly. We also took the opportunity to \"clean the attic,\" removing some old, unused code to keep the software lean and fast.
\nFixed Missing Custom Questions (Race Roster): We have resolved an issue where long custom questions from Race Roster (such as detailed newsletter opt-ins) would occasionally fail to appear when downloading participants. We've increased the character limit for these question titles to ensure that even the most detailed questions are correctly captured and shown in your field-mapping screen.
\nLightning-Fast Email & SMS Status Displays: We have overhauled how the status bar tracks large email and text message blasts. Previously, if you sent an email to 1,000 participants, the status bar at the bottom of the screen would get \"stuck\" scrolling through every individual email address one by one for over an hour, even though the messages had actually finished sending in under a minute. RunScore is now much smarter. Instead of clogging the display with thousands of lines of text, it dynamically switches to a live counter showing you the exact number of messages sent in real time. Once the blast is finished, a clean summary (e.g., \"Email broadcast complete: 1000 sent\") stays on screen for 15 seconds. Additionally, all broadcast actions are now permanently logged in your Runtime Validator files so you always have a record of what was sent and when.
\nTypo Protection for MYLAPS Event Configurations: We have fixed a bug where a simple text typo in a listing file could cause RunScore to crash. If a non-numeric character (like a letter or a symbol) was accidentally typed into a field expecting a MYLAPS Event ID number, the software would get confused trying to convert the text and shut down unexpectedly. RunScore now sanity-checks this information first. If it detects a bad character, it will pop up a helpful error box to let you know your listing file needs a quick correction, and it will safely stop generating that specific report without crashing the rest of the application.
\nStrict Duplicate Bib Prevention in the Browse Window: We have fixed a data integrity bug where duplicate bib numbers could accidentally be saved if you edited them directly inside the main grid (Browse window). Previously, the software's background uniqueness check was looking at the old value of the field instead of the new value you just typed. Furthermore, it was checking text that hadn't been correctly aligned yet, allowing duplicate numbers to slip through without triggering an alert. RunScore now fully normalizes and scans your inputs instantly when editing directly in the grid, ensuring that a duplicate bib or unique field will always be blocked and flagged before it can cause data conflicts.
\nFixed Crashes on Absolute External File Links (.include): We have resolved a memory stability bug that could cause RunScore to crash when processing complex listing setups. If a listing file used an .include command to pull in a report template located outside of the active race directory using an absolute path (for example, pointing directly to a shared drive or a different folder like C:\\GlobalTemplates\\header.txt), the software would miscalculate the text length, read past the end of the file name into uninitialized memory, and crash. RunScore now utilizes an upgraded path-resolution engine that safely checks external and absolute file locations without any risky memory guesswork, ensuring your multi-file results and report templates load seamlessly.
Fixed ChronoTrack (CT) Live Login and Connection Crashes: We have resolved an issue that prevented RunScore from successfully logging into ChronoTrack Live. The software was reading your saved credentials from the registry but failing to pass them along to the web server, resulting in authentication errors. Additionally, we fixed an intermittent crash that occurred immediately after clicking \"Select Event\" on CT Live downloads. This was caused by an internal file-reading calculation that didn't leave enough room in memory for the downloaded event data. Memory management has been hardened on both the server and remote clients, restoring smooth and stable CT Live synchronization.
\nDetailed Connection Error Messages and Crash Fix: We have resolved a bug where RSClient would crash unexpectedly if you entered an invalid or mistyped server name when attempting to connect to a remote race. Instead of shutting down due to the network naming error, RunScore now safely intercepts the failure and checks with Windows to see exactly what went wrong. The software will now stay completely stable and show you a precise, clear error message, such as \"No such host is known\" or \"Network dropped\", instead of the old generic \"Connection to server has failed\" notification. This makes troubleshooting network setups and connection drops significantly easier.
\nFixed Screen and Data Entry Configuration Filters (Entries.INI): We have resolved two legacy bugs within RSClient's screen format and custom form layout parser. Previously, if a data entry profile included a conditional evaluation rule (like checking if a field matched a specific value) but omitted the field declaration line directly above it, remote stations would experience an immediate crash when loading the race. Furthermore, using more than 36 variables (%n) in automated messaging rules could cause internal memory tables to overflow and destabilize the station. Both vulnerabilities have been fully patched with modern safety limits. Remote stations will now intercept malformed or excessive layout commands gracefully and keep running without interruption.
Fixed Remote Announcer Screen \"Number Not Found\" Error: We have resolved a bug where the Announcer window on remote tracking stations (RSClient) would stop matching names to bib numbers and display \"Number not found\" for all incoming reads. This was caused by a recent network optimization that introduced an invisible helper character to separate server commands. While this worked great for regular data entry, it left an extra unread character in the live timing feed, throwing the server and client slightly out of step. The software was effectively trying to read the data starting at the wrong letter. We have switched the announcer stream to a dedicated raw data pipeline, removing the extra character and restoring accurate real-time name displays for your announcers.
\nFixed Awards and Custom Text Uploads to Race Roster: We have resolved two issues that caused custom text reports (such as a \"Top 3 Overall\" results list) to fail or upload incorrectly to Race Roster. First, the software was accidentally clearing your custom row limits on text files, resulting in the entire participant list exporting instead of just the top winners. Second, background utility reports (like participant exclusion filters) were creating tracking mismatches that caused the final upload to silently fail. Both behaviors have been corrected so that text-based award listings upload smoothly with the exact row constraints you specify.
\nFixed Application Freezes During \"Update All Entries\": We have resolved an intermittent bug that could cause RunScore to completely freeze or hang when running the \"Update all entries\" utility. This issue was caused by a highly technical conflict between an automated background timer and the entry processing loop. The background timer, which watches to see if your layout files have changed on disk, was misreading an internal time check due to a memory lifetime glitch. This caused the software to falsely believe you were modifying your configuration files at the exact same fraction of a second it was trying to update your participant database. The two tasks would collide and lock each other up. We have modernized how file times are tracked, ensuring background checks never interfere with active database updates.
\nFixed Startup Crashes on Double-Launch: We have resolved a bug that could cause RunScore to crash with an \"Access Violation\" error if the software was launched twice at almost the exact same instant (for example, if a user rapidly double-clicked the shortcut icon or if automated scripts opened multiple windows together). When two instances tried to load their windows, read the computer registry, and check software licenses at the exact same millisecond, they would step on each other's toes and crash. We have added an internal \"gatekeeper\" (a named synchronization mutex). Now, the very first window to open is given exclusive rights to finish loading its files and verify its license while the second window safely waits its turn in the background. Once the first instance finishes initializing, the gate opens, allowing both instances to run smoothly side by side.
\nFixed Crashes When Switching Between Races: We have resolved an intermittent bug where RunScore could crash with an \"Access Violation\" error when closing one race database and opening another. This issue occurred if the first race included an Age field on its entry form, but the second race did not. When closing the first race, RunScore was clearing the data from memory but accidentally left behind a \"ghost\" pointer tracking where the old Age field used to live. When the next race opened without an Age field, the system would mistakenly look back at that old, deleted memory location and crash. We have updated the database cleanup sequence so that all internal form coordinates are completely erased the exact millisecond a race is closed, preventing any memory crossover when opening a new file.
\nRobust Internet and FTP Disconnect Protection: We have overhauled how RunScore handles background web uploads when your internet connection suddenly drops or fluctuates mid-race. Previously, if a network dropout occurred while sending results to an FTP server, the software could freeze or crash. This happened because the background network task would get locked waiting for the internet to return, while the main program would simultaneously try to clean up or close the race, leading to an internal memory conflict. RunScore now includes strict network timeout controls. If your connection cuts out, the software drops the stalled socket instantly, safely preserves your background upload queue using a decoupled memory snapshot, and ensures the program remains completely stable and responsive so you can keep timing your event offline.
\nFixed Data Corruption on Custom Questions with Commas: We have resolved a text-parsing bug where downloading participant records could cause data to become shifted, cut off, or corrupted if a field contained text inside quotation marks with commas in it. For example, if a participant selected a descriptive checkbox or waiver text like \"Neurodivergent (Autism, Down Syndrome, Other)\", RunScore's import utility would misinterpret those internal commas as column separators, even though the text was wrapped safely in quotes. This threw the remaining columns out of alignment. We have rewritten the text classification engine to properly recognize quotation barriers, ensuring text options containing commas are imported exactly as intended without breaking the row layout.
\nFixed Data Search Crashes on Right-Aligned Fields: We have resolved a bug where attempting to search or filter data inside right-aligned fields (such as certain bib number or custom division columns) could cause RunScore to crash unexpectedly. This was caused by an outdated text-handling rule left over from an older version of the software. When performing a search in these columns, the program would try to clear out trailing spaces by targeting a character slot that didn't actually exist in memory. This corrupted the software's immediate workspace and forced a shutdown. RunScore now uses a modernized, auto-protecting boundary check when processing your search queries, keeping the application perfectly stable.
\nWireless Disconnect and Crash Protection: We fixed an issue where a remote device losing its WiFi connection mid-race could cause the RunScore server to crash. Previously, a sudden wireless dropout could leave garbled data in the network pipeline. Upon reconnection, the server would misinterpret this corrupt data as an invalid competitor number, causing the program to freeze. RunScore now automatically clears network memory on disconnect and strictly validates all incoming data. The software safely ignores corrupt requests, ensuring your timing environment remains completely stable.
\n1-Mile Age-Grade Accuracy Fix: We corrected an issue where male age-grade percentages and award rankings for 1-mile races were calculated incorrectly. A previous data update accidentally applied female scoring factors and an incorrect baseline time to the male 1-mile division. RunScore now uses the official 2025 WMA scoring tables, ensuring accurate results and fair standings for all competitors.
\nData Entry Screen Reset Fix: We resolved an issue where saving a participant record (using F10 or F12) could cause the data entry screen to lock up or fail to advance to the next entry. This occurred on race configurations using specific blank or right-justified fields. Upon saving, a background safety check would mistake the freshly cleared screen for an error, blocking RunScore from generating the next automatic bib number or resetting the workspace. The entry screen now resets instantly and smoothly after every save. Additionally, error logs for AltKey configuration issues will now display the exact file path, making startup errors much faster to locate and fix.
\nSearch Stability Fix: We resolved an intermittent crash that could occur when performing specific database searches. The system now automatically validates all search parameters behind the scenes, ensuring the program remains completely stable during complex queries.
\nLive Results Scrolling Stability: We fixed a crash that occurred when the scrolling Live Results board displayed multiple time splits or calculated columns (such as triathlon splits or gun-minus-chip net times). Previously, the background timer could trigger an internal memory deadlock when simultaneously refreshing multiple time intervals on the same line, causing the display to freeze or close unexpectedly. RunScore now safely isolates these time calculations behind the scenes and includes automatic error recovery, ensuring your results boards scroll smoothly and reliably throughout the event.
\nDecommissioned Registration Platforms Cleaned Up: We have completely removed integration code for several discontinued, non-operational third-party online registration platforms, including GetMeRegistered, Active (ActiveWorks), ZapEvent, and imATHLETE. Because these external services are no longer in business, removing them allows us to clean up the software menus, reduce background overhead, and significantly speed up system load times.
\nWe are incredibly excited to unveil RunScore 9.0.0! A release that marks the beginning of a new chapter. This isn't just an update; it's a complete evolution of the software you've relied on for decades.
\nThis version delivers 188 epics, bug fixes, and major improvements. We have focused on extreme performance, absolute data integrity, and a new community-focused model that makes RunScore accessible to everyone.
\n\nThe annual license model is officially retired. We believe the best timing tools should be available to every timer, everywhere.
\nOur new MYLAPS Cloud integration is designed for speed.
\nWe've addressed long-standing \"silent\" issues to ensure your results are 100% accurate.
\nWe've shipped some great improvements and want to share a few tips to get the most reliable results on race day.
\nWhat's New
\nA Few Best-Practice Reminders: Behind the scenes, RSClient doesn't actually do the \"work\" itself β it asks RSServer to do everything for it over the network. That's great for viewing data, but it means some things are safer and faster when done directly on RSServer.
\nHere's our recommended setup:
\nRSClient = a window to look at the race. RSServer = where you run the race. When in doubt, do it on the server.
This release wouldn't have been possible without our incredible community.
\nRunScore 9.0.0 is the most stable, fastest, and most accessible version of RunScore ever built. We are proud to put these tools in your hands for free.
", "url": "https://docs.runscore.com/changelog/9.0.0", "title": "9.0.0", "summary": "We are incredibly excited to unveil RunScore 9.0.0! A release that marks the beginning of a new chapter. This isn't just an update; it's a complete evolution of the software you've relied on for decades.", "date_modified": "2026-04-21T12:00:00.000Z", "author": { "name": "RunScore Team" }, "tags": [ "release" ] }, { "id": "https://docs.runscore.com/changelog/8.4.3", "content_html": "We are excited to announce RunScore version 8.4.3. This update focuses heavily on improving stability and reliability while introducing key features to make your race-timing workflow smoother and faster.
\nYou should notice a significant reduction in unexpected crashes, better performance, and several quality-of-life improvements across the application.
\n\nWe found that many users were experiencing errors or unexpected crashes. This often happened because their computer either didn't have this necessary Microsoft component installed, or it had an older version that wasn't fully compatible with the latest RunScore features.
\nThe update was made because RunScore needs the latest Microsoft component to work correctly. Automatically installing the newest version ensures a smooth experience and guarantees stability on all systems. Since this component is from Microsoft, the installer may ask you to reboot your computer; this is expected and safe, and you can proceed with the reboot when prompted:
\nThe Enter Window (used for single-entry data input) has received significant updates for speed, usability, and stability.
\nThe majority of this update focused on making RunScore more stable and less prone to crashing, especially during live timing and network operations.
\nRunScore 8.4.2 delivers one of the most comprehensive stability and performance updates in recent history, with 41 tracked improvements addressing long-standing crash scenarios and inconsistencies.
\nThis release strengthens the system's internal architecture, improves crash resistance and file handling, and lays technical groundwork for upcoming feature expansion.
\n\nThis release was subjected to an extended beta program consisting of:
\nAcross these builds, 20 confirmed bugs were resolved and 21 engineering tasks were completed. The scope of work includes everything from crash tracing to usability edge cases.
\nRunScore 8.4.2 is an essential upgrade for all users. With dramatically improved crash resistance, smarter file handling, and the technical groundwork laid for a major new capability, this version positions the platform for smoother timing operations today and exciting growth tomorrow.
", "url": "https://docs.runscore.com/changelog/8.4.2", "title": "8.4.2", "summary": "RunScore 8.4.2 delivers one of the most comprehensive stability and performance updates in recent history, with 41 tracked improvements addressing long-standing crash scenarios and inconsistencies.", "date_modified": "2025-07-31T12:00:00.000Z", "author": { "name": "RunScore Team" }, "tags": [ "release" ] }, { "id": "https://docs.runscore.com/changelog/8.4.1", "content_html": "Over the last ten months, our team has focused on a significant issue affecting application stability: memory management. Almost all (96%) of our problems stemmed from insufficient memory management.
\nWith version 8.4.1, we aim for enhanced stability that RunScore has never experienced. We fixed 157 issues spanning memory modernization, runtime validation, entries processing, the Enter screen, and a new results management feature.
\n\nThe SDL checks implement additional security measures at runtime to ensure the application does not perform actions outside the allocated memory space.
\nThis is important because the LINE FEED command \"appeared to work\" in the previous version, but in reality, the code accessed memory outside the allocated range. Such issues can lead to crashes, data corruption, and security vulnerabilities.
\nThe correct usage is: LINE FEED 2
The main goal of this release was to improve the program's stability. RunScore 8.4.0 performs runtime checks before operating with memory and will terminate the application if memory corruption is detected, rather than continuing with undefined behaviour.
\nStarting with this release, RunScore adopts Semantic Versioning 2.0.0. Our team addressed 128 issues to eliminate unpredictable behaviour and outdated code that could cause crashes.
\n\nRunScore 8.3.7.5 focuses on stability fixes for Server-Client connectivity, team downloads, chip data processing, and Entries.ini validation, plus improvements for error messages, printer handling, and MyLaps connections.
\nThis release resolves six critical crash scenarios and adds four enhancements for clearer diagnostics and more reliable external timer connectivity.
\n\nFindFirstFileA calls.RunScore 8.3.7.4 resolves critical crashes when viewing results from the Client and when receiving null point-of-read data from external timers.
\nThis release also improves ChronoTrack and MyLaps connectivity with real-time status display, support for up to 50 simultaneous connections, and automatic reconnection within 20 seconds.
\n\nRunScore 8.3.7.3 addresses critical stability issues including race-closure crashes, ghost processes in Task Manager, Live Results navigation failures, and listing file exception handling.
\nThis release also adds configuration improvements for events, external timers, ignored chip reads, and the installer package.
\n\nRunScore 8.3.7.2 resolves critical crashes during registration processing and duplicate bib handling on the Results screen, and modernizes singleton management and race-folder permission checks.
\n\nRunScore 8.3.7.1 adds RaceRoster team type name downloads and resolves multiple critical crashes affecting chip data processing, the Announcer screen, browser search, and TFRRS posting.
\nThis release also improves Announcer command handling for lap races and strengthens runtime memory checks.
\n\nRunScore 8.3.7.0 introduces team downloads from RaceRoster and fixes eight bugs affecting results sorting, race opening, data entry, team results posting, import replace, and lap time recording.
\nThis release also improves error messaging on slow connections and Fusion data transfer performance.
\n\nRunScore 8.3.6.35 adds configurable auto-save intervals as short as six seconds, encrypts crash-report logs to protect personal data, and fixes crashes in the Announcer window, entries.ini lookup, multi-file output, and large RunSignUp downloads.
\n\nc:\\runscore\\path).delete vs delete[] usage in the results class.RunScore 8.3.6.34 fixes four bugs affecting RunSignUp downloads, invalid chip reads, application shutdown, listing file destinations, and USAT/USATF registration downloads.
\n\nRunScore 8.3.6.32 fixes three AutoRun-related crashes and adds more in-depth logging for easier diagnosis on race day.
\n\nRunScore 8.3.6.31 fixes an AutoRun crash with lap races, adds unstructured results posting to Race Roster, integrates the ESEO registration system, and removes Sub-Event ID from text outputs.
\n\nRunScore 8.3.6.30 improves API data encoding for special characters, adds unstructured results posting to Race Roster, and removes Sub-Event ID from printouts.
\n\nRunScore 8.3.6.29 fixes two bugs affecting listing file JSON creation and the Announcer screen when opened from a listing file.
\n\nRunScore 8.3.6.28 fixes an issue with a new thread that prevented some users from posting results to Race Roster.
\n\nRunScore 8.3.6.27 improves internal data management and moves listing file processing to its own thread, keeping the GUI more responsive during race operations.
\n\n