On 4/02/2012 5:02 p.m., Nick Rout wrote: >> End user desirement.
> I am surprised everyone in your house wants to watch the same thing at
> the same time, with pauses governed by one user.
Seems a bit of a jump from the subject, which was intended to be more
about multi-casting and less about noisy frontends. With the benefit of
hindsight it might have been better to not refer to noisy frontends, my
apologies for the noise. >The very antithesis
> of what mythtv is all about.
For me mythtv is an open source effort that evolves with user / dev
input. I'd need persuasion that using mythtv in a way it does not
currently do, yet is capable of doing, is not what its all about, seems
quite the contrary reality for me. To add to my case I also observe the
paradigm shift "requirement" that mythtv is, that mythtv is designed
that one does not watch live tv exemplifies that paradigm shift is what
mythtv is about, and for me it is not necessarily limited to that single
mind change. There are some things best viewed live. World cup finals
come to mind. Of course its best to record the final, watch it largely
live (with minimal delay) yet with the ability to pause/rewind
etc....While this is a significant aspect of mythtv its, for me anyway,
not the holy grail or conclusion of mythtv's path forward, which is (for
me) not closed to other paradigm shifts.
The concept is not new and has been considered, even to the extent of
enjoying initial dev coding for this some years ago. Its just, like
many desirements, not publicly implemented successfully yet.
When using the older SD mythtv I did broadcast a mythtv frontend around
the house using a modulator that was relatively affordable. This worked
very well, requiring a tuner device with each display to access. (that
generally meant a SD TV! However in the DVB-T HD world a HD modulator
and HDHomerun would enable any LAN connected PC to view the stream,
should one shell out the dosh for such a beast... some modulators also
include IPTV LAN outputs.) I don't plan to detail use scenarios, except
to note they proved to be more than I initially expected as it was more
flexible than I'd expected, and having lost something I had remains an
itch that demands a cure. > Perhaps if you told us the *point* of the exercise it might make some sense.
As per the title I've been trying to play the same thing on a few
frontends all synced up, (+/- a couple of seconds lag acceptable, -
without necessarily pushing this on everyone in the house) given the
costs, e.g. the price of DVB-T modulators and HDMI splitter
implementation problems, not to mention an existing LAN, multicasting a
frontend seemed a viable, if not the best path forward. If it were a
cheaper noisy frontend in the garage that might have also been fine.
VLC can be easily run to multicast a file and shows / tests whether the
LAN is multicast capable (or not), however getting it to do the display
was not so out of the box, and as has been pointed out there may well be
significant clone quality display issues with HD video.
I've since considered the frontend control socket, so it may be I can
use that to instruct a few frontends, while minimising LAN traffic. http://www.mythtv.org/wiki/Frontend_control_socket
gives an overview
including apps already accessing the socket. Any of those apps might be
adapted to do the above. http://nowsci.com/mythmobile/
absent from the list of apps.
So far the best way I can see to do this for me would be writing a
webpage to link in with mythweb to do this. One could then access this
from wherever, particularly an android for roaming control. Pausing etc
would have to be done from that page to keep the sync up. If there was
too much time drift a resync with the chosen frontend could be easily
An intial play with the socket (LAN IP's subs with x.x.x.x) shows it
does things like: # query location
Playback Recorded 00:37:16 of 01:04:09 1x 1001 2012-02-05T21:29:00 55904
myth://x.x.x.x:6543/1001_20120205212900.mpg 25 # play file myth://x.x.x.x:6543/1001_20120205212900.mpg
mythtvnz mailing list