Have you considered migrating to the mythtv services API ?

[brandon-dacrib]

http://www.mythtv.org/wiki/Services_API

[rshendershot]

a lot of discussion about this, especially concerning real-time display of mythTV on the Roku. I'm not so much interested in that but there are architectural concerns. I'm a Java/J2EE/.NET developer and happy to help with backend, testing, docs, etc... But I need to "feel it", feel me?! ;)

My primary goal would be to assure that some change in MythWeb doesn't kill this channel, and secondarily to make a new public channel that is current with the direction and philosophy of MythTV, AND is as easy to install as possible. I'd consider myself "capable" with Brightscript but really haven't done much except testing in that.

In the best of worlds, my expectation is that the result is adopted by MythTV devs in some official form. I think a MythTV Clients packaging is already being discussed so it just means that we're ready when they are.

[krisbee]

The real issue is that for the most part, most distros are a little funky when it comes to myth installs and not everything works right out of the box - this isn't a mythroku issue but a myth in general issue - it is a kludge and uses lots of pieces to make things happen. It follows that the mythroku channel follows that... I am amazed at how simple it is to get working at all - my issues were all related to my distro and not mythroku... Having said that, I have no need to upgrade my myth system and plan on staying at .23.5 for a long time - it works and the last thing I want to do is potentially destroy a good thing.

