<html>
<head>
<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 12pt;
font-family:Calibri
}
--></style></head>
<body class='hmmessage'><div dir='ltr'><br><br><div><hr id="stopSpelling">From: phil.brady@hotmail.co.uk<br>To: jerome@supernet.ab.ca; mythtv-users@mythtv.org<br>Date: Thu, 24 Sep 2015 08:17:06 +0000<br>Subject: Re: [mythtv-users] ensuring mythbackend will be idle for db optimize<br><br>
<style><!--
.ExternalClass .ecxhmmessage P {
padding:0px;
}
.ExternalClass body.ecxhmmessage {
font-size:12pt;
font-family:Calibri;
}
--></style>
<div dir="ltr"><br><br><div>> From: jerome@supernet.ab.ca<br>> To: mythtv-users@mythtv.org<br>> Date: Tue, 22 Sep 2015 18:16:44 -0600<br>> Subject: Re: [mythtv-users] ensuring mythbackend will be idle for db optimize<br>> <br>> On Tuesday, September 22, 2015 09:53:38 AM Jerome Yuzyk wrote:<br>> > <br>> > Fortunately MythShutdown can give me an Idle status like MythWelcome would use. <br>> > <br>> > 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.<br>> > <br>> > 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.<br>> <br>> 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.<br>> <br>> http://pastebin.com/XpMeBGUm <br>> (expires in 30 days because it'll be better by then)<br>> <br>> 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.<br>> <br>> 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. <br>> <br>> <br>> These are 3 example test cases, one near, one far, one with the frontend playing a recording. <br>> <br>> :r! perl % 600<br>> Checking for Idle now or within 600 seconds (10.00 minutes; 0.17 hours)<br>> Backend: -idle-<br>> Frontend: -idle-<br>> Next Recording in: 9799 seconds (163.32 minutes; 2.72 hours) *<br>> Next DB Fill in: 49339 seconds (822.32 minutes; 13.71 hours) -idle-<br>> ----> N Busy: 0 ----> Decision: IDLE<br>> <br>> :r! perl % 60000<br>> Checking for Idle now or within 60000 seconds (1000.00 minutes; 16.67 hours)<br>> Backend: -idle-<br>> Frontend: -idle- <br>> Next Recording in: 9967 seconds (166.12 minutes; 2.77 hours) [BUSY]<br>> Next DB Fill in: 49507 seconds (825.12 minutes; 13.75 hours) [BUSY]<br>> ----> N Busy: 2 ----> Decision: BUSY<br>> <br>> * s/''/'-idle-'/ line 168<br>> <br>> :r! perl % 600<br>> Checking for Idle now or within 600 seconds (10.00 minutes; 0.17 hours)<br>> Backend: -idle-<br>> Frontend: [BUSY]<br>> Next Recording in: 8371 seconds (139.52 minutes; 2.33 hours)-idle<br>> Next DB Fill in: 47911 seconds (798.52 minutes; 13.31 hours) -idle-<br>> ----> N Busy: 1 ----> Decision: BUSY<br>> <br>> <br>> Once this shakes out I'll make it into a test for Go/NoGo for other DB-touching operations, like DB backups. <br>> <br>> 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?<br>> <br>> -- <br>> A little of Jerome's MythTV World: http://mythtv.bss.ab.ca<br>> _______________________________________________<br>> mythtv-users mailing list<br>> mythtv-users@mythtv.org<br>> http://lists.mythtv.org/mailman/listinfo/mythtv-users<br>> http://wiki.mythtv.org/Mailing_List_etiquette<br>> MythTV Forums: https://forum.mythtv.org<br><br><br>I would have thought that mythshutdown would have told you all you want to know, but you also ask about the API interface.<br>I agree that documentation is sparse - the aims of some of the functions and the significance of parameters is a challenge.<br>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<br><br>I hadn't tried the frontend calls but they are similar to the channel stuff I have been doing. <br>If you wish to continue the perl route then finding next recording start and frontend status would code simply as:<br><br>#---------------------------------------------------<br>#!/usr/bin/perl -w<br>use strict;<br>use scan_database;<br>my $backend ='192.168.2.99';<br>my $temp;my %mydata;<br><br>ReadBackend($backend.':6544/Dvr/GetUpcomingList', $temp);<br>FillHashofHash(%mydata, $temp, 'Program', 'StartTime', 'Title'); #ignore duplicates<br>(my $first) = sort keys %mydata;<br>print "Next recording is at: $first\n";<br><br>ReadBackend($backend.':6547/Frontend/GetStatus', $temp);<br>FillHashofHash(%mydata, $temp, 'String', 'Key','Value');<br>print "Frontend state is $mydata{state}{Value}\n";<br>#------------------------------------------------------<br><br>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.<br><br>Best wishes<br>Phil<br><br><br>I have updated ReadBackend and the wiki to allow:<br><br>if (ReadBackend($frontend.':6547/Frontend/GetStatus', $temp)){<br> FillHashofHash(%mydata, $temp, 'String', 'Key','Value');<br> print "Frontend state is $mydata{state}{Value}\n";<br>}else{<br> print "Frontend not running\n";<br>}<br>hth<br>Phil<br><br><br></div></div></div> </div></body>
</html>