I don't know where to put this one - so bear with me.

I've got a strange hardware or software problem that results in a dialog box periodically being opened by fvwm. If it stays open for more than a minute or two, fvwm and XFree86 together use up all available system resources, and mythbackend isn't able to record without dropping frames. If it happens while I'm watching, I just mouse over and dismiss the dialog. No big problem. But when I'm not actively watching, the other 95% of the time, I get unacceptably jerky video.

I don't know why it happens. It seems to happen most often when the mouse is bumped, or the keyboard, or when the batteries are low in either . I don't know.

I'm too lazy to try to diagnose the problem -- everything else is working PERFECTLY -- so I decided to implement a brute-force solution: write a script which would invoke top in batch mode, check on the usage of fvwm, and if it exceeds 10%, to kill the process, which results in a restart of fvwm, auto login by user mythtv, and relaunch of mythfrontend. I was going to put the script in root's crontab, to run every minute on the minute. Brute force.

I started writing the script, and had this:

Before I got around to writing the killing code, I decided a little debugging was in order. So I fired it up. This script worked brilliantly when run from the terminal - so I decided to put it into root's crontab to run every minute. The resulting logfile entries show that when cron runs the job, $S is always null. All I get are datestamps.

What am I missing? Can't one run top in batch mode via cron? Or awk? I've specified all paths, and have defined the shell. The script works fine for root user, why not for root user via cron?

On a side note, anyone have any better ideas on my frontend freezing problem?

So instead of taking the time to try and reslove the problem, you've created another issue... Think about it. Just my 2 cents.

_________________
cesman

When the source is open, the possibilities are endless!

Can't say that I disagree with cesman...seems killing fvwm when sick will still yield bad recordings....But to answer the question in the thread...

whenever running a script via cron it is a good idea to capture STDOUT and STDERR into a file. The environment that your cronjobs run in is NOT the same as your login env....specifically .profile is not sourced. you must explicitly set any/all environment var you (or the called programs) need.

I dupliated your script on my box and used the following crontab entry:

The piece at the end is the key

write STDOUT (stream 1) to /tmp/test.log


write STDERR (stream 2) where stream 1 is currently goin


After the job ran, only the date was in the /myth/monitor.log file. However, /tmp/test.log contained:


so add the following to your script and all will be well.

_________________
R5F1 - Dell P4 2.4Ghz 500MB - PVR250 x 2 - GeForce FX 5200 - Onboard sound/NIC 80GB ATA/250GB ATA/400GB SATA

Thanks, khrusher - I'll give it a go, and have no doubt that it'll work.

Can you think of a more elegant way to monitor a particular process' usage stats via cron or a daemon, killing the process if it gets out of hand? Like I said, my approach is brute force. There may even be a *nix utility designed to do just this.

cesman -

You've got a valid point. This is why I posted the issue to the "General Linux" forum, instead of any other user fora. It looked to me that I was having a Linux hacking problem, not something that other Myth users would necessarily be interested in.

