1.6.6.0 Update

[Philip Cogavin]

Possible bug in latest update.

I updated to 1.6.6.0 and experienced a lot of missed reads.

WIndows 11 - Zebra 9500 8 port - 3 antenna - ground mat - Race 5 of a 6 race series.

Race set up as per 4 previous races.

3000m handicap with chip start calture and chip finish capture

Pervious 4 races had maximum of 1 to 2 chip read misses.

Race 4 - missed complete laps of reads. The first chip reads instead of being chip starts were after 1st lap but set as chip start. No athlete registered start and 3 laps.

76 athletes with individual start times

Some athletes only has 1 lap register, other 2 laps registered.

Green icon was flashing as athletes passed through finish/lap - recent tag reads seemed to be getting them as they passed - just not registered in the software.

I've reverted to 1.6.5 version for next week. Fingers-crossed.

Thanks,

Philip

[Brian Agee]

I have not seen this in any of my tests and no one else has reported any issues so far, so I have to start with the basic questions just to rule them out.

Do you remember if the Race Clock (not the activity indicator) Red, Yellow, Green, or flashing between Yellow and Green when those chips passed by when it was supposed to register their laps?

If you want me to test the system with your exact race setup then please send me your database file and I'll program tags to match the bib #s assigned. If you can send me your "Tag Read" file then I can also follow in your exact footsteps and start the race and toggle between capturing chip stats and capturing finishes.

[Brian Agee]

I found and fixed the issue and an update is out on the website now.

This bug was isolated only to the scenario Philip described, where you're capturing chip starts AND chip finishes at the same time.

For the fellow nerds that want to know more on what happened:

• I restructured the code that handles the auto-finish gap and in one line of code I forgot that the key of a HashTable was expecting a "String" value as the key, however I was passing in the bib # as an integer. So if HashTable had a key of "100" and I attempted to get the value in the HashTable by passing in the number 100 as the key, it would not return any results and the software assumed each tag read was the first time that participant was seen at the start. So the solution was a very simple casting of the bib # to a string value (like it's done in all other areas of the code where I access the ChipStartTimes hashtable).

Thanks Philip for letting me know about the issue and I'm sorry for any extra work or headaches it caused...

[Philip Cogavin]

Thanks for the prompt attention, Brian.

I'll use the updated version at next week's race and see how I get on.

It's a great piece of software.

Thanks,

Philip

[Steve Hudson]

I think there may be an outstanding problem alongside the same lines : Live Export file gets updated with tag reads but not always to the Tag file. Chip Starts get sent to both files fine. Database, Live Export and Tag files sent.

[Steve Hudson]

Update 1.6.6.2 performs well, TAG data file updated, thanks Brian

[Steve Hudson]

Back to testing 1.6.6.2 update…sorry, Brian, I’m back to getting inconsistent TAG read entries. 4 days ago a single test worked fine, today I cannot get complete TAG sets of reads.

I tested many times. Incidentally, in doing so, even though I Finished and Reset, I had to exit ART before going onto the next test. It was as though ART still had stuff in memory ?!

Back to 1.6.4.1, sorry.