GSRS Lead Timer Newsletter

Changes to race setups

Submitted by teschek_bill on Mon, 07/12/2021 - 15:46

July 12, 2021

With the race season finally getting under way and scheduled to get very busy in the fall I'm going to do a bunch of these newsletters to update you all on a few things and to send out some refreshers and reminders. I'm using this Newsletter format so that the information will always be available on our website (under the Staff menu). All of the old ones I've sent over the past few years are in there and I strongly recommend reading through them all again when you get a chance. You'll probably find that you've forgotten a lot of what is in there. I wrote the things and even I find rereading them to be useful reminders! You can just click the GSRS Lead Timer Newsletter link at the bottom of this email or page to see all of them.

Sometimes these newsletter emails get trapped by spam filters, so please shoot me a text or email after you receive this so that I'll know that you got it. If I don't hear back from you in a couple of days I'll contact you to find out if you got it.

In this first newsetter I want to talk about some changes to race setups. Over the course of the past year I made a number of changes to the way some of the Runscore race setup files worked that you all need to be aware of. Those of you who do your own race setups need to know all of this, while those of you who don't won't need to know right now. But hopefully you all will be doing your own setups some day so I'm passing it on to all of you.

All 2019 race setups have been upgraded (or will be by the time the 2021 event comes around), as well as the three races from 2020 that had normal events – 8TUFF, HYANNIS, and CLOVER. Going forward be sure to use these files in dropbox for templates until the race has already happened post-pandemic with the typical mass starts. Races that used staggered starts have significant changes to their setups so shouldn’t be used when they next go with a mass start. I'm keeping track of which year's setup to use next time and will let you know before each year's race. When in doubt, use 2019. If using a 2019 setup be aware that the course records in that setup will be from 2018, so check all years that the race has been run since then in your new setup, not just the 2019 event.
All setups now have a DOB field in addition to BIRTHDATE. When importing pre-registration files from Excel rename any birthdate column to DOB to have the information go there instead of into the BIRTHDATE field. BIRTHDATE is now reserved for use on race day entries only where you don’t have an age and need to type the birthdate in order to have it calculate the age. Using DOB will prevent the problem that occasionally arises with incorrect birthdates automatically changing peoples’ ages when it shouldn’t.
The AGE field has been expanded to three spaces in length instead of two. This accomplishes two things. One it allows for people over 100, in the rare event you get some. But more importantly, it eliminates the problem where we would type a one digit age and forget to hit carriage return (because we’re not used to having to do so after typing an age) and the one digit age would turn into two digits when you started typing the zip code immediately afterwards. It will take a little while to get used to having to hit enter after you type a two digit age, but once you’ve created that muscle memory it will be smooth sailing. To prevent accidentally creating three-digit ages the AGE field is being set to only accept ages between 1 and 109, so you'll get an error message if you type three digit ages outside that range. Only with 10 year olds is it possible to make an error that sticks.
The field PHONE has been added to all setups (except some cross country-type meets) so when importing data from pre-registration Excel files, leave the phone numbers in there if you have them. It’s not information we normally need, but sometimes it comes in handy.
In the race ini file there are now some new lines to help make your lives easier.
1. Any entry without data in the last name field will now have UNKNOWN RUNNER automatically added to LAST NAME. This means that unidentified chips that cross the line won’t have blank entries any more, and you’ll never need to run the UNKMAKE.LST file again. In fact, that listing file has been deleted everywhere.
2. Any entry with just a zero in the age field will have that field blanked.
3. The commands SHOW ADDITIONAL, NOT FOUND ADDED, and SHOW SELECT EVENT have automatically been set to YES so that your results screens will display properly all the time.
The OPERATOR field has been eliminated from all races where we aren’t likely to have more than one computer doing data entry. The only need for that information now is when there is more than one person typing and you may need to know which person’s entry pile might contain an application you are looking for – when searching for a dupe, for example.
All event to database listing files have been streamlined into one @EVENT2DB.LST for all races. No need to run separate 2DBGUN, 2DBNET, and 2DBSTART files, for example. They all run with one file. Included in the @EVENT2DB listing file is the process whereby all data in the database such as DIVPL, TIME, PACE, SEXPL, DIVTOT, etc. are blanked out and then rerun. This will prevent bad data from test races or from runners who needed to be DQed from remaining in their records. In addition the process deletes the DIV field (for everyone with an age) and then recalculates their divisions based on age. Doing this will prevent someone who had their DIV previously set to MOPEN or FOPEN, who then gets DQed, from keeping that info in the DIV field. The @EVENT2DB.LST file has been added to almost every @ listing file so it will be run frequently without you having to think about it.
The OPEN2DB process that makes the top X number of male and female runners have a DIV of MOPEN or FOPEN is now added to most @ file listings using a file called @OPEN2DB. This way top ten listings, and prelimin and final result listings will all show MOPEN or FOPEN for those runners' divisions. Inside the @OPEN2DB file is the number of excludes, so during setup in addition to the existing EXCLUDE lines in the @AGERES listing files you also need to check this @OPEN2DB file. The ##SETUP file has @OPEN2DB in it to make it easier to get at when doing your setups. If a race goes from no excludes to having them, you’ll only need to activate the two lines in the @OPEN2DB file and you’ll be all set there. Then activate the lines in @AGERES listing files as well.
All final and preliminary results listings have been turned into @ files, even if they don’t have to run the OPEN2DB process. This way if a race decides to do excludes where in the past them have not, it’s a simple matter to activate them. By making them @ files I’ve been able to also add the ADDSUB and @EVENT2DB lines to them.
@AGERES listings have been changed so that they select only on the DIV field, and don’t worry about sex and age. For one thing, having them do both never worked, and even if it looked like they were selecting on sex and age, it wasn’t working, and they were only selecting on DIV. And now when you need to change the age divisions, it involves less work.
All @FINALRES files for standard distances have a column for age grade percent.
In the IRESULTS2 files the DIVISION TOTAL command has been spaced over. Since this file is what the iResults Connector program uses to send emails, having it include a Division Total figure before the race is over is sending inaccurate information. It's not critical information anyway. If you want to include it after the race you'd have to reactivate that one line, but then also reload that IRESULTS2 file in the iResults Connector program. Not really necessary to do that.
Due to a change in policy by Marathon Sports (who owns iresultslive.com) we can only use that website and the iResults connector program on races that use Lightbox for registration. For all other races I have been posting results to the Race Roster website. Posting results and emails is done right out of Runscore listing files. Before any race where you'll need to use this I'll work with you individually to explain how it works.
A DQ field has been added to all races. Most already had it, but a few didn’t. All listing files now must include DQ = blank so that these people don’t show up in results listings. Best practice is to always DQ every bogie who shows up in the results, and not just delete their times from the screen. Those deleted times often end up coming back, so if they now say DQ in their DQ fields it won’t matter if their times pop back up in results.
We now are creating a results archive on our website (thanks Chris!) and it requires that the results files be named in a particular format. So when you save results .txt files please save them with names like this:
1. 2021 Overall.txt
2. 2021 Top Ten.txt
3. 2021 Age Groups.txt
4. 2021 Teams.txt

