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

[Niklas Brunlid]

On 4 April 2011 18:42, Niklas Brunlid <prefect47 at gmail.com> wrote:

> On 2 April 2011 20:46, Michael T. Dean <mtdean at thirdcontact.com> 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.
>
> 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.
>
> Everything runs on the same computer, 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.
>
> / Niklas
>
>
Noted yesterday that the time to enter Watch Recordings is dependant on
wether something is currently being recorded... which I guess is related to
the theme (ArcLight) flashing "recording" and mythfrontend taking 50-90% or
the cpu as long as those entries are visible. The cpu usage goes away if I
scroll down or start playback.

/ Niklas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.mythtv.org/pipermail/mythtv-users/attachments/20110404/8286a80b/attachment.html