Hi Folks,

I'm hoping someone clever can help me understand and fix this. We have a lady at church with vision problems so she uses the remote /main view on her iPad instead of looking at the beamer. Historically this seemed to work well, but since we have moved to various versions of OpenLP 3 she has complained that there is a lagging problem. I have confirmed this behaviour using my android phone and had jumped to the conclusion that it probably was a network, or maybe PC resource issue, but following some tests today I'm not so sure.

I did a test at home using OpenLP 3.1.1 on Windows 10 (Intel(R) Core(TM) i7-8565U CPU @ 1.80GHz 1.99 GHz with 32GB RAM) and the service file from our service yesterday. This has a pre service loop of 12 slides changing every 5 seconds. I rescaled the display screen geometry by a factor of 10, so I could overlay the display and remote /main in Chrome (Version 121.0.6167.86). Below I have attached a video of the result.

Main screen in sync

This shows the remote display changing almost immediately after the "screen" shown in the upper left of the video.
The next video shows what happens as soon as I also connect to the remote /main from my android phone (Chrome version 122.0.6261.119)

Main screen lagging and missing

The remote /main screen lags so severely that it misses 2 out of every 3 slides. This test is extremely repeatable - as soon as I stop using Chrome on my phone the web remote on my laptop reverts to normal behaviour. At the moment I have the latest remote 0.9.13 installed, but I have also tested 0.9.7.1 with similar results. I have also tested connecting to the remote using another windows laptop and that causes identical lagging.

The other test I performed was to disconnect the chrome session of /main on the OpenLP laptop. When I did this it appeared that my remote laptop was in sync, until I used the phone at the same time, when once again both remote laptop and phone sessions started dropping 2 out of 3 slides.

What is going on? It appears to me that if more than 1 user is connected to the remote web server it struggles. Thanks in advance for your input.

Andrew

