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

Thu Sep 24 09:05:59 UTC 2015

From: phil.brady at hotmail.co.uk
To: jerome at supernet.ab.ca; mythtv-users at mythtv.org
Date: Thu, 24 Sep 2015 08:17:06 +0000
Subject: Re: [mythtv-users] ensuring mythbackend will be idle for db optimize

> From: jerome at supernet.ab.ca
> To: mythtv-users at mythtv.org
> Date: Tue, 22 Sep 2015 18:16:44 -0600
> Subject: Re: [mythtv-users] ensuring mythbackend will be idle for db optimize
> 
> On Tuesday, September 22, 2015 09:53:38 AM Jerome Yuzyk wrote:
> > 
> > Fortunately MythShutdown can give me an Idle status like MythWelcome would use. 
> > 
> > But I can take a little from https://www.mythtv.org/wiki/Upcoming_Parse.pl to see what might be coming and how soon, and with MythShutdown I can get a fair idea of whether the backend is and will be idle in a dozen lines of Perl so far.
> > 
> > A fair idea. A MythFilldatabase might be looming. And I might be watching or listening on the frontend. Not usually, but I'd like to be complete. So I'm adding that now.
> 
> I tinkered over the afternoon and made something that will report on various "busy-ness" aspects of my setup, to test whether they can be used in production.
> 
>     http://pastebin.com/XpMeBGUm 
>     (expires in 30 days because it'll be better by then)
> 
> 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. 
> 
> 
> These are 3 example test cases, one near, one far, one with the frontend playing a recording. 
> 
> :r! perl % 600
> Checking for Idle now or within 600 seconds (10.00 minutes; 0.17 hours)
>   Backend: -idle-
>   Frontend: -idle-
>   Next Recording in: 9799 seconds (163.32 minutes; 2.72 hours) *
>   Next DB Fill in: 49339 seconds (822.32 minutes; 13.71 hours) -idle-
> ----> N Busy: 0 ----> Decision: IDLE
> 
> :r! perl % 60000
> Checking for Idle now or within 60000 seconds (1000.00 minutes; 16.67 hours)
>   Backend: -idle-
>   Frontend: -idle- 
>   Next Recording in: 9967 seconds (166.12 minutes; 2.77 hours) [BUSY]
>   Next DB Fill in: 49507 seconds (825.12 minutes; 13.75 hours) [BUSY]
> ----> N Busy: 2 ----> Decision: BUSY
> 
> * s/''/'-idle-'/ line 168
> 
> :r! perl % 600
> Checking for Idle now or within 600 seconds (10.00 minutes; 0.17 hours)
>   Backend: -idle-
>   Frontend: [BUSY]
>   Next Recording in: 8371 seconds (139.52 minutes; 2.33 hours)-idle
>   Next DB Fill in: 47911 seconds (798.52 minutes; 13.31 hours) -idle-
> ----> N Busy: 1 ----> Decision: BUSY
> 
> 
> Once this shakes out I'll make it into a test for Go/NoGo for other DB-touching operations, like DB backups. 
> 
> I'm sure it can be tons better, and I would appreciate knowing how. What is the best documentation of the Services API that I can get for my 0.27.4 setup? The wiki can only go so far, I understand, and looks to be behind what I have. Does anyone have more examples of using the API that aren't Google-able?
> 
> -- 
> A little of Jerome's MythTV World: http://mythtv.bss.ab.ca
> _______________________________________________
> mythtv-users mailing list
> mythtv-users at mythtv.org
> http://lists.mythtv.org/mailman/listinfo/mythtv-users
> http://wiki.mythtv.org/Mailing_List_etiquette
> MythTV Forums: https://forum.mythtv.org

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

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;
my $backend ='192.168.2.99';
my  $temp;my %mydata;

ReadBackend($backend.':6544/Dvr/GetUpcomingList', $temp);
FillHashofHash(%mydata, $temp, 'Program', 'StartTime', 'Title');  #ignore duplicates
(my $first) = sort keys %mydata;
print "Next recording is at:  $first\n";

ReadBackend($backend.':6547/Frontend/GetStatus', $temp);
FillHashofHash(%mydata, $temp, 'String', 'Key','Value');
print "Frontend state is $mydata{state}{Value}\n";
#------------------------------------------------------

The module as written will die if the frontend is not running - I'll look at the possibility of running ReadBackend in scalar context next week.

Best wishes
Phil

I have updated ReadBackend and the wiki to allow:

if (ReadBackend($frontend.':6547/Frontend/GetStatus', $temp)){
    FillHashofHash(%mydata, $temp, 'String', 'Key','Value');
    print "Frontend state is $mydata{state}{Value}\n";
}else{
    print "Frontend not running\n";
}
hth
Phil

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mythtv.org/pipermail/mythtv-users/attachments/20150924/78422807/attachment-0001.html>