For clarity, as every open source project has its own practice, are you saying an update includes only one bug fix at a time?

I mentioned the web remote based on this comment from Raoul himself (in reply to my post about it): “There's an issue in the remote at the moment where more than 1 remote showing the main screen causes a race condition and manifests as the reload taking a long time. We're looking into it, but it's been pretty difficult to debug.” I see now that may have mean “remote API”.

Thanks.

    j_tizzle nope, the previous release did not have one change. But this release did because it was a new bug introduced with a previous change and was rather simple to correct. So, as a service I made a small in between bug fix release, hence the patch version increase. As a bonus several bug fixes in the dependency packages also come with it.
    The small foot print of this project makes it possible to do so because it is loosely coupled to OpenLP.

      11 days later

      j_tizzle Thanks for that tip. It is when there are 2 clients looking at /main that the 10 second delay kicks in.
      Is a useful fix to just add a button to force a push refresh of the current slide, because that would be very useful for showing the "Desktop". When you switch to showing the desktop you just see the first image, and if there was a manual refresh button the remote view would be of the latest image on the desktop. I have been doing this by quickly switching from Desktop to black and back to Desktop, but then the main stage view gets the black flicker.

        21 days later

        Is anyone having the issue that he /main stage is not updating? I've had issue since version 1.1.0. in OpenLP version 3.1.3.

          ywtstewart The remote interface—whether main or stage—is simply unusable for me.

            I will look into this issue. Since what version of OpenLP and Web Remote did these problems occur?

            @j_tizzle , @ywtstewart, @SimonG, I could reproduce the issue when I used the main view from two different devices and I was able to fix it.
            The bug is located in the Web API of OpenLP and not Web Remote, so the fix will become available when a new release of OpenLP will come out.
            We will soon release a 3.1.4 version to solve this though.

            a month later

            I don't believe having a link to the webremote control on the stage view is a good idea. Giving someone access to the stage view could mean that they disrupt the service by clicking the wrong thing. Yes, custom stage views can solve this, but from a design/web safety standpoint, I can see issues.

            5 days later

            Doing more testing with the web remote and I'm noticing that it's not as responsive and way slower than the previous web remote with the same equipment. Looks pretty, but is not as useful. Any way this "upgrade" can be rolled back?

              wemmc Did you use OpenLP 3.1.5 as well since the unresponsiveness bug when multiple clients are connected has been solved in OpenLP not in Web Remote.

                  witterholt We are using 3.1.5, and as far as I know we have a TV connecting to a custom stage view, and my phone connecting to the webremote, and our video computer on OBS using the LowerThird custom stage view. That's the total connection to OpenLP. In 2.4 this worked without issue and the webremote was fast and responsive. In 3.1.x it's not useable.
                  To be fair, pretty much everything runs a lot slower in 3.1.5 than v2.x did. I like that there are a couple of new features that were added, but even with twice the computer we used to have everything is way slower than it was before, and we're getting random errors that require restarting OpenLP. If I make a change to a CSS file in a theme, why do I need to restart the entire application? That should load on the fly. I don't need to restart Apache or Nginx on a web server.

                      3 months later