We noticed that the mAirlist UI freezes/becomes completely unresponsive for multiple seconds when entering an empty or a very short (single letter (e.g. ‘a’)) search string in the “Browser Search” window of the playout application in v8.
For context, we are currently working on migrating to mAirlist and are in the final stages of switching permanently to the software. We run 5 stations (multi-instance on cloud-based infrastructure - directly hooked into a PostgreSQL database) and have 4 different physical studios (connected to the cloud server over VPN using the mAirlist DB Server, with a fully local sync of all audio tracks). We have a database that consists of around 40.000 different tracks.
Knowing the size of our database, it is understandable that searching takes multiple seconds when entering a search query, however, it should not freeze up the entire application while it is running, blocking a DJ from interacting with the application.
Reproduction
Now, to verify this issue, I created a new mAirlist database on a fresh (trail) installation of the latest version of V8 Professional (8.0.8), added around a 200 tracks to a local database (DB file), and tried to reproduce the same issue. When typing an empty search query you will see the playout software also freezing for multiple seconds:
do you see the same Problem on older Versions of mAirlist or do you migrate from a totally different software?
From my experience using Database connections over VPN can cause lot of problems but that also depends on what type of VPN is used. OpenVPN might cause more problems than IPSec (v2) or Wireguard. So what are you using as VPN?
But in general, yes I would like to see non gui blocking requests when using mAirlist, that would make a big difference. By the way, usually the playout will continue even transitions to the next song will not be affected by the freeze. At least that was always Torbens priority and I saw that in action. But yes, I get the point, it does not feel right. Especiall for people that are not that deep in IT.
For the local database the freeze is kind of expected, that is a single file SQLite with no proper database backend. For testing the behavior I agree, it is always good to double check as you did.
For your Studios, did you test what happens if you connect them directly to the PostgreSQL Backend instead of through the mAirlist DB Server? You have the files local anyway, so you might not need that component in between. I only use mAirlist DB Server if I have to connect studios without having a VPN. So I can use direct https.
I assume if you do a search on the desktop of your cloud infrastructure the behavior is the same as in the Studios?
do you see the same Problem on older Versions of mAirlist or do you migrate from a totally different software?
We are migrating from different playout software.
We are using a WireGuard based VPN solution. In my experience with testing different setups this has no additional latency on the DB server API calls or performance impact on the playout software.
In my experience, using the DB server for our studios is faster, compared to a direct PostgreSQL connection. (I think this may have something to do with the fact that direct SQL connections requires more round trips to the database to build all the necessary data, while the DB Server multiplexes more data in the API calls - but that is only an assumption . Since we run the PostgreSQL instance on the same host as the DB Server, it can run DB queries faster).
But in general, yes I would like to see non gui blocking requests when using mAirlist, that would make a big difference.
This is indeed the main culprit here. Even if the search would have taken 20s, it should not freeze the UI during the search operation. The same can be applied to other parts of the application that require DB(server) calls, like the item properties dialog, for example.
The audio never freezes, so thats great, but it’s not ideal for our DJs, who think the application is about to crash…
I assume if you do a search on the desktop of your cloud infrastructure the behavior is the same as in the Studios?
I just tested this, the same freeze behavior applies.
Yes, I get that. I am a Sysadmin, I know how stable mAirlist works, I know how much mAirlist evolved and still I’m sometimes worried if it might crash.
So we can take any VPN or network issue out of the way. I am close to a 100% sure we don’t have any Network layer issue here.
Maybe @Torben can look into this. Although I don’t think this can be classified as a bug but more like how the architecture of the software is at the moment. So hopefully there is a chance to decouple the GUI when there is a search request happening.
By the way similar things happen when we drag a 2h recording from the Windows explorer directly to the playout playlist or a database playlist. Because the file will than be analyzed first, the gui might also freeze. So I trained the people operating that, not to open the Database from the playout window but from a Desktop shortcut. This way they are 2 independent processes and the playout keeps being responsive at any time while the Database gui freezes during analysis. Works stable for us since many years.
Dafür wäre ich auch sehr dankbar! Und ich glaube wir sprechen hier von 90% der mAirList User
[ENG] I’d really appreciate that! And I think we’re talking about 90% of mAirList users here
. Since we run the PostgreSQL instance on the same host as the DB Server, it can run DB queries faster).
