I've also noticed some of results being returned a few hours late by one of my machines, but still validating nicely with credit, and without incident.

Is this a side effect of the not resending work units?

Indeed. If possible I would not accept Rice units but nasher describes the problem accurately.

Set your profile for one of the other projects, grab enough WUs to keep your computer occupied for a bit. Then set the profile back to DDDT2 only and increase the cache so your client will keep checking in for DDDT2 jobs. You can repeat this when your cache runs dry.
Its a bit of a chore, but this way you can control what your client is running while waiting for the project you really want.

My last rice was batch 00587 completed yesterday kicking me 6 hours 7 minutes over 2 years [2:000:06:07:00], meaning there are still about 30 whole batches, last one being 00627, still doing about 0.2% per day or 10 batches per week. Till 00617-00620 or higher is seen there's no need at all to kick the safeties in i.e. standard cache of 0.3 days and controlling all devices from a single 'Rice' profile. A quick count what's marked as In Progress on the Result Status page plus what's in PV giving a quite accurate tally of how much there is already committed to get you to target, on or over. The progress chart in top post. Uplinger will warn when there are the last in the queue though no guarantee as he wrote a week or longer ago to have loaded all work in the system ready to be pushed into the feeder.

The latest batch I've recieved is 591. If the figure of 10 batches per week is still accurate, that means we still have 3+ weeks to go.

Steve