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

[Philip Brady]

> From: jerome at supernet.ab.ca
> To: mythtv-users at mythtv.org
> Date: Thu, 24 Sep 2015 13:36:04 -0600
> Subject: Re: [mythtv-users] ensuring mythbackend will be idle for db optimize
> 
> 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.
> 
> -- 
Why not a standard parser?  SAX looked understandable but seemed to need a complex call stack to be maintained, and I honestly couldn't understand the other parsers!  They also looked as if they had high memory overheads.  That was my reasoning but I'm probably way off target!Would you like to give a simple example of using an XML parser for the wiki?
On another wiki issue, do you have any views on where effort is most needed with the API pages?
RegardsPhil
 
    		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mythtv.org/pipermail/mythtv-users/attachments/20150926/1117b857/attachment.html>