Andrew M. Kinnard wrote: > > >> -----Original Message----- >> Andrew M. Kinnard wrote: >>> I've captured some mvpmc session traffic while attempting >> to change to a channel from the DTV stb. That stb is on >> tuner 2 on the mythbackend. I'm seeing early queries for >> location information on tuners 1 and 2, but the mvpmc's >> channel change request is erroneously pointed at tuner 1: >>> 39 QUERY_RECORDER 1[]:[]SET_CHANNEL[]:[]17 >>> >>> As you may infer, I've changed this channel's channum to 17 >> (from 16-2). I also set it's chanid to a number within the >> numeric range of known-good channels (that successfully >> change from the mvpmc). (That config still works from full >> mythtv frontends (remote and local).) >>> The mythbackend responds with these log entries: >>> >>> 2008-11-11 10:22:51.159 GetChannelData() failed because it >> could not find channel number '17' in DB for source '1'. >> ...<cut>... >> >> I'm not sure I understand what you mean when you say "set >> it's chanid to >> a number within the numeric range of known-good channels". I >> assume you >> are controlling an OTA ATSC Set Top Box. So, I would not expect a >> channel like 17 but rather a channel like 17_1. >> > > Yes, I am controlling the stb. Channum can be whatever you want: MythTV > doesn't much care what it is as long as it knows how to tune it (by > freqid). Similarly, chanid looks like a key index used across program > and channel tables at least but can also be changed. So, I did have a > channel 16 on Dish with channum=16, chanid=1016, and freqid=16. When I > added 16-2 with the new stb, I originally added it as channum=16-2, > chanid=10946 (assigned automatically by mythbackend channel editor or > mysql itself), and freqid=16-2. Mythtvbackend uses the chanid for most > db lookups, uses the channum for on-screen display of channel, and > freqid for actually tuning the channel. So, you can change channum and > chanid fairly indiscriminately as long as you don't choose values that > conflict with another channel. So, to work around mvpmc initializing > channum as an integer, I set channum=17 for channel 16-2. Since someone > had had a concern about limits on chanid in mvpmc, I changed the chanid > in mythconverg to 1017 since that doesn't conflict with any other chanid > and is well within the range of chanid's that are known to work from the > mvpmc (like chanid=1016 for channel 16 and 1022 for 22). > >> It looks like the channum element of the structure is used in >> mythtv_mysql.c, tvguide.c and mythtv.c. You would have to go >> in and not >> only add things like channum_major and channum_minor but also >> change the >> code to handle the new data. It could be a lot of work >> depending on how >> you go about it. > > I honestly don't think the structure of channum matters since I've > worked around integer limitations using the channel editor. Since the > mvpmc doesn't look at freqid, and the chanid actually is an integer, > that should work around the structural issues with variable typing. > >> I really doubt you can get away w/o changing the code. I am >> assuming the >> above didn't work because the actual channel number in the >> data base is >> 17_1? But I'm only guessing. > > No, the actualy channum is 17. I'll have to look at the wire when it's > channum=16_2 because I saw backend logs that indicated the mvpmc was > asking for channel change to 16_2 (which seems to fly in the face of > what we know about mvpmc treating channum as an integer); but, > regardless, the channum seemed to get passed to the backend as a string. > > So, I think the failure is something the mvpmc does in making channel > change queries in myth protocol (at least for the tuner not currently in > use for the LiveTV session). > > I'm tempted to test that hypothesis by connecting the same Dish receiver > to tuner 2, Composite 1, and setting it up in mythbackend to test > multiple tuner support with otherwise known-working equipment and xml > grabber. I suspect I'd see the same issues with changing to channels on > tuner 2 despite channum, chanid, and freqid all being expected values > (i.e., all integers). > >> (As a hack, you might try a quick fix where you append "_1" >> to all mysql >> queries. That might get you access to information about the first >> channel in a broadcaster's set of channels.) > > I can see the mysql queries and responses. Those all return the correct > data for both tuners. Program data appears in the tv guide for channel > 17. > > It's the myth protocol queries that are very obviously wrong. > >> I remember posts here about mvpmc having problems accessing multiple >> tuners. But I don't use my mvpmc boxes for live TV so I >> don't know if >> that was resolved or not. > > Anyone have any input on LiveTV and multiple backend tuners? > > I actually think that is the root problem area, not the DTV stb. I > think this because the only problem I see on the wire is that the mvpmc > queries the wrong tuner for channels on the second tuner card; > everything else looks just fine. > > Thanks, > Andy
Hi Andy... Unless you've gotten some off list help it appears not many are trying to solve this problem.** I only have 1 NTSC tuner. All the others are ATSC. And I've never tried to set up VNC for live TV from the ATSC tuners to the mvpmc box. I'm not even sure that's possible. I poked around in the users list and found "stinga" asking the same questions and not finding an answer back on 20080122. I didn't check the mvpmc developers list. I've to many things going on to commit to looking into this. But I'm thinking when NTSC broadcasts stop people might feel compelled to make use of their NTSC tuners using SetTopBoxes. So, should a developer end up w/multiple NTSC like sources on a mythbackend they might have a go at the problem. In the meantime, if anyone wants to post a "git diff" of their efforts I can probably post a private load people can try. Remember, I can't test this as I currently only have 1 NTSC source. **To summarize, you have multiple MythTV NTSC like sources which are receiving their feeds from SetTopBoxes. Your problem is that the mvpmc box can not select anything but the first tuner. ------------------------------------------------------------------------- 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/
