Network instability! Disconnects! Can’t find the IP. Default password compulsory!!! This annoys me the most! In this post you will hear me complain the most. And, for a good reason.
The mobile apps … hmmm not so good. There were some welcome recent improvements in the apps but they still suck a bit or a lot( I mean a lot ).
- First, on my old tablet, the stage mode freezes if it can’t find the IP via search. It eventually asks me for it but the stage mode overall sucks. It has all the right features, don’t get me wrong but it’s not efficient.
- The overall implementation works but is not resilient!! Have you told your church, wait everyone “I am waiting for this thing to connect!”? Or “Can everyone please turn their phones to air-plane mode?” ? Well, I have! More than once!
I was very unashamed when I did because I need it to work in order to see the chords.
OK, in all fairness it’s not entirely quelea’s fault it’s the network too.
Also If you turn the WIFI off it seems it’s able to recover from the freeze.
First of all: we don’t have a way to define a custom URL! In reaper, you can define a custom URL.
So easy! I go home run quelea, bam! Same URL. I go to church bam same URL!
Go anywhere bam bam bam! Did the server change IP or switch interfaces? Works!
You always know the URL and have it in your bookmarks.
Second, it stores the IP but in a bad way that makes my tablet freeze for a minute or 2 while it’s searching… or something. ahhhh
Issue 5.1: Ok, first the search should be cancelable!
Overall autodiscovery needs to be improved. Sometimes it just can’t find the server.
Issue 5.2: I should be able to put a custom URL. (maybe this can be done in the router or on the server, but quelea should be able to do it!)
Issue 5.3: Why is the password compulsory!!!???!!! It should be strongly advised but not compulsory! I own my LAN it has plenty of protection!
Issue 5.4: Why can’t it store the password!? Sometimes gives me a ton of trouble not being able to store the password. I mean it’s the same every time. It’s been the same for years! Quelea! My production LAN is isolated from the Guest network.
It’s too much when the not-so-computer-literate musicians keep asking me what is the IP and what is the password. I want to make it easy for them.
Issue 5.5: There should be a green/red dot somewhere on the stage mode to show it’s connected. Just some indicator.
Disconnects are fine, a momentary dropout is fine but it needs to be able to tell you better.
Issue 5.6: If I am in stage mode and I see Chords why do I not have the buttons for transpose!?!
If you are not a musician you don’t know what I am talking about but do you know how many times I have had to transpose a song on the fly? Oh. wait that’s a bit high for you, let me drop it a semitone lower!! For you singers out there, you know what I am talking about!
Am I supposed to get up, go to the PC drop, it with 1000 clicks then go back on stage? This needs to be easy from where I am!
Issue 5.7: SLOW! The response is slow! On a wired network, it works quite decent actually but on the wireless which most people will be using the response is still slow.
Latency! Latency! Latency!
Here is the problem, if someone else is changing the slides for you they might be a little late and then you need the chords for the next section they press but you have to wait for a bit to get it and you have already missed the music.
What I do is have a computer on stage and it actually runs a single LAN cable for audio/video/quelea etc. The multimedia PC ( another PC) is also wired so besides the tablet I always have quelea opened in the web browser just in case. That has saved me before.
You can not run mission-critical things on wireless in a wireless noisy environment.
Quelea is a mission-critical software and needs to be optimized in that sense for connection and reconnection resilience!
Note: the issues mentioned here are also relevant to other software, but the things relevant to quelea have to be improved.
What’s with all the traffic all the time?! Have you checked how many packets are buzzing around all the time using Wireshark?
I think we need a more efficient model transmission model.
Remember the green/red button in Issue 5.5? Running that at connection “is connection live alive” check at 250ms;500ms or even 1000ms is fine. In fact, we should have the option to tune that maybe?
Most of the time, nothing is happening at least for the next 8 or so bars of music.
But when it happens it needs to happen as fast as possible i.e. low latency!
The viewers are not sending back any data. Send once and confirm! If there is a problem resend it again (once).
There should be a panel to tell us what the connected devices are and if they are active in the server options panel.
Things should happen on even bases when something is triggered!
I mean I think it’s like that by design as far as I have looked at the code but again what’s with all the traffic?
On my wifi6 router, I can get pings from 1-2ms to 200+ms initially, but actually, once the connection is established the latency is pretty low. Also, we could probably ensure something like 30 FPS latency i.e 1000/30 ms. On wire (ethernet) it’s ok, even great, but my phone can’t easily or conveniently connect to the ethernet port and if it did it won’t be a “mobile” phone anymore.
I think OpenLP got those a lot more right on this one. And as you can see my frustrations are really raging with this issue! I am saying this as an active user and I really hope to see some great improvements.
Disclaimer: I haven’t actually tested OpenLP in a mission-critical situation so my opinion might be biased because the same issues are present there but again I am sharing some food for thought.