[mythtv-users] Web interface scalability issue: Video Gallery

Paul Harrison mythtv at mythqml.net
Sun Sep 10 13:59:48 UTC 2023

On 10/09/2023 01:48, Peter Bennett wrote:

> I have never noticed 10 second delays, and I don't think anybody else 
> has. Somebody would have let me know about the slowdown.

I wonder how many users have actually used it though? The WebApp is 
fairly slow to load so an extra 10 seconds delay here and there would 
likely go unnoticed. The only reason it really stands out for me is 
because I know how quick it was initially. I think it was only when we 
added more stuff that causes more concurrent connections to the BE that 
the problems started. It is just about usable if you are desperate but 
not something I would want to use everyday which is OK with me since the 
WebApp was always a means to an end, the important thing was to get all 
the API in place then I can use it however I want :)

> The longest timing in the debugger network tab is the GetBackendStatus 
> at 1.46 sec, followed by GetProgramGuide, at 743 ms. GetUpcomingList 
> is 236 ms if you select "Show All Statuses".

Your system is way quicker than mine GetBackendStatus takes 3.15 sec, 
GetProgramGuide 904ms. GetUpcomingList only takes 64ms but we no longer 
use Myth to record stuff so the list is only 8 rows long \0/

> I don't see a tortoise. Firefox also does not give me any slow responses.
> Channel Editor takes about 5 seconds to load, but that is because it 
> is loading hundreds of icons, and getting a 404 error for most of them 
> as they are missing on my system.

The Channel Editor is fairly quick to load but I don't have many 
channels. They nearly all have icons and I do see the occasional one 
taking 10 seconds to load but that does not slow down the appearance of 
the editor just the appearance of the delayed icons.

> I use Chrome for developing and testing, but I have tested on Firefox 
> also.

Always use Firefox. Have also tested with Chromium but not Chrome, I 
think they are closely related though.  I'm fairly confident it's not a 
browser problem.

> As for Jan's report of slowness, it turned out he is running MythTV 
> V33 so he is not using the web app, he is using the incomplete web 
> frontend.

I did see that, I'm not laughing honestly! Dare I say it? I'm going to 
say it.  We should try having regular 6 monthly releases to coincide 
with Ubuntu releases. I know I'm crazy I really should not be let out in 

Another data point I did just try the old WebFrontend and that is quick 
and responsive with no noticeable delays. Some of the API calls do take 
a few seconds like the one for recordings but that's just how long those 
calls take to complete. Certainly no sign of any requests waiting 10 

I did notice when trying the  Video Gallery that Jan was having problems 
with it does spam the BE with lots of request to get the cover art, most 
of which get blocked because the browser only allows 6 simultaneous 
connections to a single server but that is different than the delays I 
was seeing in the WebApp where the delay is in how long the server takes 
to respond to the request not how long the request was queued up for. I 
would say the UX is way better in the WebFrontend that the WebApp simply 
because it's way more responsive and let be honest it just looks better.

> I suspect something else is going on in your system to cause the 10 
> second delays.
> Are you running the browser on the same machine as the backend?

No the BE is running on my ESXi server in a VM. I don't see any problems 
with my other VM's that host websites/apis like my ZoneMinder server.

> Do you get 10 second delays when running the API calls through curl or 
> on a browser?

No I've never seen any delay using the API directly but I typically only 
send one request at a time not the multiple concurrent requests that 
browser send which I think is the problem.

> Are you using SSL? I am not and probably 99.9% of users are not.

No not using SSL.

Don't get my started on why we shouldn't make the same mistakes as 
MythWeb which by default is completely open with no security at all. 
It's slightly worse with the WebApp because of all the access to the 
setup stuff. Anyone with access to the WebApp can completely trash your 
system if they are so inclined. I think at the very least there should 
be a way to only allow certain users to access the setup stuff to 
prevent unintended meddling. I did put a prominent login button in the 
header to remind everyone what the intention was but I see you removed 
it :( Correct me if something has changed but I believe there is also 
currently no way to configure slave backends something that needs be 
addressed before completely removing mythtv-setup?

> I have installed a recent master on my production system, and I use 
> the web app perfectly successfully on that, no delays.
> Here are my timimgs for main.js: 10 ms for local machine and 51 ms for 
> remote over wifi. Nowhere near 10 seconds.
> https://imgur.com/a/3I9iUFN

Aren't you the lucky one :)

TBH I'm not too concerned about it so long as the API is still usable 
I'm OK with that it was more a FYI.

As you know we no longer use MythTV to record stuff since we got TiVos 
we pretty much only use those or the smart TV Apps for on demand stuff. 
That will undoubtedly change again when our current contract runs out 
and the heavily discounted deal reverts to normal prices but for now we 
really don't need to use MythTV at all for anything so I don't bother 
wasting cpu cycles on it. Plus I needed the SSD space, memory  and cores 
to play with Home Assistant :) I think we could learn a lot from the way 
HA handles a lot of stuff. They do have the advantage of a much larger 
user base though.

> Peter

Paul H.

More information about the mythtv-users mailing list