Lead Timer Newsletter #5

Submitted by teschek_bill on Tue, 02/18/2020 - 18:56

February 18, 2020

I want to follow-up on some of the items in the long newsletter I sent not-so-long ago. Bob had some good comments and suggestions.

Regarding the issue of questionable or missing genders in the database. if you do have some of these you should let the race directors know about them so they can either contact the runners (if they have time) or make a note on their registration file to ask them when they show up to pick up their number. We don't want to just ignore a potential issue if we can get the race director to resolve it prior to the race.
In the discussion about adding a minimum or maximum accepted time to SimpleClient, always err on the side of a runner having a really fast finish. For example, for a 5k, use a 14 minute finish time (unless Joshua Cheptegei is running in which case even 13 minutes might not be fast enough!). If for some reason you use a time that someone beats, just close out SimpleClient and restart it with a more appropriate min or max time.
The wheelchair section needs a complete rewrite:

Wheelchairs and Duos

We don't often see wheelchairs at smaller races any more. Fifteen or twenty years ago it wasn't all that uncommon, but nowadays it's usually only the big races where you see them. But every now and again you can get surprised when a wheelchair shows up, so you need to know what to do to score them properly as they almost always get a head start. The first thing you need to know is the 'differential' between the start time of the wheelchair(s) and the start time of the main field. Start a Time Machine and/or stopwatch on the wheelchair start, and then stop it when the main group of runners starts. Make note of that time differential.

