Support #395

Customer called regarding irratic scoring on the first few laps of races

Added by Walter Pate about 1 month ago. Updated 19 days ago.

Status:In ProgressStart date:09/17/2018
Priority:NormalDue date:
Assignee:Walter Pate% Done:

0%

Category:Race scoringSpent time:7.00 h
Target version:Customer needs to fix

Description

Oak lane reports issues with irratic behavior with scoring.
quote from a club members database:
"Walter,
We have had several weeks of issues running moscore. The core problem is counting down laps. After hitting green flag it will start counting 1 driver on their own lap and the rest of the pack as another resulting in 2 laps being counted down for every 1 real lap.

I updated the computer to windows 10 and don't see any hardware issues. I ran the computer during practice with one car and it worked perfectly. "
This email was followed up by a phone call from the clubs President who was at the track and wanted support.

8.25.18.mbk (3.3 MB) Walter Pate, 09/17/2018 01:01 AM

20180929.mbk (3.51 MB) Walter Pate, 10/01/2018 05:15 AM

9_29_18 PMLap recordingsfor transponder Hugh(2872401).JPG (137 KB) Walter Pate, 10/01/2018 05:47 AM

History

#1 Updated by Walter Pate about 1 month ago

I connected with the OCQMRC computer and did some diagnostic tests on their Moscore-QM.
Checking the Race Lap Times in the Results menu showed that the lap times /hits/and strengths appeared to be nominal.
There was an indication that in some races the first few laps appeared to have a duplication of laps.
Then I checked the Race Passings log on the race scoring page. Most appeared to be normal.
I could not find an obvious issue at this time!
Then I wanted to show Joe how the race passings worked so I created a race and was going to simulate transponder crossings. I noticed that before I provided any transponder crossings, the race passings table showed prepopulated passings and lap counts. Those passings would have been associated with an older race that may have had the same race number or event number that is registered to the current race.
Then I ran Tools/Archive\Repair/Repair All Tables and it showed there were no issues with the database. Events showed the oldest race was early 2017. When I chose show repair log it showed repair logs from 2003 to 2012.
Then I decided to reinstall Moscore-QM so did a backup, then I uninstalled Moscore(on the C drive) using the Windows uninstall app, then deleted directories for MOSCo, MySQL in varius file locations. then reinstalled Windows.
Next I reinstalled Moscore but was supprised that the database was still installed??
Checking the computer further I found that Windows was installed on both the C drive and D drive, and Moscore was installed on both drives as well. This would possibly provide conflicting data to the Moscore database.
We found that the current version of windows seemed to be installed on the D drive so I removed moscore related data on the C drive and renamed the Windows file on the C drive to Windowsold.
Then I installed ver 1.3.52 MoscoreQM on to the D drive and set up the Tranx and had issues with the Scoreboard initially. After Joe reset the Daktronics signal converter the scoreboard stated to work properly. It is possible that the Signal converter needed to be powercycled after installing Windows10
I discussed the issue with Jamie regarding the dual drive and Windows directories on both computers and he was unsure if that could have caused an issue even though I have experienced this phenomenon before.
I set up another connection with Joe to download a copy of their database for Jamie to test for Old data that was not archived and removed properly and could create the prepopulated data in a new race.

#2 Updated by Walter Pate about 1 month ago

I downloaded the OCQMRC database for jamie to analyze for corrupt data

#3 Updated by Walter Pate 19 days ago

  • File 20180929.mbk added
  • Status changed from New to In Progress
  • Target version changed from Future to Customer needs to fix

Ray Nettleship from OQMRC wrote
"Joe, Walter

The Sr Honda race last night seems to be the only problem as it never counted down any laps or recorded the transponder crossings. The race log shows the green was out and also shows crossings during the warm up. Hopefully Walter can see what may have happened.

Moscore was restarted and ran fine the rest of the evening so we definitely made progress with the work you did two weeks ago."

Attached database and the offending race is 9.29.18 race 6 Sr Honda A Main Event

#4 Updated by Walter Pate 19 days ago

I did look at the database as it was saved after the Race 6 Sr Honda a main event and found that the data that I was able to see at my level of analyzing the Moscore-QM program was not sufficient to come to a conclusion as to what happened. It seems that the race data for that race was not saved when the user restarted the program. in order to understand further what happened in this incident it would be best if the computer operator at the time of the race write a detailed report as to what was observed at the computer at the time of the incident.
I have forwarded a request to Jamie to try a tier 2 analysis on that particular race to see if he can extract any useful data thru an SQL query.

We did however find that in the JR novice races, the car 2 with HUGH (2872401) Transponder seemed to have a high signal emmision on the back straight as it was showing a pmhit(discarded passing) reading in the race passings column Please see the attached image I am curious about this as a JR novice should not be able to trigger on the back straight if the minimum lap time is set properly.

Moscore-QM appears to be working well based on all the data that we can see. We are awaiting the report from the OQMRC tower scorer

Also available in: Atom PDF