Use newer reconnecting websocket and reconnect when page receives focus #1446
Conversation
Fixes failures to reconnect after web app has been dormant
|
I did some testing and it looks like we are now calling each service twice if a focus or visibility event is processed (I tested with switching to a different tab in firefox on a laptop). The requests are normally quite fast, so it is not something that is really recognizable. But I am wondering if reloading the data on focus and visibility change events is the best approach. As long as the websocket connection is open, even if owntone does not have focus and/or is not visible, the notification events should be received and processed. If my assumption is correct, maybe a better solution is to check on focus / visibility change if the connection is still ok and that all events were received. I was thinking that it might be good to number the events in owntone-server and send this event number as part of the notification. The ui could then keep track of the last event number it received and processed. |
|
I agree the numbered notifications would be a lot cleaner. I’ll try this approach and report back.
…--
Ben Willmore
Auditory Neuroscience Group
Oxford University
On 10 Apr 2022, at 16:11, Christian Meffert ***@***.***> wrote:
I did some testing and it looks like we are now calling each service twice if a focus or visibility event is processed (I tested with switching to a different tab in firefox on a laptop).
The requests are normally quite fast, so it is not something that is really recognizable. But I am wondering if reloading the data on focus and visibility change events is the best approach. As long as the websocket connection is open, even if owntone does not have focus and/or is not visible, the notification events should be received and processed.
My guess, why this sometimes does not work, is, that the reconnecting websocket does not detect that the connection is broken and the ui is now out of date.
If my assumption is correct, maybe a better solution is to check on focus / visibility change if the connection is still ok and that all events were received.
I was thinking that it might be good to number the events in owntone-server and send this event number as part of the notification. The ui could then keep track of the last event number it received and processed.
On focus / on visibility callbacks could then trigger the ui to send a message over the websocket to the server with the event number of the last received event. The server would check if the event number is less than its last event number. If this is the case the server should send a notification to the ui that will cause the ui to update the stale data.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you authored the thread.
|
|
@ben-willmore last week I started to implement it, but did not finish ... I managed to add the number and include it in the notification. If it helps, here is what I did so far: https://github.com/chme/forked-daapd/tree/feat/ws-ping |
After quite a lot of testing of my previous fix (already merged by @chme), I found there is still a situation where the Now Playing (etc) information stops getting updated. It seems to depend on client platform -- on my laptop, I have to leave the OwnTone webpage in the background for a long time for it to occur, but on iPhone it happens within 15 seconds if I go to the Queue page, then switch to a different app on the phone, then switch back to the OwnTone tab.
The reconnecting websocket module is abandoned, and there is a newer version -- https://github.com/pladaria/reconnecting-websocket . Using this, and reconnecting the websocket when the web page receives focus, fixes the problem.