Web remote /main lagging and missing slides

AndrewArm

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.

@13:47 No web remote sessions active
@13:51 A single chrome session for /main was open on my laptop (also hosting OpenLP)
@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?

Jamie Hockin

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.

AndrewArm

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.

AndrewArm

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.

Jamie Hockin

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.

AndrewArm

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

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.

Jamie Hockin

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.

AndrewArm

Jamie Hockin

Apparently you can change the custom stage to use formatting
5470-formatting-on-stage-view

Simply replace "text" with "html" including quotes in stage.js

Jamie Hockin

AndrewArm
You made my day. I'm sure I read that somewhere, but this really helps.

Jamie Hockin

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!

Jamie Hockin

@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.

raoul

@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.

tstephen10

raoul I've been meaning to see if I can fix this too. If you can give me whatever pointers you have that would be a great help.

witterholt

AndrewArm 8GB should be sufficient for both OpenLP and Web Remote.

Jamie Hockin

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...

Jamie Hockin

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.

raoul

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.

Jamie Hockin

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.

raoul

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.

raoul

tstephen10 The main issue I'm seeing is a deadlock of sorts. When two different clients try to capture the screen at the same time, then they end up waiting for each other, it seems.

https://gitlab.com/openlp/openlp/-/blob/master/openlp/core/ui/slidecontroller.py?ref_type=heads#L1333

It's not ideal (obviously) but I haven't figured out an easy way to get around it without some significant changes.

Jamie Hockin

raoul You know the code much better than I ever will. The comment below
def grab_maindisplay(self) -> str:
is Gets the last taken screenshot
but it seems to me, we take another screen shot independently of the ones taken to update the live display window. I don't fully understand what happens during transitions, but could you save the post-transition screen shot as an object and just serve it up to any remote requesting it?