> Andrew M. Kinnard wrote: > > 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 > > Wow, never thought of that (recording the NTSC output of an OTA ATSC > Tuner). Great idea. (Well, I'm trying to unsuccessfully get > my replay > to do this - but that's another thread.) > > More of an explanation than help: As the mediamvp can not > handle HD and > does not synchronize the sound for SD ATSC (well, we've > played w/it, I > don't think anything came of it) most here (actually everyone AFAIK) > plays ATSC recordings on their mvpmc boxes from their myth > boxes through > VLC. As such you don't deal w/channel numbers (more like that whole > (nice) aspect of mythtv is lost). > > So, you and your great idea may be at the cutting edge of mvpmc > development (i.e. no one bothered to debug ATSC channel tuning). > > --- > > A quick look at the code shows an element "channum" of an array of > structures called chanlist being treated like a number. That > hints that > support for numbers like 8_1 is not part of the current code. > > Comments from others?.... > > --- > > So, sounds like you have found a way to contribute to the > project! Jon > has made it very easy to set up the necessary environment and > tools on a > linux box to do development work. I believe others have > crated howtos > w.r.t. this in the mvpmc wiki. > > The easiest way to get code changes in w/o having repo > permissions is to > do a "git" type diff and post the output in the mvpmc's > developers list. > (OR, you could do it here, but that would confuse some people.) > > FYI, until we implement a plug-in architecture, the project > is somewhat > space strapped on the target hardware. We can make bug fixes and add > this and that. But don't go off adding boat loads of sloppy code. > > --- > > Humm, I'm beginning to warm up to your idea, I might have to > go out and > buy another OTA ATSC tuner today! >
I'm not understanding the code (and have no C experience) to contribute probably. I would be interested in anyone who can provide an overview of the channel change (from the program guide) process...anything that might help me figure out why my unit is asking for these channels on the wrong tuner/source. BTW, I've never seen tuner offerings/switching some users say you get in the menu resulting from pressing the "info" button when running LiveTV or in the program guide. I don't know whether that's related. I really didn't think this would be very out-of-the-box to use an OTA DT converter box this way. I am aware that the mediamvp is very memory space strapped; I'd not want to clutter up the code with anything I might turn out. 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/
