NPVR Fails to Read Information from EPG

[sub]

Can you post the full xmltv file? Regardless of what the channel section at the top of the xmltv file says, from that log I'd only [x] of those channels actually have listings in the xmltv file.

I'm guessing it's an mc2xml problem, or problem with the data it's getting from Microsoft, otherwise we'd be seeing lots of people reporting it from around the world.

[drlava]

Sure, here it is attached.

If the problem were with the listings, how do you explain the fix being a twerk with npvr?

[sub]

Those channels seem to all have listings here.

The only possible things I can see happening are:
- sometimes mc2xml is generating your xmltv file is with different channel id strings, causing the listings to match some of the mapped channel
- sometimes your xmltv file contains errors and it's stopping processing the file part way through.

I'm happy to help you work out the cause, but don't believe its a NextPVR problem since this stuff area of code hasn't changed in like 3 years, and it's been super reliable. I've not seen other reports of problems loading xmltv listings.

When the next release is out, I could give you a patch with a super amount of logging around the processing of your xmltv file, so it tells us clearly why some listings aren't being used. I'm sure it'll be one of the two things I said above. Unfortunately my build isn't compatible with 2.6.2, so I cant give you a patch for the current release.

[drlava]

- sometimes mc2xml is generating your xmltv file is with different channel id strings, causing the listings to match some of the mapped channel

Yes, this is it. See my post 7 here. When new OTA channels are inserted in the lineup, the channel ID string in the xmltv file is changed, but the <display-name> isn't. SO, the 'twerk' fix I mentioned before gets NPVR to re-associate an ID string to the new display-name by 'editing' each channel. All that needs to be done is have NPVR re-scan for display-names when it does a guide update instead of having it rely on the old id string that it grabbed from the initial display-name lookup.

[sub]

No, it shouldn't have to do that. It's just a bug in your xmltv grabber or data source. The whole point of the ids is so that the application rely on the ids not changing, even if the channel name changes.

We've never seen the need for this before from other xmltv users, in all the years of NextPVR, and GBPVR before it.

[drlava]

Hmm, I'm using mc2xml. Here's an example of the change:

Code:

Before:
<channel id="I72.28459581.microsoft.com">
        <display-name>49 MyNetworkTV</display-name>
        <display-name>74 49 MyNetworkTV</display-name>
        <display-name>74</display-name>
        <display-name>KPDXDT (KPDX-DT)</display-name>
        <display-name>MyNetworkTV Affiliate</display-name>
    </channel>

After:
<channel id="I74.28459581.microsoft.com">
        <display-name>49 MyNetworkTV</display-name>
        <display-name>74 49 MyNetworkTV</display-name>
        <display-name>74</display-name>
        <display-name>KPDXDT (KPDX-DT)</display-name>
        <display-name>MyNetworkTV Affiliate</display-name>
    </channel>

The only difference is the id string prefix changed from I72 to I74. I guess the solution is I could write a parser that removes this prefix. Then the ID string will stay the same.
thank you for your feedback.

[BrettB]

No, it shouldn't have to do that. It's just a bug in your xmltv grabber or data source. The whole point of the ids is so that the application rely on the ids not changing, even if the channel name changes.

We've never seen the need for this before from other xmltv users, in all the years of NextPVR, and GBPVR before it.

Sorry to burst your bubble, but I have seen this problem with EPG data coming from Schedules Direct via the xmltv.exe grabber. (See the original post in this thread from 2010. AND I've had this problem happen twice in the last 2-3 weeks. The same work-around "fixes" the problem and gets NextPVR to properly import the EPG data. (from the exact same xmltv data file)

[drlava]

What I've done now is added a line in my updateepg.bat that strips out the changing part of the string (see my post above)

using a command line utility:

http://brett.batie.com/software-developm...-editplus/

and the line:
searchReplace "=\"I\d+\.(\d+)\.microsoft\.com\"" "=\"I.${1}.microsoft.com\"" "xmltv.xml" > xmltvmod.xml
del xmltv.xml
ren xmltvmod.xml xmltv.xml

or

http://rxfind.codeplex.com/
rxfind "xmltv.xml" /p:"=\"I\d+\.(\d+)\.microsoft\.com\"" /r:"=\"I.${1}.microsoft.com\"" /q

this turns
<channel id="I72.28459581.microsoft.com">
into
<channel id="I.28459581.microsoft.com">

Note these regular expressions are formatted for my mc2xml OTA legacy microsoft source. YMMV.
If your channel id string has different formatting or no part of it has a unique identifier which stays constant, then this patch won't work.

[mvallevand]

BrettB, I think SD uses just the number anyway, why are you bothering with a grabber?

Martin

[BrettB]

Sorry to burst your bubble, but I have seen this problem with EPG data coming from Schedules Direct via the xmltv.exe grabber. (See the original post in this thread from 2010. AND I've had this problem happen twice in the last 2-3 weeks. The same work-around "fixes" the problem and gets NextPVR to properly import the EPG data. (from the exact same xmltv data file)

OK, the activity on this thread (along with my recent problems) got me looking more closely at my xmltv files. It appears that MY problem was caused by UltraXMLTV Enhancer. Apparently, it changes the <channel id> values in the file when it processes it. Yuck!