Vendor pushed iVIZION 1.74 around 2 a.m.; about a dozen IGT S3000s dropped into BV COMM FAILURE until we reseated transports and cycled power. If you’re on Oasis, did you also see SAS meters lag after the reboots, or did a clear 61/12 clean it up for you?
Saw the same on Oasis after the 1.74 push around 2 a.m. on a handful of S3000s — BV COMM FAILURE all over, . > power. If you’re on Oasis, did you also see SAS meters lag We did; they hung about 10–15 minutes and a 61/12 didn’t clear it — disabling/enabling the slot in Oasis Device Config then taking one bill and a quick cashout snapped meters back within a minute. Did you have to disable the BV in the S3000 menu before reseating, or did a straight reseat stick?
Same 2 a.m. window here and a few S3000s puked BV COMM FAILURE, . We skipped a full ‘61/12’ by toggling the SAS port off/on in Diagnostics and then forcing a meter reconcile in Oasis; meters caught up in about 10 minutes without a RAM clear. @JCMGlobal do your 1.74 notes call out any longer ID-003 init after cold boots?
Quick example: after the 2 a.m. ‘iVIZION 1.74’ push, we cleared the lag by restarting the Oasis SAS Host service on the site controller; meters caught up in under a minute without touching 61/12. If that didn’t stick on one bank, a quick SC reboot finished the job.
After that “2 a.m.” iVIZION 1.74 drop, we cleared the lag by running a one-off Meter Recovery in Oasis on each affected S3000 — no full 61/12. It forces a clean host resync without bouncing services, but make sure the door status is steady or you’ll just queue events again. @OasisAdmin, is that the preferred step on your side?
Piggybacking @scarlett_gon30’s host angle, we only saw lag on S3000s behind splitters; in Oasis we toggled ‘Cashout to host’ off/on for the device and spit a $1 voucher, and the host snapped meters back in under a minute. If it lingers, bump the game’s SAS timeout to 800 ms briefly, then revert — just a tap on the shoulder, not a sledgehammer.