Volumio Version: 2.779
Hardware: Pi 3B+
DAC: Allo BOSS
http://logs.volumio.org/volumio/yG3hnE3.html
Can you confirm the problem does not occur with touch display plugin disabled?
If I spotted correctly from the log your display is not an original Raspberry 7" touchscreen and you have the display rotated by 180°.
If that is correct try setting the rotation 0° and report back if the issues persists. I think I have discovered a bug regarding the rotation by 180° though not sure that this is really the cause. I am not in front of my Volumio system so can’t do a test but will do asap.
Thank you for the quick reply.
Can you confirm the problem does not occur with touch display plugin disabled?
Yes. Not only that, but the Web UI works perfectly under every tested condition. The issue of switching among multiroom doesn’t occur with or without the display on if using the Web UI.
Correct - not official Pi screen, but:
Also, it looks like one other user had this in a previous version. See VOLUMIO 2.348 MULTIROOM SWITCHING VIA WEBINTERFACE (reply by ed733).
It appears to me that the browser kiosk on the touch screen reloads quickly when you switch to another multiroom device (as does the web UI) but the reload progress bar at the top of the screen moves much more slowly, and never finishes – the bar gets stuck near 100% – when you try to switch back to the home device on the touchscreen - the screen darkens and the spinner appears - it behaves as though a connection has been lost although the Volumio is still reachable via the web.
Again, many thanks for looking into this.
I can confirm the issue. I tested on a Pi 4 with a Raspberry original 7" touchscreen running Volumio 2.779 and a second Volumio system in a virtual machine (x86).
Other than on Raspberry systems Volumio for x86 does not need a display plugin but a similar function already built in. Volumio x86 shows the same behaviour you described so it is not specific to the Touch Display plugin for Raspberries. In principle the plugin as well as the built in display function on x86 systems just run a local web browser in kiosk mode and display the same content as is shown in a browser on another device.
Unfortunately I don’t know much about how the multiroom option works and what happens server side when switching between rooms. As I can’t see a related error in the logs I have no idea how to resolve the problem ATM, sorry.
The same or at least similar issued has also been reported here, here and here.
For the time being you can also reload website hitting F5 if you can connect a physical keyboard to your device instead of restarting the plugin from another device.
Thanks for the testing legwork. Some of the threads you linked suggested @volumio has fixed this issue before, so maybe it just broke again with recent updates.
On GitHub I saw a “partial fix of multiroom selector” as of 12 Dec 2016, but some of the reports have been after the fix.
I have tried in vain to figure out how to configure the chromium kiosk to enable a pull-to-refresh gesture, which would be a very modest hack. You can swipe forward and back for pages but a pull to refresh might solve the problem.
Yes, chromium flag --pull-to-refresh has no effect. But even if it did, it would be more of a workaround. Better if no action would be required. 
By chance I discovered I still have version 2.522 (x86) of Volumio in a VM. @volumio In 2.522 the issue is not present. So I suspect something might have gotten lost/changed on the journey to 2.779.
Sadly several hours later the same issue occurred on 2.522, too. I decided to update the VM to 2.779 including a reboot of the system - now switching back and forth between two rooms on 2.779 works, but I guess as with 2.522 it will be a matter of time or maybe amount of data before the issue returns again 
.
Any chance that the IP address of your VM changed, and that’s what broke Multiroom? It might explain the facts you describe.
I’ve been haunted by this thought of yours:
I have been poring through /volumio/app/plugins/system_controller/volumiodiscovery/index.js, which is the file that was edited in this fix:
and while I have nowhere near the JS chops to figure it out, that piece seems to rely at least to some extent on IP addresses for multiroom function
When using the Web UI, the displayed multiroom devices will all have different hosts from the web client looking at them. But the touchscreen/internal UI may be a special case.
When your local device is displaying its own interface, it’s just looking at itself, but it may not be looking, as far as a superficial search of index.js reveals, at 127.0.0.1, even though other parts of the project refer to 127.0.0.1 for local content. If localhost changes IPs, I could see multiroom on the device not handling this special case well, and looking for something that’s no longer there, explaining the jump to the twilight zone.
I admit this hypothesis could be 100% wrong.
No, but worth asking
I had similar thoughts like you regarding an IP address issue… but I am lacking knowledge on how multiroom works in detail.