<div dir="ltr">On Wed, May 7, 2014 at 10:57 AM, Craig Treleaven <span dir="ltr"><<a href="mailto:ctreleaven@cogeco.ca" target="_blank">ctreleaven@cogeco.ca</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="">At 9:42 AM -0400 5/7/14, Greg Thompson wrote:<br>
</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="">
> On May 7, 2014, at 8:55 AM, Craig Treleaven <<a href="mailto:ctreleaven@cogeco.ca" target="_blank">ctreleaven@cogeco.ca</a>> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
At 12:57 PM +1000 5/7/14, Phill Edwards wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I for one love mythfrontend and have never found a reason to replace it with XBMC.<br>
<br>
But I accept they do different things and there is definitely scope for them to sit side by side on the same machine.<br>
</blockquote>
<br>
The MythTV developers are providing a sanctioned way to write alternate frontends for Myth: the Services API. There are at least three more frontends out there now: MythTV-Android-Frontend, MythExpress and Torc.<br>
<br>
<a href="http://www.mythtv.org/wiki/Services_API" target="_blank">http://www.mythtv.org/wiki/<u></u>Services_API</a><br>
<br>
<a href="https://github.com/MythTV-Clients" target="_blank">https://github.com/MythTV-<u></u>Clients</a><br>
<br>
<a href="https://github.com/Torc/torc" target="_blank">https://github.com/Torc/torc</a><br>
<br>
In addition, one of the developers is working on a wholesale web-based Myth frontend using the Services API. (Eating his own dogfood, so to speak.) The big deal here is that they want to modify the backend and extend the Services API such that Myth's setup and configuration can be done this way.<br>
<br>
Which would be huge. Especially if they can move to an embedded database. As I see it, the biggest thing holding Myth back is the complexity of setting it up. I've run into a number of folks who got stuck on one of the steps of installing, configuring or initializing MySQL and/or configuring Myth. Lots more look at the work involved and flee in panic. Myth may never be a 'one-click' install but it can be a lot easier. Any steps in this direction are a big win.<br>
<br>
</blockquote>
> XBMC can easily be another Myth frontend but they ought to convert to the approved methodology and embrace the Services API.<br>
><br></div><div class="">
The current API has no way to start watching live tv. Additionally I have found The documentation wrong in some cases and not complete in others. It's hard to build a complete frontend on the API in its current state.<br>
</div></blockquote>
<br>
No one said it is feature complete yet...which is part of the reason I made the dogfood comment!<br>
<br>
Why not help move the current state forward?<div class="HOEnZb"><div class="h5"><br>
<br>
Craig<br></div></div></blockquote><div><br></div><div><br></div><div>I would love to, but I am not a QT/C++ dev by any means. I did explore the code and part of the issue is just finding where everything is at in the directory structure.... I am mostly Objective C, Visual Studio.NET. I was trying to write a nice fronted on iOS since Torc on iOS appears to be abandoned. I have Ceton Tuners and was able to write my own LiveTV app in a matter of a couple hours using the Guide API and external applications (PHP, Curl, VLC to transcode the mpeg 2 to mp4 , Apache) but became frustrated with the internal transcoder and streamer, no way to start a live tv stream, and incorrect documentation on the API. (For the record I was attempting to start a custom Recording and then grab that file to stream live tv. The API shows StartTime as one of the fields needed to get to current recordings, but it took awhile to figure out that it is in fact StartTimeTTS or something like that). Not to mention the internal transcode/streaming mechanism seems far worse than VLC in Quality and speed. </div>
<div><br></div><div>I realize some of these issues are outside the scope of the original email. etc.</div><div><br></div><div>Greg</div><div><br></div></div></div></div>