|
JCapper Message Board General Discussion
|
| Home |
Register
Log In |
| By | Sat Aug 18 2012 - Woodbine R4 | |
| jeff 8/18/2012 5:16:40 PM | Sitting in my inbox are no fewer than 4 emails just like this one: --quote: "Jeff, Sat Aug 18 2012 - Woodbine R4 - the winner, the 12 didn't even make it to the past performances...what happened?"--end quote And over at paceadvantage.com, we have this thread titled Twinspires screwup again: http://www.paceadvantage.com/forum/showthread.php?t=96959 So what happened? First, here's link to a screenshot of the xml itself: -click here - screenshot of xml for race winner scratched from the xml- Piecing things together, here's what I see: 1. Horse (erroneously) listed by either Woodbine or Equibase Chart Caller in the Scratches and Changes XML as a scratch - timestamp: 12:30 hrs (12:30 pm eastern.) 2. Horse (correctly) unscratched (most likely by the chart caller) from the xml - timestamp: 14:46 hrs (2:46 pm eastern.) The chart at Equibase.com shows race off time at 2:41 pm eastern. An educated guess about the chain of events... • 12:30 pm eastern - Someone in the Woodbine racing office keys the horse in as a scratch (in error.) • 12:30 pm to race off at 2:41 pm eastern - Horse is incorrectly listed as a scratch. Bettors, ADWs, and even brick and mortar tracks and otbs relying on the xml are caught unaware. • 2:42-2:43 pm (a few seconds give or take) - the "scratched" horse wins the race, paying $7.80 to win. • 2:46 pm - Chart caller (5 minutes after race off) while in the act of cutting the official chart notices horse is (somehow) scratched from the EnCompass system. He can't cut the chart with the horse scratched. So he "unscratches" it and cuts the chart. You guys may not be aware of this, but for the past several weeks I have been actively campaigning the higher ups at Equibase to add a tote parse routine to the scratches and changes system. My belief is that the one missing piece from a quality control standpoint needed by the scratches and changes xml system would be to add a tote parse routine - followed by timely handling of any differences between scratches gleaned from the xml and scratches gleaned from the tote system. Had that been in place, there was a 2 hour window today where the chart caller at Woodbine could have been alerted - the horse could have been "unscratched" - and this whole mess could have been avoided... And messes just like it that are sure to keep happening on a regular basis going forward could be avoided. As human beings, none of us are perfect and all of us will make our share of mistakes. The xml is only as good as the people making the entries and the internal controls in place to catch mistakes before they become problems. Historically, the entries in the scratches and changes xml is running at better than 98.5% accuracy. However, a typical Saturday this time of year will likely see about 300 horses listed as scratched in the xml. (Do the math.) Obviously, when a scratched horse wins a race it's a big problem. Below is a cut and paste of an email that I sent to the brass at Equibase earlier today: --quote: "Every Saturday there's at least one example that just screams out the need for parsing the tote and (quickly) handling differences between the xml and the tote.--end quote You guys should also know that I will be meeting with Equibase CEO Hank Zeitlin next week - and yes, among other things, I WILL continue to push to have a tote parse routine added to the scratches and changes xml system because I see it as a much needed item from a quality control standpoint. In my opinion, when you are talking about player's money 98.5% accuracy isn't good enough. There's no reason the xml can't be brought close to 99.9% accurate. -jp .
| |
| jeff 8/20/2012 6:14:30 PM | Equibase contacted me earlier today to tell me they agree with me that parsing the tote and (quickly) reconciling exceptions between the xml and live runners in the tote can bring scratches in the xml right up to near 100% accuracy. They also emphasized that near 100% accuracy for the scratches in the xml is one of their primary objectives. They've decided to act and move forward implementing my suggestion. It'll take their contract programmers a few weeks to get the work done - but after completion of work, the chances of an incident like the one from this past weekend repeating itself should (literally) become zero overnight. Equibase is stepping up in a big way here. Instead of ducking problems like everyone else in this industry, they are LISTENING to players and TAKING ACTION to fix something that needs to be addressed. Personally, I find that refreshing. On behalf of players everywhere I want to tell Equibase: THANK YOU! -jp .
|
| Reply |
|
Copyright © 2018 JCapper Software back to the JCapper Message Board www.JCapper.com |