For wheelchair results, use the separate WHEELS.LST file. You may need to edit it a bit to make it work properly, but usually this will be set to look for times in event WHEELS. That means you need to type the wheelchair athlete's time and bib number into event WHEELS. You can get their time from the overall results when their chip was read at the finish line, but remember that if they started early this is no longer the correct time. So either do the math on their chip time to make it correct for them, then put it into event WHEELS, or put a line in your WHEELS.LST to add the differential amount to event WHEELS. Have it read EVENT (tab) WHEELS (break) PLUS followed by the differential time. And you'll need to make sure that they have a Y in the WHEELCHAIR field of their record in the database. Your regular results files should all require the WHEELCHAIR field to be blank, otherwise the wheelchair will show up in the regular results if they have anything in event TIME. I also recommend having a separate timepiece to record the times for all wheelchair athletes who start early if possible. Dedicate a Time Machine or a stopwatch to them and find a volunteer or two who can just look for wheelchairs and record their finish times and bib numbers.

A very common situation you may run into is a "Duo" or "Assisted" wheelchair, where a runner will be pushing another participant in a wheelchair. These people should usually be treated as runners and left in the overall results (unless the race has a separate category for them) so you should not put a Y in the WHEELCHAIR field for them. But, they may very well start early so you'll still need to deal with a time differential The time from their chip will be off by the amount of the differential. You'll need to find their time in the results and change it by adding the amount of the differential to their chip time. If you do this, keep in mind that if the times get reloaded for any reason their old, faster time will reappear and you'll need to fix it again.

I don't recommend leaving regular wheelchairs in the results as we do for duos, because they will be given a division place in the overall results listing and could confuse the results.

Lead Timer Newsletter #4

Submitted by teschek_bill on Wed, 03/27/2019 - 19:20

March 27, 2019

It has been ages since I sent out one of these "lead timer newsletters", but I've been making notes of things I wanted to share. That's why this is so long! And I'll also be sending another newsletter to the entire staff, as it has items that pertain to more than just scoring. Some of you haven't been lead timers long enough to have ever received one of these, and others haven't really even been trained to do it yet, but soon will be. (Yes, I'm talking about you Hannah and Ken) Please take the time to plow through what's here and let me know if you have any comments or questions. If some of this is over your head right now just skim it and go back to it later once you've had a bit more experience. I also recommend following the link at the bottom of this email to go back and read previous newsletters. I don't know about you but I find it easy to forget a lot of this stuff because much of it doesn't come up all that often. A reminder once or twice a year is a good idea and can possibly save you from some headaches on a future race day.

Supplemental Results files to iResultsLive.com

Now that there is no coolrunning where we can load our team results, clydesdale/filly results, series results, or other supplemental files, we need to be sure to include them in our iResults Connector setups or else they won't be available online anywhere. So don't forget this critical step when setting up for your race.

Check for Winners by Net Time