Addendum - Just for my own sanity I went back to 2.4.6 and tried this and the lagging issue is not there.

    AndrewArm When you were using 2.4.6, were you using the old web remote that is bundled with 2.4.6, or the new one that needs to be downloaded separately?

    One of the major upgrades we made from the old version to the new version is that the old version use polling, where it would check back with OpenLP every second or so, whereas the new version uses websockets, which is a live always-on connection to OpenLP.

    The polling method was extremely unreliable, so I find it quite interesting that it seems to be more reliable than the web sockets.

    I wonder if there's a problem with the websockets server in OpenLP which is causing this issue? Can you check your log file for errors?

        raoul Hi Raoul,

        Thank you for the reply. To briefly answer your questions

        • With 2.4.6 we used the bundled remote.
        • There were no websocket errors in the logfile

        I have done some more tests today and created a debug log which I have uploaded here

        I did 3 loops of 12 slides, changing every 5 seconds.

        1. @13:47 No web remote sessions active
        2. @13:51 A single chrome session for /main was open on my laptop (also hosting OpenLP)
        3. @13:53 A 2nd chrome session for /main added from my android phone. Lagging behaviour observed

        My reading of the log file is that everything seems to be working normally, but maybe you can see something I don't.
        As the web socket server seemed to be working normally I expanded my testing to looking at the slide view and the stage view. Both of these work as expected even when there are multiple sessions on both laptop and android. It is only /main that lags. I did wonder if this was a problem with the fact that these are image slides, so I also looped a song and with a change every 5 seconds - it also misses 2 out of 3 slide changes when there is more than one session open.

        Does any of this help?

          For what it's worth. I tested this out with OpenLP 3.1.1 on my iMac, using a remote Main view on a browser on the same machine and on my phone. There is a delay of 8-10 seconds before either shows a new slide. I can't compare to earlier version 3 releases as the main view reliable crashed OpenLP.

          When only a single browser was connected to the Main view, the delay was a fraction of a second.

          We use the Main view in an OBS browser window at church to put a slide with graphics into our streamed services. No one else connects there. But we're still using an earlier version of OpenLP 3. Window capture and screen capture work as well there.

            Jamie Hockin Thanks for confirming it isn't only me. We also have a main view embedded in one of our OBS scenes and I now realise that this is what is causing the issues for our sole vision impaired user.

              Yes, @AndrewArm . Your post gave me the idea of providing a tablet with the Main view on it to our one visually impaired congregant. Right now, someone prepares large print copies of hymns and bulletins.

              However, what I will try for her is to create a custom stage view that has only text on it. We use custom views with OBS to provide text overlays for hymns, prayers, etc. I can confirm that the custom stage views don't have the same problem as Main. Multiple stage views display immediately.

              This morning I opened two browsers with the Main view on my desktop, with the same result--a long delay before the image is rendered. Digging into it a bit, I can see that the OpenLP websocket communicates to both browser windows immediately that it has an binary packet (the image) coming, but then waits a long time for it. I don't know if the delay is on the browser end or in OpenLP, but I suspect the latter.

              Here's a thought for the developer of the web remote. Why not send the images out via UDP packets. One broadcast will get to all clients. Maybe this is impractical, but it seems to me that OpenLP is fighting itself to get multiple images out. I may be totally off base. I thought looking at the javascript for the main view would provide some insight, but it's a complete mystery to me. It seems to be a one size fits all monster code.

                Hi Jamie Hockin,
                The custom stage view is a good idea, which I have already tried. I simply took everything out of the <body> section of stage.html apart from

                <body>
                <input type="hidden" id="next-text" value="next" />
                <div id="currentslide"></div>
                </body>

                This works fine for text, but we use ppt slides converted to images for our liturgy so I then made this change to the updateSlide section in stage.js to get rid of the image name above the image.

                // use thumbnail if available
                if (slide["img"]) {
                text = "<img src='" + slide["img"].replace("//thumbnails//", "//thumbnails//") + "'>";
                }

                This worked but the stage view uses very small thumbnails rather than the original images. See forum. The only solution I have here is to open the service in OpenLP and then replace all the thumbnails in images/thumbnails with the original images extracted from the osz.

                It all appears to work rather well (it would be better if I could get chrome on android to go full screen, but fortunately my congregant uses an iPad :-) However copying the images is a rather clunky work around which I'm not going to do every week, so for the moment I'm going to make sure we only have one user of main.

                    AndrewArm
                    It would be great if custom stages could receive the full image. We use full-screen images at times, but not for hymns or other liturgy. Fortunately we had access to all lyrics in our main hymn book and I massaged that into the songs database several years ago. We go with a small left- or right-sided theme image each week, leaving most of the screen for text. It takes only a couple of minutes to create a service file without having to play around with PowerPoint.

                    For me, with a single browser to the Main view, the lag is maybe half a second, which is acceptable. The drawback to custom stage for us is that you lose the font decoration. We routinely use plain text for the worship leader and bold text for congregation responses. So I'll try that this week, but make sure that we don't have an OBS scene that uses a browser to Main. For OBS it's just as easy to use a display capture anyway.

                        I can report that our one person who is visually impaired is thrilled that we can provide a tablet with the slides on it. Thanks again @AndrewArm for bringing this to my attention!

                        9 days later

                        @AndrewArm Do you have any advice about locking down a tablet to show only the browser view. We're using a tablet with Windows Home Edition and it's impractical (if not impossible) to set up kiosk mode. I'm going to try to put Firefox into kiosk mode, but not sure yet what will happen.
                        Also, I further tweaked the javascript to hide the <div> with html content if the screen has been blanked. That works very well.

                        @AndrewArm I was able to reproduce this, and I've narrowed it down to where the issue is happening... now just to figure out WHY and how to resolve it.

                          raoul That is good news Raoul, I look forward to you solving my problems as usual :-) Have you also encountered any issues with someone connecting to main actually "crashing" OpenLP as reported by Jamie Hockin. I hadn't seen this myself until this week when I bought the church laptop home to play with and when I connected to main on my android it bought up a busy hour glass with OpenLP that never went away. We can't use the main view at all if there is a risk it will stop the show for everyone. Is there a minimum memory requirement for the remote? Our church laptop only has 8GB RAM.

                                AndrewArm The MAIN view does not crash OpenLP with the latest release (3.1.1) and the latest remote interface (0.914). I only had that crash on the Mac with 3.1.0.
                                However, clearly you cannot have more than one browser accessing MAIN remotely (or even on the same computer) as the delay in refreshing makes it impossible to use this way. I've created a custom stage view (access via URL:4316/stage/isight) that incorporates the slide HTML and also blanks the remote view if the OpenLP screen is blanked. There is no delay if we have multiple views open. Now if only we can get full size images as an option, rather than thumbnails...

                                  a month later

                                  For what it's worth, I tried using the remote API V2 to request a screen image when there was an image displayed, but the API seems to use the same call as the MAIN remote view. So it has the same effect. Perhaps this should be a feature request - provide, via API V2, the full-size image as an option. Given network speeds today, this shouldn't put a burden on any hardware, since it's a simple http request.

                                    Jamie Hockin Good point. I did recently change the way OpenLP generates thumbnails so that it uses the "maximum height" setting when generating them, which will be in the 3.1.2 release (which will be released once I can figure out our favourite VLC on Mac issue), this should hopefully make things at least easier for now.

                                        raoul This will be great (and enough for me). I think the maximum size is more than we need.

                                        In the V2.x era, we were cautioned to use only even minor revisions. I assume that is no longer the case. 3.1.1 is great, aside from VLC. We'll wait for 3.1.2 before updating the church PC.

                                            Jamie Hockin Yes. We've moved to using a versioning scheme recommended by Python (the language OpenLP is developed in), so that rule no longer applies.