First, would not worry about this 'reliability' rating. Even when I run a buffer of 2 days continuously do my clients get rush jobs, if that's the objective. This 'reliability' has no meaning whatsoever for getting Beta work, other than till you've worked through the queue, will the client not request work of any kind. Why would you want to beta only on reliable clients? WCG when testing wants to have results coming off any type of PC. The faster return is anyway forced off with a shorter deadline.

Now, if your settings were to have a short queue, you don't give us anything to get a full picture such as which project these are for, and suddenly you have 8, it could be your machine had a brief period of quicker returns. The server could have been confused too and thought you suddenly had a quad server... there were serious issues after the patching, so I would not worry too much about it.

No extra work buffer it showing as 0.00 in the local prefs screen? Default is like 0.2 or 0.3 days.

What projected completion time for these rice? Should be ~7 hours. I've had jobs showing 4x but also 0.25x the true time when the mean times were in great state of flux.

Empty? At least it should show 0.00. Presume you set the website device profile 'cache' value to 0.00 too.

Looks though as if your rDCF or active_frac values have been hit by a windmill. 61 hours will definitely freeze work fetch. You could suspend all none-started rice jobs, then suspend the currently active task to push the DDDT ahead. That will speed up the correction of control values, short of a project reset ;>)

still, nothing to worry... it will sort itself out by no later the end of the last task.