<div dir="ltr">On Sun, Oct 14, 2018 at 11:34 AM Bill Meek <<a href="mailto:keemllib@gmail.com">keemllib@gmail.com</a>> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 10/13/2018 12:17 PM, John P Poet wrote:<br>
> Good to know. I had not thought of retrieving a template first. That<br>
> seems like a good approach.<br>
> <br>
> Has anyone written a set of python tools for controlling Myth with the<br>
> services API, that has been published somewhere? The documentation is<br>
> currently somewhat sparse, and examples might be helpful.<br>
<br>
Hey John,<br>
<br>
This was my attempt at a cookbook. It builds up from simple examples to a<br>
full program with arguments. Since I don't speak fluent Python, I wanted<br>
to show how to use the returned values from the API (and I'd guess that<br>
you were using some of it.)<br>
<br>
<a href="https://www.mythtv.org/wiki/Python_API_Examples" rel="noreferrer" target="_blank">https://www.mythtv.org/wiki/Python_API_Examples</a><br>
<br>
I've been looking at putting the Python Services API *next to* the existing<br>
Python bindings. That's where mine is installed. I'm not clear on how to<br>
incorporate it into the build process.<br>
<br>
Unless we're living in parallel universes, you're using<br>
<br>
<a href="https://github.com/billmeek/MythTVServicesAPI" rel="noreferrer" target="_blank">https://github.com/billmeek/MythTVServicesAPI</a><br>
<br>
and that was my idea of a tool. My original plan was to create a library of<br>
things that could be imported. Like: Capture.py/Content.py/Guide.py...Video.py.<br>
Plus one Connection.py that the others used.<br>
<br>
But they were essentially the same, all returning a dictionary with the returned<br>
parameters. And so the more generic backend.send(...) is what I decided on.<br>
<br>
I do have a tool just for testing (cleverly named 'api') and it's --help looks<br>
like this:<br>
<br>
$ api --help<br>
usage: api [-h] [--debug] [--digest <user:pass>] [--host <host> [<host> ...]]<br>
--endpoint <ep> [--noetag] [--nogzip] [--oneline] [--port <port>]<br>
[--postdata <pd> [<pd> ...] | --rest <rest> [<rest> ...]] [--quiet]<br>
[--timeout <seconds>] [--usexml] [--version] [--wrmi]<br>
<br>
Services API Tester<br>
<br>
optional arguments:<br>
-h, --help show this help message and exit<br>
--debug output additional information (False)<br>
--digest <user:pass> digest username:password<br>
--noetag tell the backend not to return a ETag (False)<br>
--nogzip tell the backend not to return gzipped data (False)<br>
--oneline print the response on one line, no formatting (False)<br>
--port <port> back/frontend port (6544)<br>
--postdata <pd> [<pd> ...]<br>
Tag=Value *<br>
--rest <rest> [<rest> ...]<br>
Tag=Value *<br>
--quiet don't print any responses (False)<br>
--timeout <seconds> seconds to wait for a response (10)<br>
--usexml ask for an XML response (False)<br>
--version show program's version number and exit<br>
--wrmi allows postdata to be sent to the server (False)<br>
<br>
required arguments:<br>
--host <host> [<host> ...]<br>
server hostname(s) or IP address(s)<br>
--endpoint <ep> endpoint to test<br>
<br>
* E.g. Id=1 TitleRegEx=\*News\*. Default values are in ()s.<br></blockquote><div><br></div><div>Hi Bill,</div><div><br></div><div>Yes, I am making use of those tools that you have written. They are a huge help -- although I had not noticed your `api` application, and will need to check it out.</div><div><br></div><div>It is a challenge to document "best practices" for each possible API call (e.g. retrieving a template to use for creating a new recording). I was just wondering if anyone had used the Services API in a fairly complete application, that acted as a good example.</div><div><br></div><div>Thank you,</div><div><br></div><div>John<br></div><div><br></div><div><br></div></div></div>