One of Yankee's races had an embarrasing issue recently when their results on iresultslive.com showed the incorrect winner of the race. This is because the results on that site were sorted by net time, and the second place runner actually beat the winner of the race when their net times were considered. It's always important that the top one, or two, or three (whatever this race uses for its top awards) finishers - both male and female - are in the same order by gun and by net time. Taking a look at the results on iresultslive.com can often clue you in that there is a problem, but also comparing your PRELIM or FINALRES files with your TOPTEN lists can tell you. If you do have a discrepancy the best solution is to change the start time of the person who was given an advantage so that it matches the start time of the person who actually beat them to the line. It's kind of a clumsy way to do it, and cheats the runner out of an accurate net time, but it is better than having the gun and net order of the top winners be different. I had one race a few years back where one guy started way in the back of the pack because he was late to the line and managed to pass everyone except the overall winner, coming in second. His net time gave him the win, so I changed his start time to make sure that he ended up second by net time as well.

Sex Checks

One thing we have always done when setting up the race files prior to the race is to run the SEXCHK listing file to see if there are any male Marys or female Steves or the like. But I'm of the mind that we shouldn't do this any more, for two reasons. One, it has always been a bit dicey because some names that you'd think were obviously either male or female just aren't. The classic case was a woman named George that we used to run into. The second reason is that nowadays with gender identies being more fluid you might have a runner who is in the process of changing their gender identity to one that is different from what their name would suggest. Another thing to think about is that it isn't wise to fill in a gender when it is left blank. A Trans person might have left it blank deliberately, because neither male nor female works for them. So going forward, just take whatever gender comes with the database and if you need to make changes to the results later on, so be it. But do make a list of the most likely errors, including blank genders, and send them to the race director to see if they might be able to determine what is correct. They can ask the runner directly at registration.

Form Feeds

If you have a FORM FEED command at the end of a listing file you can safely delete those. They are a holdover from the days of dot matrix printers and aren't used any more. They don't hurt anything if you leave them there, but can be safely deleted. This does not apply to the CONDITIONAL FF command, which is still used. Or to a FORM FEED command that is in the middle of an @ results file where you want to make sure that the results that follow come out on a separate page.

Backing Up Your Runscore Data

At races when you are typing new data into Runscore you should be continually backing up that data to a flash drive. If your computer were to crash you would not want to have to retype all of that data. If you have it on the flash drive you'll be all set to go to your backup computer and resume where you left off. Most of you are already doing this but just in case, here is how it is done:

First bring a flash drive to all your races. Note which drive it takes up when you insert it, usually it's either e: or f:. Now in Runscore go into Tools > Preferences and in the top right of that screen you'll see two lines:

Alternate folder to save results

and

Alternate folder to save entries

In both of them put the drive letter for your flash drive followed by a colon, for example, e:

Down a little further you'll see a box that says "Minutes for Auto Save". Set that to 10.

With those settings Runscore will auto save all your entries and results to the flash drive every ten minutes. While in Results if you hit F10 it will save them right then and there, but more importantly, when you are entering names if you save with F11 instead of the usual F10 it will save a copy of the database to both the computer and the flash drive. This way if you computer should suddenly blue screen and crash on you in the middle of the race after you've typed in a hundred entries or so you won't have lost everything. You can get out your backup computer, put in the flash drive, copy over the .dta file from the flash drive to the new computer, and you're back in business.

Another way this can be used is when you're working with an announcer that uses Runscore, such as those from Announcers on the Run, like Andy Schachat or Steve Moland, They'll give you a flash drive for the database. Just use that as your backup flash drive and change the "Alternate folder to save entries" line to whatever that flash drive's letter is. Save all entries with F11 and when you're done typing entries just hand the announcer the flash drive and they have what they need. After that remember to change "Alternate folder to save entries" back to your own flash drive.

Common Start/Finish Lines and SimpleClient