We use the channel daily and are quite happy with the way it works - wish the resume playing button worked (or was absent if it doesn't ever work for anybody), but that is a minor quibble. I am always around to try and help with the limited knowledge I have, and again, we are so grateful for the channel - it was the final nail in the satellite coffin for us and we have saved $1400 to date so far by cutting the cord.

I think HLS support along with the mythroku.sh script is the only real way to make things fairly easy to setup/user friendly... but transcoding will still need to be done. Then people can delete the content via their phone/web with their mythweb setup... But with saying that, then there really is no need for the mythroku channel except for the script that helps transcode and repoint the database to the correct file.

[krisbee]

I should have also said DLNA also would be the future, but that is on Roku's side and so far is unlikely to happen...

[brandon-dacrib]

I disagree with you krisbee for a number of reasons that I outlined here: http://forums.roku.com/viewtopic.php?f=28&t=33704&p=378444&hilit=mythtv#p378444

Mainly, the mythtv developers worked to provide the services API to remove the need for just the kludge like solution that you described. I also think that the services API provides all of the bits needed for HLS via realtime transcoding.

http://www.mythtv.org/wiki/Content_Service

I think any solution that the community would go for would not leave users like yourself that have not upgraded in the dark. You could continue to use what you have, and when you did get around to upgrading then a more seamless solution without as many parts would be available to you. A use case that I imagine would be simply installing the public "mythroku2" channel, pointing it to your mythbackend and rolling forward. No need for transcoding, or managing the transcoded files separately because all of those bits are built into mythtv now. Again, if you wanted to do things that way ... thats fine.

I am a linux admin, I have a working .25 backend for testing, and while my brightscript/basic skills aren't there I can help with things like debugging, sniffing packets, testing, documentation, and all of the fun things that a linux admin can do. Also I am motivated, maybe I can get developers to "feel it" :)

What would a good technical 1st step be.. getting a single file to play on the roku via the services api, and documenting how that got done?

[rshendershot]

I've been waiting for cpinkam to check in with plans from the MythTV side of things. There was already an effort started to refactor this code. just wanted to let you know this not forgotten.

[brandon-dacrib]

Awesome. Thx for the update.

On Apr 27, 2013, at 7:28 AM, rshendershot wrote:

I've been waiting for cpinkam to check in with plans from the MythTV side of things. There was already an effort started to refactor this code. just wanted to let you know this not forgotten.

— Reply to this email directly or view it on GitHub.

[rshendershot]

I haven't heard anything more about service-based code porting.... I and Zane have begun so please have a look at Zane Dev and my master (myth 0.24--26 compatible).

[brandon-dacrib]

nice!

[rshendershot]

my dev branch now removes the deps on mythweb and uses several of the services. For v0.25 and later for technical reasons.

Open to suggestions for replacement for PHP.ActiveRecord. Needs to be available on many many linux distros. Needs to support php object relational mapping and arbitrary SQL statements.

Otherwise I will need to refactor to use the Video XML from the MythTV Services implement some custom services as I have for jobqueue (yes it probably should query inuseprograms not jobqueue that's another todo)

comments most welcome!

[brandon-dacrib]

That is excellent news! My projector bulb died and I can't test this yet (dammit), but I do work with a group of talented php developers and asked them about a replacement ORM for you. I will reply here once they get back to me. Good work man!

[rshendershot]

Thank you very much! another bit of news- I just added a current weather conditions top menu item. The next time I'm watching a show and the thunder crackles, it'll be nice to be able to quickly check conditions. I don't know if this supplier will include warnings yet but it was just a proof of concept really.

[brandon-dacrib]

Straight from my co-worker: Doctrine (http://www.doctrine-project.org/) and Propel (http://propelorm.org/) are the most popular ORMs. I've worked on a project that uses Propel. The general consensus is that Doctrine is superior, but I don't have any experience. I'm not a superfan of ORMs in general, but I didn't have any problems with using Propel.

Doctrine 2 uses the Data Mapper pattern, whereas Propel uses Active Record. So to avoid Active Record I would recommend Doctrine 2 - it also has a more active following.

[rshendershot]

thanks! I had a look at Doctrine. My initial reaction was that either that or Propel are going to be more, or just as, complicated. Ubuntu packages what appears to be 1.2.4 version. Just a quick look.... But it made me think the goal should be to use Myth services to replace the ORM. I'll have more time to look into it tomorrow but I wanted to let you know I'd gotten this. tx again.

[brandon-dacrib]

Actually I can get behind that second thought. The goal REALLY SHOULD be to use the services api to remove the need to use an ORM. Once again, thanks for your hard work.

[rshendershot]

I finally caught up with Chris Pinkham and he sent me a tar of the player UI modifications and the backend services code. Unfortunately the changes to MythTV that make these .qxml valid server side scripting sources are not part of 0.26-fixes. It's also unlikely that HLS on-demand encoding will make it into 0.27.

[brandon-dacrib]

Where did that bit of information come from? The instructions here for adding a live stream seem to work for me. http://www.gossamer-threads.com/lists/mythtv/users/525602

I am using: root@hostname:~# apt-show-versions mythtv mythtv/raring uptodate 2:0.26.0+fixes.20121118.340b5d4-0ubuntu1

[rshendershot]

as I understand it Chris intends On-Demand to allow for rewind and start-at-x and won't require setting up streams that later have to be removed. I'm a little hazy on this but I think the implication is in watching LiveTV. Here's what he actually told me. Sorry for any confusions...

"...commit-binge tonight pushing everything out of my on-demand HLS branch except for the HLS encoding portions themselves..."

and in a later reply: "I actually had a Roku patch at one point that did use the existing HLS start/stop/delete-stream API commands, but it was clunky...."

[cannino]

@rshendershot @ear9mrn @brandon-dacrib @zane131 @cpinkham I realize this repo/issue hasn't been touched in a number of years, but I wondered about the live tv feature. There are so many different forks to this project it's hard for me to tell which to install. Has everyone bailed on that idea and resorted to using Kodi as a frontend? Which fork is furthest along in a feature set? is it still necessary to transcode recordings so they play nicely on a roku?

I have a working Mythtv 0.28.1 running on Ubuntu 17.04 with a Hauppauge winDualTV tuner. I also have ear9mrn's version of mythroku running, though I haven't configured my mythtv-backend to transcode to a proper mp4 format using the encode script. I would appreciate any updates you may be able to provide.

[krisbee]

At some point mythrokuplayer just failed for me. Left a few messages on the roku forums but never heard anything. No idea what upgrade just caused everything to break, but I ended up moving to Plex to serve my mythtv to my roku. I still use the scripts to transcode shows I most likely will want to watch, but if I don't, it will transcode on the fly for me, which is handy. No need to use the LiveTV, so I never looked any further into that. As for a frontend, a rpi3 work good with mythtv-light now that they solved the judder issue that bothered only me in my household... So in the end, I only have the scripts (and what I modified from them) left from these forks and ended up deleting the mythroku channel.