[mythtv-users] "Watch Recordings" slow - disable thumbnail/preview generation, or big SQL queries?

[Michael T. Dean]

On 04/04/2011 12:42 PM, Niklas Brunlid wrote:
> On 2 April 2011 20:46, Michael T. Dean wrote:
> ...
>> To see if you're having data-access problems, try running:
>>
>> wget 'http://<masterbackendip>:6544/Myth/GetRecorded' -O /dev/null
>>
>> (but change "<masterbackendip>" to the IP address of your master
>> backend).  After, you should see something like (probably about 2x as
>> large as since I have 1469 recordings):
>>
>> 100%[======================================>] 1,263,278   --.-K/s   in 0.1s
>>
>> If so--if you're getting the results in, say, 0.2s or 0.3s--the problem
>> is likely the mythfrontend sorting/processing of those recordings.
>> FWIW, with half as many recordings as you have, my system brings up the
>> Watch Recordings screen in (seemingly a lot less than) 0.5s (I'd guess
>> 0.2 to 0.3s, but can't say for sure).  So, either you've surpassed some
>> performance ceiling, have an underpowered frontend (mine is not an
>> Atom--it's a real computer--but trying to load that screen with 3K
>> recordings on an Atom-based system *should* take a long time), or have
>> some other misconfiguration, such as...
>>
>> Often previews /are/ a problem for users with some MythTV system
>> misconfigurations--but, as Raymond  mentioned, won't be a problem on a
>> properly-configured system.
>>
>> Off the top of my head, reasons I can remember that cause previews to
>> slow Watch Recordings include:
>>    a) having your (frontend user) $HOME/.mythtv directory on NFS and
>> disabling file-attribute caching
>>    b) having a broken/not-writable $HOME/.mythtv/{remote,theme}cache
>> directory
>>    c) having a time difference on your frontend and backend machines
>> (you should use NTP on all mythtv machines)
>>
>> There are probably others, too,  but this is a good start of a list of
>> things to look at.
> --------------------------------------------------------------------------------------------------------
> $ time wget 'http://<address>:6544/Myth/GetRecorded' -O /dev/null
> --2011-04-04 18:28:38--  http://<address>:6544/Myth/GetRecorded
> Connecting to<address>:6544... connected.
> HTTP request sent, awaiting response... 200 OK
> Length: 2956015 (2.8M) [text/xml]
> Saving to: /dev/null
>
> 100%[======================================>] 2,956,015   --.-K/s   in 0.01s
>
> 2011-04-04 18:28:44 (291 MB/s) - /dev/null
>
> real    0m5.801s
> user    0m0.001s
> sys     0m0.007s
> --------------------------------------------------------------------------------------------------------
>
> So the actual download goes by quickly, but it takes a few seconds before it
> starts to receive data.

Yeah, on my system, I get my ~1500 recordings with a real time of about 
1s.  Some of that 1s is due to the use of HTTP versus the 
already-connected MythTV protocol, which explains why my Watch 
Recordings screen comes up much faster than 1s.

> System specs: Fedora 13 on an Asus K8V with an AMD64 3000+ and a Sparkle
> GeForce 9400 GT PCI card, with OpenGL painter and VDPAU output, using
> DVI->HDMI to a FullHD LCD TV and the SP/DIF of the mainboard directly to the
> amplifier. The system is somewhat regularly updated against the Fedora and
> ATrpms repos. MythTV version is release-0-22-fixes 22973.

This is the mythbackend system, too?  Since it's now looking like your 
mythbackend and/or MySQL host are causing much of the slowness, their 
specs come into play.  If this is a combined frontend/backend/mysql 
host, or if your master backend/mysql host(s) have similar specs, you 
should be able to get good performance.

> Everything runs on the same computer,

Ah, yeah, then it should be sufficiently-powerful hardware.

>   no external file systems, everything
> on ext3. Recording drives have "rw,data=writeback" flags, used to have
> noatime and nodiratime but those were removed since I suspected they
> interfered with thumbnail generation.
>
>
> Is $HOME in (b) above for mythfrontend or mythbackend? The frontend runs as
> my normal user, the backend runs as root. In the user home remotecache and
> themecache are writable by user and group, in root:s home I only have
> themecache and it's writable by root only.

Yeah, remotecache is only created for frontend systems.  As long as the 
user running the program can access the $HOME/.mythtv/* stuff 
appropriate for its environment, all is good.  So, if your frontned is 
run as your normal user in an environment where 
HOME=/home/<yourusername> , and $HOME/.mythtv/*cache are writable by 
your user, you're good.

Since it may well be backend data access or processing causing the slow 
down, I recommend trying something like:

wget mysqltuner.pl

and then running it against your database to see if it has any 
recommendations.  Also, what kind of RAM do you have in the system?  I 
could see it being slow with too-little RAM causing paging (maybe 
512MB), but you should be good with 2GB, and might be OK with 1GB (lower 
RAM may require usage of lower-resource themes, too, since it's a 
combined frontend/backend system).

Mike