[mythtv] Placeshifting for MythTV?

[Edward Hughes IV]

On Mon, Jan 2, 2012 at 5:08 AM, Mark Kendall <mark.kendall at gmail.com> wrote:

> On 2 January 2012 04:08, Raymond Wagner <raymond at wagnerrp.com> wrote:
> >  Very recently, a replacement
> > transcoding interface was added into the new Services API.  The backend
> > now supports chunked transcoding and streaming, currently demo'd in
> > videos of an iPad application being written by Robert McNamara.  A new
> > HTML5/flash frontend to this is planned for MythWeb for the 0.25 release.
>
> IMHO this is the way to go. The HTTP live streaming API allows you to
> adjust the transcoded video size and bitrate and, depending on the
> remote app (e.g. iOS) you are free to seek anywhere within the
> transcoded portion of the stream. If you were still interested in
> using a full featured frontend and wanted to tinker with the code, I
> would suggest looking at adding http live streaming support to
> mythfrontend. This would give you a local frontend, 'optimised' video
> transfer and would no doubt be a useful feature to have regardless
> (e.g. mythnetvision).
>
> regards
>
> Mark


Given that I have a modest HTPC environment with 400+ movies and 1000+
television episodes, some might say that I don't respect copyright laws.  I
just feel that personal consumption should be exempted, but I think that
Raymond's legality points are more than valid.  Most of us realize that the
Cable-Cos and MAFIAA would dis-approve of us making "unauthorized" (HD)
recordings in our own home, let alone providing the possibility to easily
share them geographically (whether that is the intended use or not).

Sorry for that.  I felt I had to put some disclaimer out there...

That said, I have cobbled together, with perl and bash scripts only, a
remote frontend setup that allows me to view my recordings at my school at
apartment while my master (recording) backend is located at my parents'
home 100+ miles away.  I have a persistent VPN connection between the two
networks for database access, but not the streaming.  A short perl script I
have written queries the master's XML file on port 6544 and parses the
current recordings.  It uses this to create an --exclude string for an
rsync-over-ssh command that is then executed in a screen session for easy
monitoring.  I use the mythbox script for XBMC to watch the then "local"
recordings from my personal file server because it only needs database
access and a path to the recordings directory (thus, it doesn't directly
stream from the backend if you so choose).  I originally planned to setup a
Master-Slave MySQL situation, but since this first attempt has worked so
well for 5 months, I'm not going to mess with it anymore.

It's not perfect, in that it might take more than real-time to transfer the
recording to my local server, and sometimes my VPN is flaky.  The benefit
is that I only have to transfer once.  It's a DVR, so I'm not ever watching
things as they air anyway.  I have Comcast 25/25 service, but don't get
near that except at 3am or later; the master is on FIOS 25/25 and always
gets that.  Most of the time it takes about 20-25 minutes to transfer a 30
minute HD-PVR recording - so an 8:00 sitcom is usually ready to watch by
9:00.  My Comcast bill is still cheaper than the least expensive
internet/digital cable combo, so I feel I'm making out in the end for the
less than one year that I am living here to finish my degree.

All this for less than 60 lines of perl/bash code.

Since the topic was open, I just wanted to share for a "it can be done,
kind-of" example.  This may or may not be what Stewart was looking for.
 I'm sure that some of you are more capable and creative than I, but as has
been mentioned I don't see this ever being a supported "feature" due to the
reasons already discussed.

Thanks to all the devs' hard work!  MythTV f*&#ing rocks!  This sweet setup
would not have been possible otherwise.

-Edward
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.mythtv.org/pipermail/mythtv-dev/attachments/20120102/6bf2c0c2/attachment.html