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! ------------------------------------------------------------------------- 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/
