Closed kimlongcr closed 5 days ago
@kimlongcr I was not able to reproduce this problem (see recording below).
In v1 of check-in, each kiosk would constantly ask the server to see if there were any changes by making an API request. This was very costly and had to be done frequently (by default I think it was 10 seconds). Times that by dozens of kiosks and it was a huge load on the server. Especially since these changes were very rare and infrequent compared to the 8,640 times per day the kiosk would ask if anything changed.
In next-gen check-in this has shifted. It uses the "real-time" system built into Rock so that the Rock server. This means that the kiosk no longer asks the server if anything changed. Instead when the Rock server detects a change that could affect check-in (such as a named schedule being edited) it will send a notice to all connected kiosks that directs them to refresh their status.
As you can see in the recording below, this is nearly instantaneous and how it is supposed to work. There is a single edge case where this won't be instant. In order for this "real-time" system to work, the kiosk keeps a connection open to your server. If that connection is broken (such as restarting the Rock server) then it won't hear about any real-time changes. If it is already on the welcome screen it will wait for 10 minutes before performing that reload - this is to give Rock a chance to fully restart before it tries to reconnect. If it isn't on the welcome screen then it waits until it returns to the welcome screen to reload the page.
All that to say, it's possible the kiosk was in this "waiting for the server to restart" state. Please verify that isn't the case and see if you are still having the problem. The easiest way to do this is to manually reload the kiosk page before making the changes to the schedule. If you are still having the problem, please try including a screenshot of the JavaScript error console and a recording of both the kiosk and the window in which you are making changes so we can attempt to diagnose further.
@cabal95 Finally had a chance to come into the office and try it on an ipad with the app installed. Works great. Closing.
@kimlongcr Thanks for verifying!
Description
The kiosk says "Kiosk Closed for Today". When the schedule is fixed, the kiosk is not auto refreshing to show Start on it and allow people to start checking in. I just tried this in 16.6 and it refreshed the kiosk page within seconds.
Actual Behavior
The kiosk says "Kiosk Closed for Today". Staff is freaking out because checkin should be starting soon and there should be a countdown happening. They realize that the schedule must not be setup correctly. They go correct the schedule to start now. The kiosk is not auto refreshing to show that there is an available schedule and changing to display the start screen. I waited over 2 minutes. I had to do a manual refresh on the page.
Expected Behavior
It refreshes the kiosk pages to the new status of the schedule - whether that is a countdown to the next schedule, they can start checking in now or we closed the kiosk for the day. None of these are refreshing to display the updated schedule status.
Steps to Reproduce
Issue Confirmation
Rock Version
Rock McKinley 16.7 (1.16.7.2)
Client Culture Setting
en-US