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

Peter Bennett pb.mythtv at gmail.com
Mon Sep 11 00:48:44 UTC 2023


On 9/10/23 09:59, Paul Harrison wrote:
> 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? 

James Abernathy tested everything, including doing multiple setups from 
scratch using the web app setup.

Klaas DeWaal, Bill Meek, Ken Mandelbaum, David Engel, gave feedback 
after testing it. Some feedback was that it does not look pretty, but no 
slowness complaints that have not been fixed.


> 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 :)
I notice no slowness at all. I use it regularly to look at my backend 
upcoming recordings, videos, etc.
>
>
>> 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 have loaded every possible channel including ones I do not receive, 
now there are 843 channels in my laptop test system.
>
>> 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 public.
>
>
> 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 seconds!
>
>
> 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 done nothing for security in the web app. I rely on the ip 
address checks that I put in a couple of years ago. Unless the user 
specifically allows connection form all ip addresses, only connections 
for the local subnet are permitted.

Slave backend setup is supported. If you start the web app on a slave 
backend, or a system that looks like it should be a slave, it displays 
at the top of the page:

This appears to be a slave backend. If it is intended as a slave 
backend, please disable scheduling on the master backend while running 
slave backend setup.
If this is not intended as a slave backend, please go to Setup, General, 
Host Address Backend Setup, and select "This server is the Master 
Backend" or else set the correct custom identifier on the Database Setup 
page. Save and Restart the backend,

In the case of master backends, the code will not save any setup pages 
until you disable scheduling. In the case of slave backends, the user 
must manually make sure that scheduling is disabled on the master.

The dashboard part of the web app is rather limited when running against 
a slave.

>
>> 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 :)
>
It is hard work, not luck. I have spent over a year working on this and 
some of the time was spent on improving performance whe I found 
something was slow.
>
> 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. 
I did not know that.
> 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.
>
>
I just did some testing on the slowest machine I have, a pentium laptop 
from 2017. For example it takes 30 seconds on this laptop for chrome to 
start after clicking it on the start menu. I am accessing a backend that 
is on wifi and the slow machine with the browser is also on wifi. The 
slow laptop has only 2.4 GHz wifi, the backend on a fast laptop has 5 
GHz wifi, so the signal is getting translated in the router.

Channel editor (843 items) : 7 seconds to open
Program Guide (843 channels): 6 seconds to open
Videos (7531 videos) : 3 seconds to open
Upcoming (701 shows): 1 second

Is your database remote from your backend? Tests of running queries 
against my slave backend are rather slower (because of the remote 
database), with API response of 6.2 seconds for the call to get the 
video list, for example

If my database is on a system connected to the backend via wifi, then I 
get some horrible response times. Wifi is asymmetric. They advertise 
speeds of a Gigabit per second, but that is download speed. Upload speed 
is a fraction of that, and having the database on a wifi connected 
laptop kills the speed.

Peter






More information about the mythtv-users mailing list