Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[greynolds]

I've got a recording rule setup to record Boston Bruins games.  It's setup to not record repeats to avoid getting replays of recent games, but that can obviously have the side effect of not recording a game if it's incorrectly flagged or processed as a repeat.  I was double checking the upcoming recordings this afternoon and noticed that the game for this coming Monday, 12/7, wasn't listed.  So I temporarily modified the rule to allow it to record repeats and the game then showed up in the list of upcoming recordings, along with a bunch of replays of other games that I don't want to record.  I switched the rule back to not allow repeats and manually added a recording for the game from the guide.

I also have Windows Media Center setup to record the games (it's still my primary DVR, I'm testing JRiver's recent recording rules alongside for a while before switching over) and it had the same problem - it didn't have that game in the upcoming recordings either.

Since neither program stores a copy of the xmltv.xml file, I made a donation to MC2XML and just got the version that will download the new Rovi data.  I found the program of interest in the xml files and here it is:

   <programme start="20151207190000 -0500" stop="20151207213000 -0500" channel="I76.28455377.microsoft.com">
      <title lang="en">NHL Hockey</title>
      <desc lang="en">Nashville at Boston.</desc>
      <category lang="en">Sports</category>
      <category lang="en">hockey</category>
      <episode-num system="ms_progid">1.310144854</episode-num>
   </programme>

Since it has been a few hours since I noticed the problem in MC, it's obviously possible that the data has now been corrected, but this clearly isn't marked as a repeat as it would have the previously-shown element if it was a repeat.  Since I already manually added the game in question to the recording queue from the guide, I'm not sure if I can cancel that recording and still expect it to get recorded by the rule I've been using.

Is it possible to access/display more of the guide data that's used somewhere in MC (preferably in the guide displays in standard and theater view)?  It would be nice to include some sort of indication that a program is a repeat, both for confirming why a given show isn't being recorded and just so one will know that a show they're considering watching is a repeat.  It would also be nice to see the duration and/or end time of each program in the guide list that's shown in the standard view.

Another potential enhancement to the recording rules would be to be able to have a rule where you can choose duration for the rule and then enter hours:minutes for the value.  In the case of the hockey games, new showings are always listed for 2 1/2 hours, while replays get compressed to 2 hours.  So being able to create a rule where the duration is greater than 2 hours might allow the subscription to be set up to allow repeats but still only get new games thereby bypassing the problem with improperly flagged repeats.

I obviously don't expect MC to be able to work miracles with bad data, but displaying some more information would at least help the user figure out why something isn't scheduled to record when they think it should be (and vice versa).

[RoderickGI]

I'm a bit short on time for a full reply, but;

You can delete specific program instances from a subscription so they won't be recorded. So if you allowed repeats, then went through the Guide, highlighted the repeat you didn't want, press Enter/OK, select Cancel Recording, confirm with a yes. The red dot on the program will change to a white dot, and that repeat won't be recorded. A bit of work to go through the Guide to do this, but possible.

Even easier, you can do the same thing just about anywhere where the recording of that program in visible. So via the "To Be Recorded" list for example, or by using the Standard View display of the Program Guide, plus the search function (top right corner), to make it easy to find the programs, and then Cancel the ones you don't want. i.e. Display "All Programs" in the Television view in Standard View. Select the channels you wish to search, where hockey may be played. Ctrl-Click to select multiple channels, or just select "All Channels". Then use the search function to search for "NHL Hockey". You will be able to see the program Name and Description, so if that is enough to determine if it is a repeat, you can Cancel a repeat recording there. Just select the program and the "Cancel Recording" button appears.

I have started to play with a custom view of the EPG data. If you have learned how to create custom views, you can create one and restrict it to viewing data in the "Television Guide" database. To do so "Set the rules for display" with a "Modify Results" rule of "Limit database to" = "Television Guide".

Now, I haven't really done much testing, so I can't say how useful that is. But, when I made a change to a value in the view, the change stuck and was reflected in the Guide. There is a field called "Rerun", which may well be the field the MC sets when a repeat is detected. Some of the programs in my view have "Rerun" set to "1", which I suspect means that they are repeats. Maybe, if that field has no value in an imported EPG data set, any change to that field value may survive future EPG data loads? I don't know. Haven't tested. There doesn't appear to be a "previously-shown" field or equivalent in the, but I'm pretty sure that if such a field exists in the EPG XML file, then the "Rerun" field is set.

Yaobing has explained how the repeat identification works previously, but he may need to do it again. I don't have the explanation at hand.

BTW, MC now keeps the XMLTV file for 24 hours after processing, before it is deleted. Yaobing posted on that change a while back. Again, have a search on he forum, or your hard disk. I can't remember what the file name is though.

Anyway, enough for now. That should give you a lot to look at. Enjoy! 

[Yaobing]

Along the same line as the customer EPG view mentioned by RoderickGI, you can also create a "Guide" smartlist in Standard view.

Yes, Rerun is the field to look at.

Rerun is set to true, when epg data contains "rerun".  It is set to false if epg contains "new".  It is set to true if the data has a "original air date" that is older than the schedule date.  It defaults to false.

The xml file is kept in C:\Users\[user]\AppData\Roaming\J River\Media Center 21\Temp\ for 24 hours.

[greynolds]

Thanks for the replies, guys.

I realize that individual matches to a subscription can be deleted, but I really don't want to have to go in every few days and clean up all the duplicates as that becomes a pain to deal with.

I had started to create a custom view of the Guide late last night, but I was tired and didn't get very far, so I finished that this morning with decent success, though it's not exactly perfect (user friendly channel numbers don't seem to be available, for instance).  But the rerun flag now shows up, so I can at least go there to check for that when problems appear.

So, I created the custom Guide view and I grabbed the "OpenCable - 10328.xml" file from the temp folder and extracted some info from it, and something is definitely fishy here.

For the game at 7PM on Monday night, it's listed on 3 channels (see the EPG.jpb attachment), 576, 587, and 1525.  Here's the info from the XMLTV file that describes the 3 channels (1525 is actually a dupe that I should edit my channel list to hide):

Code: [Select]

<channel id="I576.28459096.microsoft.com">
<display-name>576 NESNHD</display-name>
<display-name>576</display-name>
<display-name>NESNHD</display-name>
<display-name>New England Sports Network</display-name>
</channel>

Code: [Select]

<channel id="I587.182598034.microsoft.com">
<display-name>587 NHLHD</display-name>
<display-name>587</display-name>
<display-name>NHLHD</display-name>
<display-name>NHL Network US HDTV</display-name>
</channel>

Code: [Select]

<channel id="I1525.28455377.microsoft.com">
<display-name>1525 NESN</display-name>
<display-name>1525</display-name>
<display-name>NESN</display-name>
<display-name>New England Sports Network</display-name>
</channel>
Here's the extracted XMLTV program info for the 3 showings at 7PM:

Code: [Select]

<programme start="20151207190000 -0500" stop="20151207213000 -0500" channel="I576.28459096.microsoft.com">
<title lang="en">NHL Hockey</title>
<desc lang="en">Nashville at Boston.</desc>
<category lang="en">Sports</category>
<category lang="en">hockey</category>
<episode-num system="ms_progid">1.310144854</episode-num>
<video>
<aspect>16:9</aspect>
<quality>HDTV</quality>
</video>
</programme>

Code: [Select]

<programme start="20151207190000 -0500" stop="20151207220000 -0500" channel="I587.182598034.microsoft.com">
<title lang="en">NHL Hockey</title>
<desc lang="en">Nashville at Boston.</desc>
<category lang="en">Sports</category>
<category lang="en">hockey</category>
<episode-num system="ms_progid">1.310144854</episode-num>
<video>
<aspect>16:9</aspect>
<quality>HDTV</quality>
</video>
</programme>

Code: [Select]

<programme start="20151207190000 -0500" stop="20151207213000 -0500" channel="I1525.28455377.microsoft.com">
<title lang="en">NHL Hockey</title>
<desc lang="en">Nashville at Boston.</desc>
<category lang="en">Sports</category>
<category lang="en">hockey</category>
<episode-num system="ms_progid">1.310144854</episode-num>
</programme>
So far there's no hint of any of these being flagged as a rerun.

Here's where it seems to get a bit odd.  If you look at the attached CustomGuide.jpg image, it shows the 3 showings as follows:

Program ID: 1.309399717 Rerun: 1 Channel: 15397346
Program ID: 1.310144854 Rerun:   Channel: 15397353
Program ID: 1.309399717 Rerun: 1 Channel: 15397558

I'm not sure how to map those channel id's to the XMLTV file, but the program ID's of 1.309399717 don't seem correct as the XMLTV file has the following for that id (there are a bunch of occurrences of that id at different dates and times but the title is always the same):

Code: [Select]

<programme start="20151207010000 -0500" stop="20151207023000 -0500" channel="I1753.28457242.microsoft.com">
<title lang="en">To Be Announced</title>
<date>19900101</date>
<category lang="en">Sports</category>
<category lang="en">sports</category>
<episode-num system="ms_progid">1.309399717</episode-num>
<previously-shown start="19900101000000" />
</programme>
I couldn't find any instances in the XMLTV file where this program id shows up at 7PM on 12/7 and it's clearly for something other than the hockey games as the title obviously isn't "NHL Hockey".  But it does have the previously-shown element set, which explains why the rerun field is being set to 1.

But why is JRiver thinking that 1.309399717 is the correct program id for these, despite managing to display the correct title and description?

My assumption is that JRiver's channel id of "15397353" maps to 587 NHLHD because my subscription is not configured to match programs on that channel (if the game is being shown on both NHLHD and NESNHD, I want the recording from NESNHD to get the local announcers, and it will never only be on NHLHD).

I can certainly accept that data is sometimes bad (we all know that it happens), but this doesn't appear to be one of those times.  Of course, WMC had the same problem with presumably thinking the 7PM showing on NESNHD was a repeat, so there may be something wrong with the EPG data that I'm missing.

Yaobing - I've stashed aside a copy of the XMLTV file in case you want me to provide a copy of it for analysis.  Just let me know and I can upload it to a location you can access it from and provide you with a link.

Thanks!

EDIT:  I just deleted the recording that I manually added for the game on Monday night and then edited my subscription to include channel 587.  After doing that, the instance from Monday night on channel 587 showed up in the "to be recorded" list.  I then re-edited my subscription to remove channel 587 and re-enabled the manual recording of the game on channel 576.

[Yaobing]

You can forward the xml file to me so I can take a look on Monday.

To figure out what these channels are:

Program ID: 1.309399717 Rerun: 1 Channel: 15397346
Program ID: 1.310144854 Rerun:   Channel: 15397353
Program ID: 1.309399717 Rerun: 1 Channel: 15397558

you can use the hint given by Matt, here.

Use http://localhost:52199/MCWS/v1/File/GetInfo?File=15397346, for example, in a browser.

[greynolds]

You can forward the xml file to me so I can take a look on Monday.

To figure out what these channels are:

Program ID: 1.309399717 Rerun: 1 Channel: 15397346
Program ID: 1.310144854 Rerun:   Channel: 15397353
Program ID: 1.309399717 Rerun: 1 Channel: 15397558

you can use the hint given by Matt, here.

Use http://localhost:52199/MCWS/v1/File/GetInfo?File=15397346, for example, in a browser.

Thanks!

Here's a link to a zip file that contains the xml file and the GetInfo files:

http://www.geoff-reynolds.net/JRiver/OpenCable - 10328.zip

Channel: 15397346 = 576 NESNHD
Channel: 15397353 = 587 NHLHD
Channel: 15397558 = 1525 NESN

Let me know if you need anything else.

[Yaobing]

Could channels 576 and 1525 once been tied to XMLTV ID "I1753.28457242.microsoft.com" (which would be for channel 1753) erroneously?

[greynolds]

Could channels 576 and 1525 once been tied to XMLTV ID "I1753.28457242.microsoft.com" (which would be for channel 1753) erroneously?

Not that I know of - is there something I could check to confirm that one way or the other?  I reset my guide when I upgraded to MC 21 several weeks ago, so I suspect I would remember actively doing anything that would tie them to 1753.

[RoderickGI]

Well this could end up being a very interesting thread.

I have noticed in the past what appeared to be some anomalies in the XMLTV load, where programs in the Guide didn't seem to quite match the XMLTV data. But it has been hard to check since not all data was visible before the event, so I had to rely on making a recording and seeing what data was included. That is why I went looking for a way to create a custom view of the Guide data to compare to the XMLTV file immediately.

But even with that custom view available it wasn't worth raising, as my XMLTV data has had unexplained errors that made any comparison useless. I collect EPG data OTA using EPG Collector. So I have been working with Steve Bickell, the developer of EPG Collector, to get those sorted out. Once that is done I can investigate what MC is doing, and see if there really are any XMLTV file load issues or not.

It looks like you are starting the job for me GReynolds.

On the data you have presented, the three programs in the XMLTV file have the same Program ID of 1.310144854, as expected.

But then you picked out three programs from the custom Guide by date and time. These three;
Program ID: 1.309399717 Rerun: 1 Channel: 15397346
Program ID: 1.310144854 Rerun:   Channel: 15397353
Program ID: 1.309399717 Rerun: 1 Channel: 15397558

So it looks like MC has incorrectly imported the Program ID for those time slots, using another time slots Program IDs.

I am wondering though, were there any other instances of Program ID 1.310144854 in your custom Guide, and if so, at what dates, times, and channels?

[greynolds]

Program ID: 1.309399717 shows up in the custom guide list for the following times:

12/7 at 7PM on channel id 15397346 (576 NESNHD)
12/7 at 7PM on channel id 15397558 (1525 NESN)
12/8 at midnight on channel id 15397346 (576 NESNHD)
12/8 at midnight on channel id 15397558 (1525 NESN)
12/8 at 2:30PM on channel id 15397346 (576 NESNHD)
12/8 at 2:30PM on channel id 15397558 (1525 NESN)

While sorting by the description to get the above info, I also just noticed that there's another program ID in play for the same hockey game that also seems to be behaving strangely:

Program ID: 1.309540651 only shows in the custom guide for the following time:

12/8 at 1PM on channel id 15397353 (587 NHLHD)

But shows up multiple times in the XMLTV file (I'm not including some other entries for this one for channels that I have hidden in my TV setup in JRiver).  Note that the extra times and channels overlap with some of the program ID: 1.309399717 entries from above:

Code: [Select]

<programme start="20151208000000 -0500" stop="20151208020000 -0500" channel="I576.28459096.microsoft.com">
<title lang="en">NHL Hockey</title>
<desc lang="en">Nashville at Boston.</desc>
<date>19900101</date>
<category lang="en">Sports</category>
<category lang="en">hockey</category>
<episode-num system="ms_progid">1.309540651</episode-num>
<video>
<aspect>16:9</aspect>
<quality>HDTV</quality>
</video>
<previously-shown start="19900101000000" />
</programme>

Code: [Select]

<programme start="20151208143000 -0500" stop="20151208163000 -0500" channel="I576.28459096.microsoft.com">
<title lang="en">NHL Hockey</title>
<desc lang="en">Nashville at Boston.</desc>
<date>19900101</date>
<category lang="en">Sports</category>
<category lang="en">hockey</category>
<episode-num system="ms_progid">1.309540651</episode-num>
<video>
<aspect>16:9</aspect>
<quality>HDTV</quality>
</video>
<previously-shown start="19900101000000" />
</programme>

Code: [Select]

<programme start="20151208130000 -0500" stop="20151208140000 -0500" channel="I587.182598034.microsoft.com">
<title lang="en">NHL Hockey</title>
<desc lang="en">Nashville at Boston.</desc>
<date>19900101</date>
<category lang="en">Sports</category>
<category lang="en">hockey</category>
<episode-num system="ms_progid">1.309540651</episode-num>
<video>
<aspect>16:9</aspect>
<quality>HDTV</quality>
</video>
<previously-shown start="19900101000000" />
</programme>
It'll be interesting to see what Yaobing is able to find out from all of this.

[RoderickGI]

It'll be interesting to see what Yaobing is able to find out from all of this.

Indeed.

I was wondering though if some program data was overwriting other program data, or if the data is just being moved around, to different time slots. Hence my question about the correct Program ID for your game.

I am wondering though, were there any other instances of Program ID 1.310144854 in your custom Guide, and if so, at what dates, times, and channels?

[greynolds]

Indeed.

I was wondering though if some program data was overwriting other program data, or if the data is just being moved around, to different time slots. Hence my question about the correct Program ID for your game.

Right, and I think that could be what's happening.  I didn't include all of them above, but there are a bunch of instances of program id 1.309399717 in the XMLTV file.  Though they're clearly for other channels, it seems as though their data is somehow getting merged with these hockey games.  It's not simply overwriting, because the hockey games have the correct times, name, description, and channel numbers - all that really appears to be wrong is they have the wrong program id and as a result also have the rerun flag set to 1.  The xml file is somewhat painful to go through, as it's pretty big, so at this point I think I'm going to let Yaobing look at it when he can on Monday and see what he has to say.

[Yaobing]

Hopefully this issue is fixed:

Fixed: When loading XMLTV EPG data, re-run flag was not saved when it's value was false.  This caused previously saved bogus "true" value not to be corrected.

The problem likely was caused by the following:

Previously the time slot had been filled with program 1.309399717 which seems to be a catch-all for any sports program that is "to be announced".  The odd thing about this is that this "program" always has a previously-shown date of 19900101.

The only thing that I still can not explain is why the program ID was not updated.

[greynolds]

Hopefully this issue is fixed:

Fixed: When loading XMLTV EPG data, re-run flag was not saved when it is false.  This caused previously saved bogus "true" value not to be corrected.

The problem likely was caused by the following:

Previously the time slot had been filled with program 1.309399717 which seems to be a catch-all for any sports program that is "to be announced".  The odd thing about this is that this "program" always has a previously-shown date of 19900101.

The only thing that I still can not explain is why the program ID was not updated.

Ah - that makes a lot of sense.  Thanks for taking a look and for fixing it.  I'll keep monitoring things after I install the next release that contains this fix and let you know if it happens again.

[RoderickGI]

Hopefully this issue is fixed:

Fixed: When loading XMLTV EPG data, re-run flag was not saved when it's value was false.  This caused previously saved bogus "true" value not to be corrected.

I suspect that this problem is not limited to the "Rerun" field Yaobing. I documented evidence some time ago of strange happenings with the Title and Sub-title EPG data, and the resulting Series and Name fields in MC: http://yabb.jriver.com/interact/index.php?topic=92426.0

If you look at the first example image, you can see that the program "Harry's Practice" has picked up the Series name from the earlier program "Bates Motel".



Now that I know more about how MC uses the EPG data than I did back in October 2014, this is what I think is happening

For the "Bates Motel" program, the EPG data provided is;

EPG "Title" field = "Bates Motel".
EPG "Sub-title" field = "The Truth".
As both the EPG Title and Sub-title fields have values in them;
"Bates Motel" is passed to the "Series" field.
"The Truth" is passed to the "Name" field.


For the very next program, "Harry's Practice", the EPG data provided is;

EPG "Title" field = "Harry's Practice".
EPG "Sub-title" field = blank.
As only the EPG Title field has a value;
"Harry's Practice" is passed to the "Name" field.
The "Series" field isn't updated, and retains the value "Bates Motel".

Note as per the thread I linked to, the programs involved aren't always consecutive.


What do you think. Is that a possible scenario?

[Yaobing]

I am pretty sure we are not taking the values from a program that is scheduled just before the current one.  The bug I found was that we had a wrong program previously, for example a day ago, or even a week ago, the program was something different.

In your example, do you think the time slot 12:30 am used to be filled with Bates Motel?

[RoderickGI]

In your example, do you think the time slot 12:30 am used to be filled with Bates Motel?

Possible, but highly unlikely, particularly as the duration of the two programs are different, so a swap wouldn't result in the same start time for the second program. They would have to all involve schedule changes that moved the second program to the same time slot as originally occupied by the first program, with the same start time I assume, rather than just been scheduled to be part way through the program. I found so many examples at the time I created that thread, there would have to be a lot of schedule swaps on the one channel, which resulted in the same start time.

Well, I am assuming that the internal program ID you assign is based on the channel, date, and start time, and that it is the internal program ID that is being reused or something. I don't really know how that is handled internally.

I haven't been looking for the problem since my last post in that original thread, as it is a bit rare and I have to go through the whole Guide on screen to find them. That is time consuming, and it is even more time consuming to document them. If the problem was that the programs were swapped as above, then I would need to keep every XMLTV file and check the current one when I find a problem, then check all previous ones to see if the donor program used to occupy that time slot. Doable, but a very big job.

At the moment I am working on fixing my EPG source data. I probably won't take on checking this problem again until that is done. I may have a look though, to confirm if the problem is still happening, and if I find some will post in the original thread rather than clog up this one. I raised it here because in fixing my source data, I have seen similar data parsing problems to this with EPG Collector. Strange things such as when the Description exactly matches the Title (Series), then the Season and Episode numbers gathered from TheTVDB always used the first numbers found for the series, not the correctly matched Season and Episodes. Just quirks in the parsing code. After all, you are just parsing XML files into the MC library, or the

[greynolds]

Ah - that makes a lot of sense.  Thanks for taking a look and for fixing it.  I'll keep monitoring things after I install the next release that contains this fix and let you know if it happens again.

So I decided to wait for the problem to happen again and then update.  This week, a couple of Boston Bruins games (Friday night and Saturday night) weren't showing up in the upcoming recordings list.  So I checked the repeat data in the guide and sure enough it was set to 1.  I installed version 30, reloaded the guide data, and the repeat flag was now correctly cleared and the games show up in my upcoming recordings list.  So the fix appears to be good.  Thanks again!

[greynolds]

Here's a different twist on the problem.  I was checking on shows scheduled to be recorded to verify that things are correct and noticed that the Bruins game for this Sunday isn't scheduled.  So I looked at the guide data.  On channel 7.1, a show is listed as "NHL Hockey" but without a Description.  Channel 507 (the HD cable TV equivalent of the OTA 7.1) has a listing for "NHL Hockey" with the correct description of "Boston at Detroit".  My rule is setup to record on 7.1 (and some other channels that the games can be on), but not 507 as I always want to use the OTA tuners for shows that are on this channel and conserve the cable tuners for shows that are cable only.

So I checked my custom guide view and verified that both instances of a program id of 1.310308273.  If they share the same program id, shouldn't they have the same description?  Obviously, 1 is coming from the ATSC guide data file and the other is coming from the opencable guide data file, so this may just be bad guide data.

Here's a link to the current guide data files:

http://www.geoff-reynolds.net/JRiver/2016-02-10-GuideData.zip

Interestingly, neither XML file seems to have the description in it for that program id...

[RoderickGI]

Interesting. I had a look in your file. Big. It prompted me to finally install Notepad++ just to handle the file size in a reasonable timeframe.

No "Boston at Detroit" in the OpenCable file, or the ATSC file. I wonder where MC is getting the description from? A past recording with the same ProgramID maybe? (Which would be an error, I would have thought.)

Your Custom Guide View, if it is like mine, will show past guide data as well as current and future guide data. I haven't restricted my guide date range, I just show everything in the Guide table. Did you check the dates against the game with the description "Boston at Detroit"? I've been caught out a couple of times comparing EPG data, when I realised that I was looking at old data.

[greynolds]

Interesting. I had a look in your file. Big. It prompted me to finally install Notepad++ just to handle the file size in a reasonable timeframe.

No "Boston at Detroit" in the OpenCable file, or the ATSC file. I wonder where MC is getting the description from? A past recording with the same ProgramID maybe? (Which would be an error, I would have thought.)

Your Custom Guide View, if it is like mine, will show past guide data as well as current and future guide data. I haven't restricted my guide date range, I just show everything in the Guide table. Did you check the dates against the game with the description "Boston at Detroit"? I've been caught out a couple of times comparing EPG data, when I realised that I was looking at old data.

Yeah, the OpenCable files are pretty big - there are a lot of channels in the cable lineup.

Yes, I checked the dates.  The regular guide is also showing the "Boston at Detroit" description for the instance of the game that's on channel 507.  If I had to guess, it would be that a previous guide update may have had the correct description in the OpenCable version, but the most recent update dropped the description in which case I would actually expect MC to do the same.  Even if the data is wrong, MC should probably assume that the latest guide data is the most accurate as there's really no way for it to know otherwise.  I'll keep an eye on this for the next few days and see if another guide update corrects things.

[Yaobing]

MC gets descriptions from the xmltv files.

In my area, "Boston Bruins at Detroit Red Wings" is the episode name.  Most of NHL Hockey series have no description.

[greynolds]

MC gets descriptions from the xmltv files.

In my area, "Boston Bruins at Detroit Red Wings" is the episode name.  Most of NHL Hockey series have no description.

When I mentioned "Description" above, I was referring to the MC Description column in the Television views.  Where that comes from in the guide data, is another matter.  But the main point here is that if 2 instances share the same program id (such as in this case), I would expect them to both have the same data showing in the MC guide and the other Television views.

[Yaobing]

Description is a standard field.  So I would say the data in the column come from the field in each program entry.  The field is filled when we load xmltv data.

The only other ways the field gets modified are - user changes it manually, and user runs "Movie & TV Info" tool on the program.

[Yaobing]

And I double-checked my code again.  We do always save Description to the database field even if it is empty.  So that rules out the possibility of data being left over from previous EPG loading.

[greynolds]

Description is a standard field.  So I would say the data in the column come from the field in each program entry.  The field is filled when we load xmltv data.

The only other ways the field gets modified are - user changes it manually, and user runs "Movie & TV Info" tool on the program.

This still leaves me somewhat confused as your answer doesn't explain the discrepancy that I'm seeing.  By the xmltv data, should I assume that you mean the "opencable - 8456.xml" and "atsc - 8456.xml" files that I provided?  If so, then neither instance of this program id should have a value for the description in the guide since the xml files don't have anything for it.  Since it's not possible to manually enter the guide data in the standard Television views (and I didn't edit it in the custom guide view), this would seem like an issue in MC, not something I did wrong.  Do the attached screen shots of what I'm seeing make the issue more clear?  In the 2 guide screenshots (custom and standard), I've highlighted the 2 instances that share the same program id, but have different descriptions (which isn't explained by the xml files as neither one seems to have an episode name / description for this program id).

I had been running MC version 21.0.30, but just updated to 21.0.45.  After upgrading, I also forced a guide update.  Now both instances of this game (channel 7.1 and channel 507) have no value for the Description.  So at least they're consistent now and we can blame the lack of a description on bad guide data.  The other upcoming Bruins games have appropriate descriptions and are properly scheduled to record.  I'll let it sit for another day to see if the next guide update includes a description.  Note that the screenshots are from BEFORE I upgraded to version 45.

What's interesting though is that WMC, which uses the same guide data from Rovi, has the correct description for this particular game and is scheduled to record it.  Of course, WMC had other guide data issues.  It wasn't going to record the game on Saturday; I'm guessing it thought it was a repeat (an issue that's most likely very similar to the original topic of this thread that Microsoft will never fix now that they've abandoned WMC development).

[RoderickGI]

I saw this:

I had been running MC version 21.0.30, but just updated to 21.0.45.

and thought the issue might be this:

21.0.27 (12/11/2015)
5. Changed: When loading XMLTV EPG data, all relevant fields are updated, instead of only updating those that are not empty.  This prevents wrong data from being retained.

But if you were already running MC21.0.30, then that issue should have been fixed.

But I guess it is a good rule with MC, if you see something funny going on, upgrade to the latest version and see if it has been fixed.   

I would put this issue down to transitional effects of many changes happening in TV at the moment, and move on.