Turning Error Free mode off when its needed is far worse then suppressing one or two mostly inconsequential message boxes, because it can prevent playback from advancing on a headless system and require complicated manual user intervention. Hence we're rather cautious doing any such things.
Thanks for that insight. I understand your caution.
The request is for a way to
manage ErrorFreeMode so that it is on whenever needed, but then automatically turned off when not needed. For a headless system, it could be left on all the time. For a multitasking desktop PC as server with monitor and keyboard, ErrorFreeMode could be turned off when no remotes are connected so that the user is less likely to be surprised by disappearing message boxes.
Side Note: When PC clients Play from my server, the server's ErrorFreeMode remains off anyway (MC 28.0.42, true for both GUI and Panel on the client; I have no experience with other MCWS apps). So JRemote2 is an exception for me, though I do use it quite often.
Some possible solutions:
1) It seems simplest for remote connections to "clean up" before closing. That may be sufficient for one, but not robust for multiple simultaneous instances.
2) Server-based state tracking described in OP.
3) An ErrorFreeMode state toggle button under tools menu, so the user does not need to open a web browser. It could raise a warning if remotes are connected.
4) Matt's initial suggestion: Leave a subset of message boxes, which only appear during user initiated interactions (like library backup), unblocked all the time. However that might present a problem for some apps on headless servers.
5) Show a count-down timer within the message when in ErrorFreeMode: 10, 9, 8, ..., 1, 0 (secs) and then vanish to default land if no response is detected.
I don't know the total number of disappearing message boxes likely to be encountered by users. So far, I was surprised by two messages during library back ups (which I use a lot right now), and two in the help > logging system as previously reported (not a good place for messages to disappear).
Now that I am fully aware of the root cause, I can of course manage ErrorFreeMode manually with MCWS commands in a browser plus username/password login, but that is less than ideal and certainly required some work to discover.