Here's a nifty way to deal with a common start finish line. In your START SimpleClient session, you'll have a minimum accepted time of zero as usual, but then go over and fill in a maximum accepted time of whatever is likely to be the fastest possible finish time. Err on the side of a really fast finish, such as 14 minutes for a 5k, so that you don't get surprised and have to redo it with a different time if the first runner is really fast. This way you can leave the start open for really late stragglers and not have to worry about forgetting to turn it off and finishers coming in and wiping out their earlier start times.

Then when you open the finish session, use a minimum accepted time that is the same as the maximum time in the start session. You'll have to delete the max time that is carried over. This way you don't have to hit markers or anything on the orange box. When that min/max time comes it's like the box just rolls over from being a start to being a finish.

Announcer Line tips

One way that your announcer line can fail is if it has been recording runners prior to the race and those times are still in the system. You might think that a simple Zero Count after the start would erase all the times but in this case it does not. SimpleClient may still feel that it has 'seen' them before and not present them again when they finish. There are two ways to avoid this:
1) Don't plug in the antenna cables from the mats or flashpoints until after everyone has started and is far away from the mats. If you use this method, just be sure you remember to plug them back in before the first finisher!
2) Make sure the orange box is synced to the same time as your finish system, and then use a minimum accepted time in SimpleClient that will ignore any reads until shortly before the first runner arrives.
The only way you really get into trouble is if you leave them plugged in, with no minimum accepted time, and SimpleClient open and running the entire time. Zero counts won't help.

If you have enough computers, always try and provide two computers for the announcer. One should run SimpleClient connected to the mats/flashpoint, while the other can be set to the announcer screen in Runscore. This way if a runner's chip isn't read the announcer can type in their number and get what they need.

In smaller races (less than a thousand runners) it is perfectly acceptable to just use a flashpoint for your announcer line, with no gators. One advantage to this is that the runners won't confuse the announcer mats with the finish mats and stop running too soon. Just keep in mind that a flashpoint won't effectively read as far as a full 7 or 8-gator wide system, so if you have a very wide announcer line you should use mats. If you have a corner just before the finish line put the flashpoint on the inside of the curve and you'll get most everyone since most people will be hugging that side of the road.

Printing Results Files to PDF

Sometimes you need to send a results file to a race director that they will need to then print out on their own printer. If you send them the standard txt file saved out of Runscore, the lines are likely to word-wrap badly making the results look awful. The solution to this is to print them to PDF and send the PDF file to the race director to be printed. Most Windows computers come with a standard PDF printer that is installed like it was a real, physical printer on your computer. So when you go to print choose that PDF printer instead of your physical one and then save the resulting PDF file to your computer. One caveat: Your Runscore preferences must have the "Printer dialog box" box checked or else Runscore won't give you the option of printing it to a PDF printer and will just print directly to your default printer.

Time Machine glitch

Sometimes, for some unknown reason, a Time Machine, when used in a manual race and connected to your computer through the Serial to USB hub, can send a whole bunch of extra times into Runscore. We haven't seen any rhyme or reason as to why it might be doing this, but you should be aware that this can happen, so that if you find a dozen or more extra times in your event you'll know why and can feel comfortable deleting them.

Wrong Date in Orange Box

We all know that when we're syncing our boxes we are supposed to check first to make sure that the date in the box is correct. But sometimes we forget, and it may be on a time when the date was wrong. When you try to bring those times into SimpleClient you'll have a real mess with times that are either very high, or even crazy negative numbers. That's often an indication that the date was wrong. Don't panic if this happens. There's a simple solution. Check to see what the date actually is on the orange box, then use that date in SimpleClient instead of today's date - in both places, minimum accepted time and time shift. That way the calculations will be correct. After the race fix the date on the box for next time, and make a big note on that box stating that the date was wrong the last time it was used. If the date gets off again it means that box needs to be sent in for repair asap, so get it back to Bill so that can happen.

Too Big an ADDSUB

