Whoops, that's my fault, I used roots ability to run MySQL DB queries without giving a user name and password. It's easy to fix. Just add the login information to each of the mysql commands.

OK, that's fixed now... I still want to add some refinements like making the time range configurable and possibly adding some output controls (verbose versus silent or the like) but other than that I suspect that this is usable.

OK, the production ready version of idle.sh is now available from the wiki. Click the link to get it: Download idle.sh

Looking through the script I get the general gist of what is being done. I am just not sure how to implement it with/into a backup cron job.

_________________
-Roseville, Michigan USA
LinHES R8: FE/BE, FE (x2)

This is what I have in my /etc/crontab:

This runs my backup on Su, Tu, Th, Sa at 3:10a.

_________________
Tim

LinHES 8.4
HDHR3
BioStar A770, AMD X2 4050e, 2GB RAM
GigaByte GeForce 8400, Chaintech AV710
USB-UIRT

I do have a question about the "inuseprograms" table. Mainly, what does it show? Currently, as far as I know, none of my Myth PCs are doing anything, and my "inuseprograms" has one entry. The single entry is for a recording that finished about 45 minutes ago. So, when will that entry be removed?

_________________
Tim

LinHES 8.4
HDHR3
BioStar A770, AMD X2 4050e, 2GB RAM
GigaByte GeForce 8400, Chaintech AV710
USB-UIRT

Could it be commercial flagging or a transcode job?

I checked and commflag is not running, and I haven't even looked at this new recording, much less configured it to transcode. Also, the "lastupdatetime" field contents show almost an hour ago. Additionally, that time is also almost an hour after the show finished recording. Guess it's just a housekeeping issue. Just would hate to have the backup not run just because I recorded something two hours ago.

And now it just updated again at the top of the hour. Though the recording finished two hours ago.

Hmmmm.

_________________
Tim

LinHES 8.4
HDHR3
BioStar A770, AMD X2 4050e, 2GB RAM
GigaByte GeForce 8400, Chaintech AV710
USB-UIRT

The script is intended to be called from your crontab command as described in detail here: http://knoppmyth.net/phpBB2/viewtopic.php?t=18000

Another approach would be to set up a loop something like this in your script:


As Cecil indicated, active recording, watching, commercial flagging, transcoding, all get listed in the inuseprograms table.

Hmm, The entry is still in my "inuseprograms" table, some 18 hours later. So I opened "Live TV" on my PC, and closed it almost instantly. And now the entry is gone. I may need to check this tonight after my next program records and verify that this table is getting cleaned up properly on my system.

_________________
Tim

LinHES 8.4
HDHR3
BioStar A770, AMD X2 4050e, 2GB RAM
GigaByte GeForce 8400, Chaintech AV710
USB-UIRT

Yeah, that's not normal. On my system it tracks usage very closely. If you're watching a program it shows up there. If you're recording something it shows up there. If the system is commercial flagging or transcoding it shows up there. When any of those end the entry goes away. I've got a _few_ patches from the 0.20-fixes SVN branch applied on top of the vanilla R5F27 (mostly to .php files) but that's it.

FYI, I just noticed that the idle.sh script will still return a "planned recording" even if there is a Conflict and not really going to record. Again not a show stopper, but just a little odd.

The technique used to scan through the output of mythbackend --printsched is a bit crude and the safety margins at the beginning and end of recordings may contribute. Here is what the code does, maybe somebody can come up with a simple approach that is more robust.

- Take the count of recordings that overlap the window of interest from the DB query as an input.
- Use that count to isolate the first N items in the printsched output.
- Check those items for an assigned tuner number indicating a real recording.

One of the things I was trying to avoid was parsing times, as that's a notoriously miserable business. The other thing I wanted to avoid was having to capture the upcoming schedule matches rather than a simple count. There are cases where the algorithm above can err to the side of caution, such as when a recording has just completed, but I figured that was better than the other way...

I have a couple of questions regarding this cron job.

1) Does running mythbackup give the same audio (voice) as if you navigate the menu on the frontend and select backup?

2) Since it is being backed up locally, should a user keep remote copies of this backup too? I have not had any problems where I would need to restore a backup, but the majority of the time is it to fix a configuration problem or to recover a catastrophic hardware failure?

I was just considering adding a separate cronjob to a desktop to copy the backup files once in a while.

BTW, to help other newbies like myself, there is more info about mythbackup here (wiki):
http://www.knoppmythwiki.org/index.php? ... storeHowTo

I tried this out and it looks like it would work great but unfortunately it's grabbing my deactivated upcoming recordings as potential recordings. Even if I do "./idle.sh -t 1" (or even -t .01) it says the system is busy. Any solutions?

md10md - Did you get the latest one from the wiki link, rather than the original one here? There are some tweaks in the newer one that make it smarter...

On the other hand, there are definitely ways that even the newest one is going to get a false positive, and since it errors to the side of caution... <shrug> To get around it you would have to makes the script a lot smarter which also means a lot more complicated.

Finally, if you included the complete output (along with the output of "mythbackend --printsched" it'd be a lot easier to help you troubleshoot your problem...


It runs the same script (mythbackup) so it has exactly the same behavior.


Depends on how serious you are about it. I'd certainly recommend it. That's why my deepbackup.sh script copies everything to a separate disk.