[mythtv] mythcommflag control suggestion

Ambrose Kofi Laing aklaing at gmail.com
Mon Apr 3 21:49:36 UTC 2006


It is a 900MHz Athlon, with 640 MB of RAM, and it has 3 disks.  One (20G,
UDMA66) has the root and home
filesystems, with swap.  The other two (100G and 40G) are merged with LVM to
obtain my /myth directory.  DMA is enabled
for all of them.  Tuner is a PVR-350.  I don't know if the way LVM works at
a low level makes fragmentation an issue or not,
but it was installed (Knoppmyth R5B7, Myth 0.19) from scratch (not
upgraded), less than 3 weeks ago.

Thanks

On 4/2/06, Robert Johnston <anaerin at gmail.com> wrote:
>
> On 4/2/06, Ambrose Kofi Laing <aklaing at gmail.com> wrote:
> > Hi Everyone,
> >
> > first post here.  I have a problem with mythcommflag.  Somehow when it
> runs,
> > encoding (by PVR-350) seems to include artifacts.  Playback has lots lof
> > little split-second
> > freezes.  There is no problem at all if I switch things off so that
> > mythcommflag does
> > not run while recording.  Its an underpowered PC I know.
> >
> > I know mythcommflag runs nice (17), but that seems to still not be good
> > enough for
> > not interfering with other processes.
> >
> > I also know it is possible to set up a window of time during which
> > mythcommflag can run,
> > and no jobs will be initiated outside this window.   That works best if
> > there is a window during
> > which I never want to record any shows.  However some of the shows I
> record
> > are sitcom
> > reruns that run at all sorts of odd hours.  If I could keep these
> windows
> > disjoint from the
> > recording sessions, that would be great, but the interface is obviously
> > designed so that you
> > set the mythcommflag window once and leave it alone.
> >
> > So my suggestion is that if possible mythcommflag should be designed to
> be
> > able to dynamically adapt
> > its operation to run outside the recording and playback sessions.  That
> is,
> > when any recording
> > or playback is happening, mythcommflag will not run, and when nothing is
> > happening, we don't need
> > to tell mythcommflag to run, it just kicks into gear on noticing the
> silence
> > and does what it has to do.
> > The goal is to have mythcommflag automatically know what the recording
> > schedules are and what the
> > users' viewing activity is, and know how to stay off the radar in those
> > times.  If this can be arranged,
> > then mythcommflag can run with no high nice setting, just barge through
> the
> > job and be done with it.
> >
> > One way I was thinking of doing this (preferably without touching any
> source
> > code for right now),
> > is to misuse the commands for turning the machine off and on when
> nothing is
> > happening.  It is intended
> > for shutting down and waking up, but can we use those hooks to instead
> > enable and disable
> > mythcommflag?  That way, whenever the machine thinks it is safe to go to
> > sleep because no recording
> > or viewing is happening, it will instead permit mythcommflag to
> run.  And
> > when it thinks it is time to come
> > back on, it will instead disable mythcommflag.
> >
> > Any reactions welcome -- either on how to get this implemented as a
> standard
> > feature, or how I
> > can configure my own installation to have that behavior with the minimum
> of
> > work.
>
> Personally, I think having the commflag nice(17)'d already achieves
> this. It's set below everything that could possibly be causing
> artifacts like this (Including Mythbackend and IVTV). However, if your
> HDD is running in a PIO mode (Without DMA), or if your FS is extremely
> fragmented, it could be that the FileSystem is blocking as it changes
> from a write of the current recording to a read of the commflagging
> file. Check that DMA is enabled, and that your FS is running properly.
> In thoery there should be more than enough bandwidth on even the
> oldest IDE hard-drives to cope.
>
> If your system is already DMA'd, then chances are you're running a
> very slow system, and perhaps commflagging should be completely
> disabled. You say the system is "Underpowered"... just how
> underpowered are we talking here?
> --
> Robert "Anaerin" Johnston
> _______________________________________________
> mythtv-dev mailing list
> mythtv-dev at mythtv.org
> http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mythtv.org/pipermail/mythtv-dev/attachments/20060403/d19efbe5/attachment.htm 


More information about the mythtv-dev mailing list