[mythtv-users] slow mythweb?

[Kevin Kuphal]

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

> Michael T. Dean wrote:
> > On 04/21/2008 01:13 PM, Udo van den Heuvel wrote:
> >> Michael T. Dean wrote:
> >>
> >>> If you
> >>> really want to record everything with that system, you may need to
> find
> >>> another program to do it.  Or, you can get a better system.  Or, you
> can
> >>> try more systems (though you'll almost definitely need a more powerful
> >>> master backend--as it's the one that does the scheduling).
> >>>
> >> For recording only three channels I need more than this Epia?!
> >> What is the bottleneck?
> >
> > Only 3 channels is meaningless when you tell Myth to record /every/ show
> > on those 3 channels.  Just a simple query on my system shows that 3 of
> > my channels (a local NBC, CBS, and ABC affiliate--i.e. some of the US
> > main networks) have 1200 shows in the next 2 weeks (through the end of
> > the available listings data).
>
> What use is that?
> Listings info is updated daily and maybe even more often.
> So why do the same work over and over and over?  Just info until the
> next show could be enough. Maybe including the next show after that one.
> But even then.
>
> There is only program info for a few days into the future (5 or so) and
> we're not watching american networks.
> I don't care much about dupes since it is LiveTV and as long as there is
> enough storage for a reasonable buffer it can go on. It'll expire
> eventually.
>
> > So, Myth is managing information about all of them.  It's also checking
> > for duplicates.  It's scheduling when best to record them to make sure
> > you record them as early as possible and/or with the best capture card
> > possible and/or ensuring the proper prioritization of shows and/or with
> > the fewest conflicts (all dependent upon various MythTV settings).  It's
> > doing a ton of stuff.
>
> I only have one card. I have 5 virtual tuners and looking into patching
> so I have 6 virtual tuners. No more conflicts. So why check for them?
> (they re much rarer now with multirec than they were before) (what file
> can i edit for that? I only need to know the right location)
> Maybe 7 tuners so I can record and watch without conflicts.
>
> > Therefore, I still suggest some other program (i.e. dd or getatsc or
> > something) or get a better system.
>
> The system (software) is assuming way too much. How can I tell the
> software it doesn't have to?
> It's only 3 channels on a simple Dutch public TV situation. If that is
> too much for a VIA Epia 12000EN there is something wrong.


You're thinking of it in terms of you you *want* it to work vs. how it is
designed.  Myth is designed to record shows from a set of channels that
possible overlap and duplicate themselves and schedule those shows according
to priorities to best fit everything in.  This is not excatly how you have
it.

Now, that being said, Myth *could* do alot less work to schedule in your
specific scenario because as you said, there *shouldn't* be any conflicts
and *shouldn't* be any duplicates.  Now, you can control the duplicates by
turning off duplicate checking on your recording rules, but Myth has no way
to know that your particular scheduling requests will never result in
conflicts unless it trys to schedule everything, and as has been noted, the
average system doesn't have 1200 showings scheduled for the next 5 days.

With that in mind, it is unreasonable for you to assume that Myth can
automagically know not to bother looking for conflicts when that is at the
core of it's design.  What you could consider is maybe modifying the
frequency of reschedule requests by short circuiting the rescheduling code
to only run at certain times or in certain circumstances.

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?

Kevin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mythtv.org/pipermail/mythtv-users/attachments/20080421/957fe7b8/attachment.htm