<!DOCTYPE html><html><head><style type="text/css">body { font-family:'DejaVu Sans'; font-size:13px}</style></head><body><div>>><br>>> Interesting to hear.<br>>><br>>> However I've been pretty underwhelmed with the RT data, so I'll be <br>>> sticking with<br>>> EIT for now. The source of the RT program ids are still a mystery to me <br>>> but I<br>>> now think that EIT crids are going to be the way of the future.<br>>><br>>> I rarely watch Ch 5 but pick up a lot of old stuff from Dave and <br>>> they're a<br>>> nuisance. As you say, they interleave season & episodes and I was <br>>> hoping of<br>>> watching them in some sort of order for a change.<br>>><br>> Underwhelmed with the RT data? All 14 days of it? I'd hate to have to <br>> plan round a holiday with only today's data, or even now & next.<br>><br></div><div><br></div><div>EIT provides 7 days of data. For holidays 1 week of single-records & the series recordings is plenty for me - it's only TV!</div><div><br>> Program IDs are meaningless but the point is that they should be unique <br>> (like a GUID). RT provides series (season) and episode # which is what <br>> makes it all work.<br>><br></div><div><br></div><div>Program ids identify the duplicates - <a href="http://www.mythtv.org/wiki/Duplicate_matching">http://www.mythtv.org/wiki/Duplicate_matching</a></div><div><br></div><div>I agree season/episodes on everything would be great. About 1/4 of my programs (BBC, Ch4) already have them - I don't fully understand how yet. I believe they can be extracted from the EIT description. Or they might be coming from metadata lookup before I turned it off. I'll look into getting that working.</div><div><br></div><div>Thus RT provides an extra week of data that I'll never look at and screws up my duplicate matching by using its own program ids - it's not as good as I anticipated.</div><div><br><br></div></body></html>