Changing Channel Mapping Ids Causing Blank Guide

[cncb]

Thanks. I may eventually give in and pay for Schedules Direct to avoid this issue.

[eskimoquin]

Sorry, I meant to reply the other day. I haven't done anything with it yet, but its a solid *maybe*.

To be honest, it's a pain in the arse these IDs are changing. They're not supposed to. I've had a quick look how I could fix, but haven't found a clean place to fix it yet. I'll try to fix it for the next release if I can though.

It has been suggested to identify a channel using the number 28459808 as in:

Code:

    <channel id="I2.28459808.microsoft.com">
        <display-name>2 KCBS</display-name>
        <display-name>2</display-name>
        <display-name>KCBS</display-name>
        <display-name>CBS Affiliate</display-name>
    </channel>

I don't know if that number changes. I'd like to suggest a possibly easier fix.

nPVR seems to identify a channel using the first display-name field. In the case above, that would be "2 KCBS". This is problematic as the number "2" has been known to change. You may notice that the third display-name field is "KCBS" which is the station call sign and, as far as I have seen, does not change.

If this is universal (the third display-name field always has the call sign w/o channel number), then the fix may be to grab the third display-name field to identify a channel.

If it is not universal, then possibly list all device-names found as potential mappings (settings > channels > details); you would see multiple names that would reference the same channel; this may be confusing to some. Alternatively you could make an option that would grab the X display-name to identify a channel.

Thanks for all your work sub.

[eskimoquin]

I wrote a lengthy description of this problem, cause of it, and my work around at the following post:
mc2xml data changing channels (frequencies) cause nPVR TV Guide discrepancies
http://forums.nextpvr.com/showthread.php...crepancies

[sub]

For the next release I have put in a hack which ignores the first part of the channel id if it is in the "I*.xxxxxxx.microsoft.com" form, which should work around the scenario described earlier in this thread.

This is a bug in the mc2xml grabber though. The display ids are not supposed to change. They best fix would be getting the mc2xml author to fix the xmltv files it's generating. NextPVR shouldn't have to do this. It doesn't have to do anything like this for any of the other xmltv grabbers.

[eskimoquin]

OHHHH, its an mc2xml issue. I just assumed it was an issue with the source data. I'll attempt to contact the mc2xml author on the issue.

[eskimoquin]

Following is the reply from mc2xml received today concerning the issue of channel changes in the guide data received from microsoft via their legacy service.

Hello,

Those Digital Channels (*DT) can move on the Legacy service since it
doesn't support ATSC sub channels. They are moving in the MS
listings. I don't think they move around on the newer service since
the channels will be at their proper locations (like 7.1 rather than
30).

Perhaps you can use something like sed (or perl) to match the channel
ID and set the channel number based on it.
(The "38881924" part of "I31.38881924.microsoft.com"), but then you'd
also want to modify the # in the display-name tags which might be more
complicated, but certainly doable. There are more simple examples on
the homepage http://mc2xml.tk/#sed

He states it is a source issue and not an issue with his grabber. I suppose the next step would be to monitor the guide data using microsoft's new service for win7/8. You'd need to donate $20+ to mc2xml (definitely worth it) to get his/her version of the program that accesses it. I'm pretty tight on money at the moment so don't want to jump on it now; maybe it's time to sell all those old electronics I have piled up in the closet ....

Sorry to sub that it is yet another issue with sub channels and virtual channels that has caused this as I understand from another post that those are an annoyance to him.

[mvallevand]

OHHHH, its an mc2xml issue. I just assumed it was an issue with the source data. I'll attempt to contact the mc2xml author on the issue.

The source data was never meant to be used an unofficially and likely unauthorized by EULA manner. The xmltv tv spec calls for the id to be unique and consitant. When it isn't it has nothing whatsoever to do with NextPVR. The suggestion to use sed should work fine until sub's next version is out.

sed.exe -E "s/I[0-9]*.([0-9]*).microsoft.com/\1/g" should extract the unique ID but it also breaks all your mappings at once.

Martin