When reporting events, be sure to give us the event name and the event ID, so we can find your event. (Pending events have a combination of numbers and letters for the event ID, because the event ending date may not be final yet. Rated events will continue to have 12 digit IDs as before.)
There are at present 87 events on the pending events screen that staff see, which probably includes some test events by both staff and TDs and some that may have been re-uploaded or otherwise abandoned. (Figuring out how to garbage collect the pending events page will be a task we need to work on soon.)
I have never seen an event show up on the pending page for me, only on rated or on all. Even the ones that were in the process of submission, such as the one I had ready for the payment system to come online, have not shown up as pending.
Well, it’s 11:00 and I’m ready for bed. An interesting first day. I probably filed over a dozen issue tickets, a few of which have already been dealt with. If you sent something to ratings-support@uschess.org and didn’t get a response today, you should get one tomorrow.
There have been, predictably, a few glitches. Things that I thought were working seem to be working only some of the time. Some of the requests I’ve made for features that staff need to administer the system and deal with TDs or members reporting issues are now becoming more obvious to the developers why I asked for them.
It looks like there’s an issue with getting new members reported to the MUIR system from the membership system; renewals seem to be working better in terms of polling the membership system for an update. Could be some data flow issues between CIVI-CRM and MUIR that aren’t 100% yet.
We saw some signs of system slowdown this evening, one TD reported that the ‘add new player’ button was taking longer and longer to respond each time he clicked on it. One of the staff displays seems somewhat stuck, too, and I don’t know what’s going on with the Grand Prix data. BTW, the “84%” refers to the percentage of the Grand Prix year that is complete, not anything to do with system performance, fooled me too.
There seems to be some issues with the rating calculations on MUIR.
In the above event, for instance, the second placed player’s rating was changed from 1914 to 1932, but his posted rating is 2008, and he has a floor of 2000 because he is a National Master. The player who took first had a rating change from 2132 to 2141, but his pre-event rating was 2133. I have not checked the other players’ profiles but I suspect this issue may not be isolated.
Any chance the Leago team is planning to scale up the compute for the new site? I’m noticing a lot of slowness (and it seems like others are too). Is there auto scaling in place?
Dealing with the slowdowns we saw yesterday is a high priority task this week. They might have to shut MUIR down briefly to bring it up in a larger configuration model, I”m not sure how Azure handles that, I know on Amazon reconfiguring a server requires a shutdown/restart.
Sorry if this has already been addressed. Are the Section TDs being imported from DBF files not working at the moment? I’m noticing they aren’t getting pulled in. In my specific situation the tournament and section TDs are the same (not sure if that makes a difference)
Also, thank you for all the work you are doing for this transition. You are handling a lot of inquiries and doing a great job keeping everyone here informed.
I think there were some import issues. They have the ability to re-process an import to clean it up, we need to come up with a full list of what fields got skipped and re-do a lot of events.
I’m more familiar with the Amazon system than Azure, I’ll have to find out how autoscaling works on Azure, it may not be available at the resource tier we’re currently configured for.
The way MUIR is configured, each event has an alphanumeric primary key. The 12 digit numeric event ID we’re used to is not generated until the event is rated, in part because sometimes the event dates get changed during the editing process, and the event ID is based on the latest section ending date.
The way MUIR is built, the 12 digit event ID is a secondary key that can be changed, but is still needed because it is part of the ordering for ratings sequencing. So if the latest section ending date is changed at any point (it happens), a new 12 digit numeric event ID is generated but the underlying alphanumeric key remains unchanged.
This actually makes more sense than the original data model, and is an example of how re-engineering the system makes some thing work better.
Thanks. The overall response from members and TDs to MUIR has been pretty positive. Yeah, there are a few glitches and some performance issues to fix, but things actually went pretty smoothly yesterday. I need to start digging in to what fields got overlooked in migration so they can be re-migrated. The legacy system will be available until we’re sure we no longer need it, my guess is that will be well into 2026, because there are still a few tasks, like correspondence ratings, that haven’t been implemented in MUIR yet. That was deliberate, correspondence ratings are enough different from OTB/Online events that it will take some tweaking to squeeze them in, but once we do the benefits for all members will be worth it.
FYI, I reported this last night, received a prompt reply, and while it did not work this morning, I just now got it to validate! The validation was very slow, but I can live with that for now! Thanks.
