[mythtv-users] slow mythweb?

[Kevin Kuphal]

On Mon, Apr 21, 2008 at 10:34 PM, Udo van den Heuvel <udovdh at xs4all.nl>
wrote:

> Kevin Kuphal wrote:
> > And not to ask a silly question, but why are you saving Schedules so
> > often that it bothers you how long it takes when you only have 3
> > schedules recording 3 channels 24x7?
>
> I have a daily cron job *and* I sometimes run mythfilldatabase manually
> when there have been mythfilldatabase/grabber issues (segfaults, errors
> etc).
> Nothing unusual.
>
>
> It's all very tiny; the streaming of the cnalles to disk takes less than
> 10% of the CPU. Watching TV (SD..) also doesn't take a lot.
> Only the superfluous database actions take up the CPU for `ages` even
> though all of the database is in RAM.
>
> Maybe my situation of daily schedules is unusual for you.
> Maybe you can see that indeed teh amount of channels and programs is tiny.
> Maybe you can adapt the schedulig somewhat towards such a situation
> (never shcedule more than 24 hours in advance perhaps) via a
> setting/switch/logic.


The number of channels is small but the number of programs is huge compared
to someone running 30 or 40 program schedules (maybe 100-200 showings total)
vs. 3 channels running 24 to 48 programs each, maybe 100 programs over 14
days (1200 or more showings).  I think the suggestion to only download 1-2
days of listings is a good one.  Turn off the automatic mythfilldatabase
option in your setup and just run mythfilldatabase with the option (run with
--help for info) for max days set to one or whatever the option is to
download just today and tomorrow.

> It doesn't have to be such a difficult change, and no one else will notice
any issues.

Maybe not, but it's also not likely to hit the radar of many developers
because it is an unusual configuration.  I think the limiting of program
data is your best option because it fits best in your setup

Kevin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mythtv.org/pipermail/mythtv-users/attachments/20080422/6ec0cfc4/attachment.htm