I chose this solution because I could implement it over lunch, from work, via secure shell. I have ZERO time at home this time of year to investigate the cause of the problem from home in front of the box. (But I've got lots of time at work... )

I've made it a New Year's resolution to either get to the bottom of it or upgrade to the latest version - I'm still a minor rev behind everyone else. Like I said, everything works PERFECTLY, except for this one... little... thing.

Thanks for all of your work.

if brute force method is what you need, you are probably on the right track.

It you just want to delay the real fix but continue to record, maybe shutting down the frontend when not watching. That may lead to better recordings.

_________________
R5F1 - Dell P4 2.4Ghz 500MB - PVR250 x 2 - GeForce FX 5200 - Onboard sound/NIC 80GB ATA/250GB ATA/400GB SATA

What does this box state? I've been running both MythTV and KnoppMyth for over a year and I've never seem a dialog box pop up.

_________________
cesman

When the source is open, the possibilities are endless!

Does it say

_________________
R5F1 - Dell P4 2.4Ghz 500MB - PVR250 x 2 - GeForce FX 5200 - Onboard sound/NIC 80GB ATA/250GB ATA/400GB SATA

The next time I see the box, I'll pay closer attention. I don't know exactly what it says, but it's the same size and format as the dialog you get if you exit out of mythfontend and left mouse click on the desktop -- red text in grey boxes. If I recall correctly, there are about eight options in the list.

I got the monitor script running - and fvwm started hogging resource again at 2:11 pm. I manually killed the fvwm process about an hour later when I checked the log. Nobody was home, and nothing was recording. I'm running a very vanilla KnoppMyth install R4V4.1.

I'm checking logs to find anything that happened at 2:11p today, and am not finding anything. Is there any way to get the frontend to keep verbose logs by default, without using the "run from xterm" strategy?

_________________
R5Fxx

Home-Brewed Mythic Dragon Clone
200GB WD IDE /myth
2x250GB WD IDE (lvm) /myth/tv

krusher answered this already (kinda)So, from an xtermOf course with KnoppMyth, mythfrontend is ran by KnoppMyth-run. You can modify it to include the above.

_________________
cesman

When the source is open, the possibilities are endless!

I've found in KnoppMyth-run the line

I'll replace this with

and see how it goes.

Looking through all of the various logs in /var/log, I see that the stock KnoppMyth install does a fair amount of logging. I was impressed at the detail for mythbackend. Why did you choose not to implement mythfrontend logging by default? Is there a measurable performance hit? I've seen a dozen times the recommendation to run mythfrontend from xterm to get at the error messages; if messages were logged by default, debugging for the masses would be that much easier.

Thanks again for the help.

_________________
R5Fxx

Home-Brewed Mythic Dragon Clone
200GB WD IDE /myth
2x250GB WD IDE (lvm) /myth/tv

At a guess the answer is simply "disk usage". Stuff being logged via syslog gets rolled over and expired automatically by the system. This is not the case for something you capture by redirecting stdout and stderr. As a result you either need to make arrangements for stopping whatever it is, rolling/expiring the log, and restarting (ugly and possibly disruptive) or redirect stdout/stderr into some kind of fifo and have a seperate process that reads it and does the log rolling (rather fragile).

I didn't think of it at the time I came up with KnoppMyth. In building the MythTV portion of KnoppMyth, I took most of my clues from the MythTV docs. My boxens are rock solid and I don't want the output logged. I'd fully expect everyone's boxen to be solid as well. Once an install (do you research before buying hardware and don't buy the latest and greatest.) is complete and any issues are ironed out the system should be solid and there be no need for the output. But what TJC sound nice so I'll go with that...

_________________
cesman

When the source is open, the possibilities are endless!

cesman -

You raise a great point here that I don't think is emphasised enough: with the right hardware, KnoppMyth "just works". With alternative hardware, it can me made to work.

Noobs to the world of KnoppMyth should be presented with a poll:
a) I'm looking for an appliance, that I can simply set up and use. Therefore, I'm buying hardware that matches the "just works" list.
b) I'm looking for a hobby, to occupy my spare hours during the week and all day on Sundays. I'm looking to learn a lot about Linux and configuring kernel modules. Therefore, I'm buying either the "latest and greatest" hardware, or the cheapest available, depending on my budget. I may or may not get a stable myth box out of this hobby.

There really isn't a viable middle ground.

A year ago, I chose option (b) to save about $200. Over the last year, I've learned a lot about my box, and have come out even if you assume my time is worth about $1 per hour

_________________
R5Fxx

Home-Brewed Mythic Dragon Clone
200GB WD IDE /myth
2x250GB WD IDE (lvm) /myth/tv

Sorry, no such poll. Take a look at the Tier 1, 2, and 3 sections of the the forum. That is why they are there and have been there since I started the forum. They is LinHES, where I describe my hardware and setup. They is the various 'what hardware should I buy' threads... Frankly I think a noobie that buys the latest and greatest and expects to get it working is in for a world of hurt. This may turn them off to Linux. That is not to say that it won't work or it cannot be made to work. Often new hardware doesn't offer any advantages for a PVR (or most other area of computing).

_________________
cesman

When the source is open, the possibilities are endless!

Those who choose KnoppMyth are self-selected to belong to the "a" group of your imaginary poll. The promise of KnoppMyth is a working myth box with minimum hassle. Whose who wish to experiment usually go the route of setting up their own Linux first and then compiling Myth on top. It provides months of entertainment value...

_________________
Do you code to live, or live to code?
Search LinHES forum through Google