Twinspires screw up again

[Copyroomjim]

Woodbine Race 4, Won by the 12 that Twinspires program page shows scratched.

wtf??

[wle]

Played the pick 3 in the 2nd,3rd,4th races. When I saw the 12 was scratched I replaced used the 7 and 4. Had the first 2 legs. Just emailed them. Not happy

[JustRalph]

Remind them of this thread. They never did answer me.

http://paceadvantage.com/forum/showthread.php?t=68739

[wle]

I did get a reply from twinspires. They blame Equibase, regardless. it should have been caught on their end.

Per twinspires
"I apologize for this. What happened was the horse was incorrectly scratched in Equibase which is where we pull our information. This caused it to show on the scratches list as a scratched horse. However this horse was not scratched in Tote which means it was still possible to wager on it. Once Equibase realized the mistake they corrected it though unfortunately this was not until after the race."

[Itamaraca]

I did get a reply from twinspires. They blame Equibase, regardless. it should have been caught on their end.

Per twinspires
"I apologize for this. What happened was the horse was incorrectly scratched in Equibase which is where we pull our information. This caused it to show on the scratches list as a scratched horse. However this horse was not scratched in Tote which means it was still possible to wager on it. Once Equibase realized the mistake they corrected it though unfortunately this was not until after the race."


No No No. this doesn't cut it. The 12 was SCRATCHED per TS' webpage (using the classic view, in my case). BUT the horse was not scratched per TS TV. They dropped the ball, big time.

[Jeff P]

I'm one of the HANA players who originally pitched the idea of a scratches and changes xml system to Equibase and I even helped them design the xml.

That said, I probably have a unique perspective on where things broke down today and will try to communicate that in the remainder of this post.

First, here's link to a screenshot of the xml itself:
http://www.jcapper.com/messageboard/avatars/woxr4_aug182012.jpg


Piecing things together, here's what I see:

1. Horse (erroneously) listed as a scratch in the xml either by someone in the Woodbine racing office or by the Equibase Chart Caller. Timestamp in the xml: 12:30 hrs (12:30 pm eastern.)

2. Horse (correctly) unscratched (most likely by the chart caller) from the xml. Timestamp in the xml: 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 time of race off - 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 in the EnCompass system. He can't cut the chart with the horse scratched. So he "unscratches" it and cuts the chart.
________________________________________

For those of you who may not be aware, over the past several weeks I've noticed a trend. Messes just like today's incident have been happening with greater and greater frequency (although today's incident was the first in some time where I have seen a horse mis-scratched in the xml turn out to be a race winner.)

As a result of what I have noticed in the xml, I have been actively campaigning Equibase to add a tote parse routine to the scratches and changes xml system.

I contend that from a quality control standpoint - the one missing piece in the scratches and changes xml system is the lack of a tote parse routine - followed by a timely reconciliation of differences between scratches listed in the xml and the live runners in the tote system.

Had that been in place, there was a 2 hour window today where the chart caller at Woodbine could have been notified - and the horse in question could have been "unscratched" - in essence, rendering today's mess avoidable.

Until something like a tote parse routine is implemented, and a reconciliation is performed between scratches in the xml against live runners in the tote - messes just like today's incident are certain to happen (over and over) again going forward.

Knowing the system as I do - and who is responsible for doing what - The one key missing piece (in my opinion) is to implement a tote parse routine and to reconcile the scratches in the xml against live runners in the tote system – and handle exceptions in a timely manner.

As human beings, none of us are perfect. ALL of us (myself included) are capable of making mistakes.

The xml is only as good as the people making the entries and the internal controls put in place to catch mistakes before they become problems.

Historically, the entries in the scratches and changes xml has been running at better than 98.5% accuracy. (I know this because I parse it daily and mis-scratched horses negatively impact my betting.)

A typical Saturday this time of year sees more than 300 horses listed as scratched in the xml. (Do the math.)

Obviously, when a scratched horse wins a race - and when entities like Twinspires are counting on the xml to be accurate - it's a big problem.

Below is a cut and paste of an email that I sent to the brass at Equibase earlier today:

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.

Saturday Aug 18, 2012

Woodbine R4

#12 Spring Venture

Won the race - Paid $7.80 $4.80 $5.00

Race off at: 14:41

Listed in the xml as scratched at: 12:30

Listed in the xml as unscratched at 14:46 (5 minutes after race off.)

Race winner incorrectly listed as a scratch in the xml the whole time. (Bettors relying on the xml caught unaware.)


Jeff Platt
President, HANA


________________________________________

I will be meeting with Equibase CEO Hank Zeitlin one day next week - and yes, among other things, I WILL emphasize how important it is that a tote parse routine be implemented into the scratches and changes xml system. 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 doesn’t cut it.

I see no reason that the scratches and changes xml system can't be brought extremely close to 100% accuracy after implementation of a tote parse routine followed by a timely handling of differences between scratched horses in the xml and live runners in the tote system.


Jeff Platt
President, HANA

.

[wle]

The 2 hour time window is what bothers me. Someone should have noticed in that time. The ball was dropped and the bettor pays for the error.

[Jeff P]

An update...

Earlier today, Equibase contacted me to say they have decided to move forward with implementing a tote parse routine along with timely handling of exceptions between scratches in the xml and live runners in the tote.

Their goal is to bring scratches in the xml as close to 100% accuracy as possible.

It will likely take them a few weeks to complete the work. But after they are done, the chances of another incident like the one in this thread should literally become zero overnight.

Equibase has stepped up in a huge way here.

Instead of doing nothing they are LISTENING to what players are telling them and ACTING to correct something that needs to be fixed. (Personally, I find that refreshing.)

On behalf of players everywhere, I want to tell Equibase:

THANK YOU!



Jeff Platt
President, HANA

http://www.horseplayersassociation.org

.

[OverlayHunter]

On behalf of players everywhere, I want to tell Equibase:

THANK YOU!

And on behalf of me, I want to thank you and HANA, Jeff.

[SpotPlays]

I second that