When you do your ADDSUB offset after the first runners finish it shouldn't be more than a small fraction of a second, but all too often it is. Sometimes it's even more than a full second. If you use such a large offset your net times will be off by that amount, since the net times are calculated by subtracting event START from event TIME, without factoring in the ADDSUB. The gun times, on the other hand, are calculated by subtracting the ADDSUB from event time, so they will be correct. Too large an ADDSUB will give you situations where the leaders of the race, who were right on the line and off with the gun, will show a net time that is faster than their gun time by a second or two, which makes no sense if you think about it. The way to avoid this is to reload your times through SimpleClient by adjusting the time shift so that the ADDSUB is factored directly into the SimpleClient shift. When you do that you won't need to use an ADDSUB at all and both the net and gun times will be precise. To do this you need to shut down SimpleClient, delete the existing times in Runscore, then put in the new time shift in SimpleClient and restart it. When calculating how to change the time shift you do the opposite of what you were going to do with your ADDSUB. So if with the ADDSUB you were going to subtract 1.53 seconds, you should ADD 1.53 seconds to the gun time you enter in SimpleClient. It's hard to do this at times becuase it can take a minute or so at a time when you're in a rush to get your times going, but in the end it's worth taking the minute to do it as the results will be a lot cleaner.

Dropbox on iPhones

