QAM Channel Mapping

[tivo4mevo]

Anyone taken a look at mapping QAM channels to the guidedata of other channels?

Things seems to have changed with series 3, and simply pointing a channel to a station with guidedata doesn't seem to stick. A script to periodically recreate the QAM channel somewhat works, but seems less than ideal.

[ciper]

Can you point me to discussion of the QAM script? I'd love to not pay rent on my cablecards just for local HD stations.

[toy4two]

yes please let me know too where to get this QAM mapping script, how often does the scan, every 24 hours? May not be perfect like you said but good enough for people like me, nice work! :)

[tivo4mevo]

Just to clarify, the script I wrote was based upon add-av.tcl; however, as detailed in this post on tcf (http://www.tivocommunity.com/tivo-vb/showthread.php?p=6123991#post6123991), channelmap.itcl and other tools have existed for some time (in fact, they might be better starting points).

The purpose of my post was to see if anyone else was experiencing what I am: that QAM channels pointed to the guide data of another channel seem to be culled periodically (and result in a "lineup has changed" mail message informing those channels have been deleted).

Before they are deleted, the mapped QAM channels behave as expected (season passes, searches, on-screen guide all work).

[toy4two]

Before they are deleted, the mapped QAM channels behave as expected (season passes, searches, on-screen guide all work).

That is exactly what I've been looking for, my cable company hasn't changed their QAM mapping on the locals (the only package I have) in years so this would be awesome.

[ciper]

Heh, I was even aware of those tools and didn't think to apply them to QAM mapping. Gosh darn you Tivo! :mad: Implement the damn feature officially!

[tivo4mevo]

LineupUpdate (invoked after a phone home) was removing my mapped QAM channels and then sending a Message 62 to inform me of it. I'm unsure why, but possible reasons include

FilterDuplicateChannels detected the QAM mapped channels as duplicates,
lack of a valid headend/lineup and,
my not identifying the QAM Source as "Discovered" (possibly in conjunction with reason 2).
I ended up patching LineupUpdate in tivoapp so that it makes no lineup changes at all, and this seems to have worked (more time will tell). The patch, below, is not recommend for most as it prevents the unit from making other (legitimate) changes to the lineups. For OTA only folks, this might be acceptable, as there should be relatively little channel churn. In addition, it's always possible to temporarily swap back to your original tivoapp and allow a daily call to update your lineups (you might need to recreate your QAM channels aftwards).

For others looking to experiment more with this, alternative approaches to solve the issue might include developing a more selective tivoapp patch, developing a routerplus aware event listener (to drop messages related to your QAM lineup/channels), and experimenting with headends and sources to create some that satisfy LineupUpdate.

A better patch might be possible, as mine is the low-hanging fruit. The routerplus listener would be tricky unless you're already familiar with routerplus, but could offer a more selective mechanism to still allow legitimate lineup changes. Creating a headend and source that makes LineupUpdate happy holds the possibility to map QAM channels on unhacked boxes, but I haven't explored this enough to know whether or not it's feasible.

Note the newer patch below which obsoletes these patches
All Values are Hex

Sw Version Offset (VMA) Original Value New Value
9.2a 0x00b51f20 14400007 00000000
0x00b51f2c 14400005 00000000
0x00b51f38 10400107 10000107

9.3(a) 0x00b6754c 14400007 00000000
0x00b67558 54400005 00000000
0x00b67564 504000f8 100000f8

[tivo4mevo]

Updated the patch to include 9.3(a). More testing shows that the QAM channels still disappear on occasion. Additionally, season passes would default from the QAM channel to the regular channel; marking the regular stations as ones you don't receive seemed to fix that. Clearly still experimental.

[tivo4mevo]

With this more aggressive patch, I've had stable QAM mapped channels for over a month now.
All Values are Hex

Sw Version Offset (VMA) Original Value New Value
9.3(a) 0x00b64b24 27bdff30 03e00008
0x00b64b28 afb200a8 24020000
9.4.L6 0x00b7a2fc 27bdff30 03e00008
0x00b7a300 afb200a8 24020000
The patch prevents all changes to lineups (while the previous tried only to prevent LineupUpdate from dropping channels). As before, you may want to revert to an original tivoapp every so often to allow a daily call to update your channel lineup (then recreate your QAM mapped channels if need be and revert back to a patched tivoapp).

[jt1134]

I just started messing with this tonight since I got a new TivoHD and don't need any more cablecards. I'm curious as to how you actually mapped the guide data to your QAM channels to begin with. You mentioned add-av.tcl as a starting point, did you actually create a dummy channel? If so, how'd you map the guide data to it? All I did was munge the Channel object to change the Number attribute to the one corresponding to my QAM channels.

I haven't had the changes blown away yet, but it seems to work correctly (I can still tune to the SD channels manually also), and I've applied your patches just to be safe. Thanks for those, I wouldn't have known where to start :)

I attached the script I wrote in case it may help someone or if anyone could tell me a better way to accomplish it.

[tivo4mevo]

You mentioned add-av.tcl as a starting point, did you actually create a dummy channel? If so, how'd you map the guide data to it?I created a new SignalSource in /Setup and then created channels for the QAM feeds. When creating those channels, I set the Station to point to the ATSC or Cable equivalent station (i.e., the station with the guide data you want).

The above might be more complicated than need be: it should be possible to just modify the Station for each existing QAM channel (created during the channel scan) to point to a StationTMS with guide data instead of pointing to an Orphan station (also created during the scan). However, my original approach involved automatically recreating the QAM channels when LineupUpdate rubbished them, and isolating them into their own source made that a little easier. With the patches, recreating the channels is probably not necessary.

All I did was munge the Channel object to change the Number attribute to the one corresponding to my QAM channels. After running your script, do you have two channels for "103-5", one with guide data that tunes the analog SD feed and one without guide data that tunes the QAM feed? From looking at your script, that's what I would expect.

You didn't state how many SignalSources with guide data the box has, but your script runs through them all. Judging upon the channel numbering in your script I assumed you have guide data for just analog cable (and then you did a digital channel scan to detect the QAM)? Guide data for ATSC includes whether the program is HiDef or not, which is nice.

[jt1134]

I created a new SignalSource in /Setup and then created channels for the QAM feeds. When creating those channels, I set the Station to point to the ATSC or Cable equivalent station (i.e., the station with the guide data you want).
OK cool. That was how I started out, but I guess I missed something. I could get everything to show up except the guide data. Changing the channel number was simple and worked, so I just left it alone.

After running your script, do you have two channels for "103-5", one with guide data that tunes the analog SD feed and one without guide data that tunes the QAM feed? From looking at your script, that's what I would expect.
There were 2 channels, one with guide data and the other just "??? - TBA". They both tuned to the QAM channel. I just nuked the duplicates through the channel list in the UI and they were gone though.

Judging upon the channel numbering in your script I assumed you have guide data for just analog cable (and then you did a digital channel scan to detect the QAM)?
Correct. I did a channel scan, and then set up a dummy recording on each QAM channel to see how the channel number was represented in mfs.

Guide data for ATSC includes whether the program is HiDef or not, which is nice.
Never even thought of that, thanks for the tip!

[tivo4mevo]

OK cool. That was how I started out, but I guess I missed something. I could get everything to show up except the guide data. Changing the channel number was simple and worked, so I just left it alone.I think a reboot (or perhaps indexing) was required before the program info would show in the guide.

There were 2 channels, one with guide data and the other just "??? - TBA". They both tuned to the QAM channel. I just nuked the duplicates through the channel list in the UI and they were gone though.Bizarre, I would have expected the one with guide data to be analog and not QAM. If they are both QAM, it might be worth removing the patches to see if they stick (as it might allow folks with unhacked boxes to map guide data to QAM channels).

[jt1134]

I think a reboot (or perhaps indexing) was required before the program info would show in the guide.
I tried rebooting, never thought about indexing though. More to play with tonight I guess.

If they are both QAM, it might be worth removing the patches to see if they stick (as it might allow folks with unhacked boxes to map guide data to QAM channels).

I was thinking/hoping the same thing. I forced a call this morning with an unpatched tivoapp, and the guide info for my QAM channels was promptly removed. :(

[toy4two]

thank you so much updating this script.