I have an mediamvp H4 that works fine with a recent (August or
September) dongle.bin and Mythbuntu 8.04 and a Dish Networks 311 STB.
The dongle.bin.config designates mvpmc MythTV options for -s and -p; so,
the myth protocol is used for all MythTV functions (no designated
ringbuffer mount point).  It's pretty slow to tune LiveTV (getting the
"it's taking an unusually long time..." message before successfully
tuning in), and reboots itself a fair bit, but performs acceptably
otherwise.
 
The problem:  I recently added an RCA DTA800, an OTA DT converter box,
as an input on an analog tuner card on the MythTV backend machine, and
the mvpmc won't play nice with it.  All the channel selection, viewing,
scheduling, etc. works just fine from a regular frontend.  The mediamvp
however, chokes hard on the channels tuned by the DTA800, refusing to
switch to any channel on that tuner card unless all other tuners are
busy.  Even then, it won't perform a channel change on the DTA800 at
all; LiveTV just reverts back to whatever channel was already tuned on
the DTA800.  Again, the channel change script and all other functions
work just fine from any full MythTV frontend.
 
The channel numbers DO have "overlap" with channels provided by Dish
Networks and have the same channel numbers (or at least the numbers
start the same).  For example, one of our local channels is UHF 16 which
Dish dutifully provides as channel 16.  OTA DT for that channel is
aliased as 16.1 and 16.2 (HD and SD channels respectively); the DTA800
wants those requested (via its remote) as 16-1 and 16-2.  If I add the
channels to MythTV in the channel editor as 16-1 and 16-2 (the exact
selections one must make from the DTAs remote control to tune those
channels), they work fine on full MythTV frontends.  In fact, I can name
the channels any number I like (e.g., some unused, high number like
95016 to eliminate Dish channel overlap) as long as the frequency IDs
are set to 16-1 and 16-2.  It appears a regular frontend requests
channel changes from the backend in such a way that the backend sends
the freqid to lircd, not the channel number, but mvpmc must make that
request differently.
 
mvpmc won't tune these channels no matter what number I give them.  If I
call them 16-1 and 16-2, they show up in the mvpmc guide as duplicates
of 16 (i.e., the dash and subchannel number are ignored completely).
The same for 16.1 or 16.2; the dots and following characters are not
displayed.  Worse yet, attempting to tune to these channels yields the
expected progression of screens involved in LiveTV channel change but no
channel change at all.  It doesn't even switch to that tuner (unless all
others are busy).  Named arbitrary high numbers, the channel numbers
display correctly but still won't tune!
 
The symptoms manifest only on the mvpmc; essentially all channel configs
that use the correct freqid for that channel (i.e., what the DTA800
wants as the lircd/IR channel request) work just fine on a regular
frontend, but no configuration seems to work for mvpmc.
 
Any thoughts on debugging this aside from breaking out the sniffer?
 
Why won't it tune those channels no matter what I call them?
 
Why does mvpmc totally ignore non-numeric channel characters (even
dots...I really thought that would work)?
 
Thanks,
Andy


DISCLAIMER:
Nothing in this email shall bind Schaffer & Layher, PLLC in any contract or 
obligation. This e-mail is for the intended addressee only. If you have 
received it in error then please delete it and notify the sender by return 
e-mail. In case of doubt about correctness or completeness of this e-mail 
please contact the sender. Schaffer & Layher, PLLC makes every effort to virus 
check the files available for downloading on the site or send as attachment 
with an email. Schaffer & Layher, PLLC cannot accept responsibility for any 
loss or damage that may happen from the use of downloaded material. We 
recommend that users re-check all downloaded material with their own anti-virus 
software.  Pursuant to requirements related to practice before the Internal 
Revenue Service, this document, including any attachments, was not intended or 
written to be used for, and cannot be used by the taxpayer, for the purpose of 
avoiding U.S. Federal, State or local tax penalties.
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Mvpmc-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/mvpmc-users
mvpmc wiki: http://mvpmc.wikispaces.com/

Reply via email to