If you download the dropbox app to your iPhone (not sure whether it's available for Android or not) and log into it using the GSRS account credentials, you will have access to all of our company dropbox files right there on your phone. Why is this helpful? Because you have immediate access to all of the Race Notes and all of the instruction files that are kept there.

Invalidated Tags

This happens often enough that you should all be ready and know what to do. Please familiarize yourself with the "Invalidated Tags" Word document in dropbox/ChronoTrack Instructions so that when (not if) it happens to you, you'll be able to fix it quickly without any problem.

Putting Runners Into Results Based on Their Info

Sometimes you'll have a runner come up to you who isn't in the results, and you have no backup information anywhere to give you evidence that they even finished the race. While it's important to make runners happy, we have to be careful here. If you take their word for it and use the time they say was on their watch, or what they 'think' their time was, you must be certain that doing so won't make them an award winner. So enter their time and then run all the awards listings that might pertain to them - run team results if they are on a team, etc. If their time makes them - or their team - an award winner when it wouldn't have otherwise, you should run this by the race director to see what they want to do. The RD is the ultimate decision-maker in this situation. Now he or she may be undecided and ask you for your advice, which leaves you with a difficult decision. There is no single answer I can give you here. You have to look at all the evidence, judge the credibility of the runner, the reliability of the equipment, and go with your gut. Maybe the runner had folded their number and the chip was damaged. This would easily explain why they weren't in the results. But maybe they have no good idea of what their time really was, and it was their fault for damaging their chip so you might want to leave them out. There are any number of possible scenarios here. Ultimately you don't want to deny a runner their rightful award, but you also don't want to unjustly take away someone else's award. If you just can't seem to decide which is the best course, my recommendation is to make the person who is right in front of you happy, then hope you got it right!
---- Side note. This is why having photos of all the finishers can be SO helpful!

Old Race Files

Old race files are kept in dropbox for two or three years. After that they are deleted (to save space in dropbox) and archived on Google Drive. If you would like access to these let Bill know.

Don't Neglect Your Backup Computer

Everyone should be bringing a backup computer to your races, that goes without saying. But when was the last time you scored a race with it? It's a good idea to use your backup every now and again to make sure it's up to snuff. You don't want to find out that it has problems in the middle of a situation where your primary has died on you. Better to find out when you still have the primary available. If you have a really crappy backup computer let Bill know and he'll get you a better one. I want everyone to have good, reliable equipment!

Scrambled Databases

One of the worst things that can happen to you during a race is to discover - usually after the runners start finishing - that you have a scrambled database. At some point in the process the race director resorted the data AFTER sending it to you, so none of the bib numbers match up with the correct person. Your results, as a consequence, are now garbage. But it's up to you to fix the problem, so what do you do? Well first of all you need to get your hands on a correct copy of the database. Go to the race director and explain the situation and let them know that you need to get a copy of the database that they used for their registration table. In the best case scenario you will be able to get that quickly and will be able to solve the problem right away. (More on how to do so later.) If you can't get a copy of the correct database for some reason, grab their paper registration lists, which will have the correct names and bib numbers. If for some odd reason you have neither option open to you the only choice will be to have all of the runners come to you and give you their names and bib numbers. Each of these three solutions will take time to fix, but the second, and especially the third choice, can be very time consuming. One thing you can do in the meantime to get some results up for the runners is to print your results without any personally identifying information - just bib numbers with times. That way they can at least find their time by locating their bib number.

Fixing the problem: With a correct copy of the database in hand you should be able to simply upload it to Runscore and overwrite the bad data. Take the file and prepare it by naming the columns to match what you have in Runscore, deleting any columns of information you don't need, and saving it as a csv file. In Runscore go to File > Import Replace and locate that file to import it into Runscore, replacing the old data with the new. If you just use File > Import (instead of Import Replace) it will add everyone to the end of the database and you'll have a bunch of duplicates. Ideally this Import Replace process should completely solve your problem. Keep in mind that if you had made any manual changes to anyone's data you'll need to redo those.

If you have no database file and have to use paper registration sheets, it will take a lot longer, but is still doable. First export your runner database out of Runscore using the File > Export process. Open that file in Excel, and delete all of the bib numbers for your PRE-REGISTERED runners. Remember, the entries you added on race day will be correct, so you want to leave those intact. Once the pre-registered runner numbers are all deleted you can take your paper registration sheets and locate each person and retype the correct bib number into Excel. After you've fixed everyone's number, save the file and Import Replace it into Runscore using the method above.

If you find yourself with no data file or paper sheets and have to resort to getting the information directly from runners you can give up any idea of being able to provide complete and accurate results on race day. Their awards ceremony will have to consist of awards only to the top runners, who can be identified by bib number. One problem with this method is that a lot of runners will leave without giving you their correct bib number so you're going to end up with a lot of unknown runners in the results. Because of this, be sure that announcements are made quickly and frequently asking runners to come to the timer before they leave. The process for fixing this is similar to the one above where you export the file from Runscore to Excel, blank the appropriate bib numbers, and then just type the new ones in as you get them.

If in either of these last two process where you have to export to Excel, you end up with entries that have no numbers, you'll have some unknown runners in your data. It's very important in this case to delete all of your existing times from Runscore and reimport them. Times in Runscore are digitally tied to the record number for that bib in the database, so if you suddenly are missing a bunch of bib numbers it will be a mess if you don't reload everything. Reloading will create a bunch of blank entries. Run the UNKNMAKE listing file to fill in the term "Unknown Runner" in their record and then you'll be able to print your results. Hopefully over time many of those unknowns will come forward.

One last thought about this situation. To the runners this may look like a collossal failure of the timing unless the race director owns up to the fact that it was their fault that they gave you the incorrect data. While you don't want to come right out and demand that the RD owns up to the problem, don't hesitate to speak out - diplomatically - if they are actively blaming GSRS. Or course it goes without saying that if YOU are the one who scrambled the database you'll need to own up to it. This will not be a happy situation for you, so all the more reason to be extra careful when working with pre-race database files that you don't do any sorting without being SUPER careful!

USATF Rulebook

Thank you all for taking the time to read through all this verbiage. If you are ever in the mood for more race-related reading, I recommend taking a look at the USATF rule book, which can be found online here: https://www.usatf.org/governance/rule-books. I do not recommend reading the entire thing (unless you're having trouble falling asleep some night), but take a look at rules 128 and 165, as those apply most directly to what we do.