[mythtv-users] ensuring mythbackend will be idle for db optimize

[Jerome Yuzyk]

On Thursday, September 24, 2015 09:05:59 AM Philip Brady wrote:
> 
> > MythShutdown is the workhorse for most of what matters "in-progress": recording, commflagging, and transcoding. Things outside that are less-distinct, though MythShutdown may be doing more than I can see from its public docs. Watching a recording (I skip a lot) is probably the most DB-active activity left. Maybe importing music/videos, but I don't use them to be able to test.
> > 
> > Then there are things that are coming up. Avoiding an upcoming recording (only the first matters generally) is easy, avoiding an upcoming MythFillDatabase less so and is a hack just for me (or others using the defaults) right now. 
> 
> I would have thought that mythshutdown would have told you all you want to know, but you also ask about the API interface.
> I agree that documentation is sparse - the aims of some of the functions and the significance of parameters is a challenge.
> I have chipped in with it in a minor way and also supplied the Perl examples which may help, but it's far from complete and extra authoring would always be welcomed by the community

As far as I can tell Mythshutdown can only tell me that the backend is busy, though it may know more about what's coming up than I have been able to discover.

And once I got started it looked like I could generalize the whole "is/will be idle" testing for other uses, perhaps like Stephen's storage-balancing, or the remote MythMusic musicscan I generate after a round of ripping CDs that I do on my desktop.

I'd be happy to pitch in on docs but I am still lacking in clue about how it all comes together. Interesting learning though, and a fine winter project. That's why I wondered what part of the source I could read to get the real story for what my version (0.27.4) can do.

For example, I get a different XML return for GetStatus than is shown on https://www.mythtv.org/wiki/Frontend_Service - there was a conversion at some time I guess. I could at best contribute some Wiki janitorial for these kinds of things.
 
> I hadn't tried the frontend calls but they are similar to the channel stuff I have been doing.  
> If you wish to continue the perl route then finding next recording start and frontend status would code simply as:
> 
> #---------------------------------------------------
> #!/usr/bin/perl -w
> use strict;
> use scan_database;

Interesting module. Why do you not use an XML parser? I have to live with hand-rolled XML parsers in modules I use for work, and I happened to find the upcoming_recordings.pl example first and was relieved to see it use a known (though old) parser module so that was my model. Plus a way to learn how to use perl-XML for the future.

But, I gotta say, your tech support is great! :) I'm looking though the update now. Will try it this evening.

-- 
A little of Jerome's MythTV World: http://mythtv.bss.ab.ca