EPG - Repeat, original air date?

[Jaggy]

Having just moved from Windows MCE, one thing that I used constantly was the 'original air date' in the EPG.

I could be totally thinking wrongly here as our TV guide down under is basically total crap as far as anything apart from title, time, description (if we are lucky)

Anyway enough of my problems...if MCE can get the data isn't that the same data mc2xml uses?

[zehd]

Check the <date> field?

Yes... mc2xml gets from the same place as MCE. And that's probably how MCE extrapolates the New Show

Ultra works fine and dandy with this. It's just up on the hoist at the moment...

[jdg]

I could be totally thinking wrongly here as our TV guide down under is basically total crap as far as anything apart from title, time, description (if we are lucky)

Anyway enough of my problems...if MCE can get the data isn't that the same data mc2xml uses?

I'd like to suggest that gbpvr catch up with the times and improve its own standard EPG. I think the gbpvr author has guide info that is probably pretty basic in new zealand, but the rest of the world could really use a better one.

The epg is central to the PVR experience. All the info is already in the xmltv file I think.

Instead of having all these extra "*" new show hacks, bulky post processors, XmlTvExtras plugin, TVListings2 plugin, 4therecord plugin and more and more plugins, I think it is time GBPVR improved its dinosaur EPG and scheduling capabilities (check out 4therecord for examples of advanced scheduling).

As for the EPG, if it could handle the "previously-shown" tag, "date" tag, "episode number" and all the other standard xmltv ones it could quickly become much more advanced at figuring out on its own (or even in user definable ways!) what is a new show, and what should/shouldn't be recorded. It seems like it would just be adding columns to the database and adding some basic logic expressions on top of that. The user could record "all episodes" of some show, and then "episode numbers" would be used to check if some episode had already been recorded or not.

Or the user could record new episodes, and define "new" to be "if episode has "<new> tag, or <previously shown> has a date of today, or <date> is today" or whatever makes sense.

Plus, look at the windows 7 epg. It has thumbnail pictures for shows/movies. GBPVR has to catch up!

http://hdimage.org/images/6eid2exuh9danvx9ms9h_5.png

I love the pictures for my kids, as they can find the programs they want to watch from the recorded list by looking at the pictures!

[bgowland]

I'd like to suggest that gbpvr catch up with the times and improve its own standard EPG. I think the gbpvr author has guide info that is probably pretty basic in new zealand, but the rest of the world could really use a better one.

I'd like to suggest that we're all pretty damn lucky that GB-PVR supports such a wide range of television standards so well and, if people aren't impressed enough they could always try other PC-based PVR software.

All the info is already in the xmltv file I think.

Have you read the XMLTV DTD? Pretty much 99% of it is optional. Try grabbing xmltv info from various countries and see how much the content varies.

and all the other standard xmltv ones

Again...no such things as "standard" xmltv - optional maybe, very little mandatory.

It seems like it would just be adding columns to the database and adding some basic logic expressions on top of that.

Yep - simple as that. Sigh! .

All due respects sir but you're talking out of your ear.

Cheers,
Brian

[daveangel]

Hey, I just checked the raw xmltv feed from MC2XML and EVERY entry has the 'previously_shown' start date which is perfect. So I guess I need to run this through the UltraXMLTV program to extract and tack it in the description and I then have the EXACT same experience as the Windows Media Centre. Perfect!

I assume there is no plugin which will simply do this for me without having to run through a filter or something?

[jdg]

I'd like to suggest that we're all pretty damn lucky that GB-PVR supports such a wide range of television standards so well and, if people aren't impressed enough they could always try other PC-based PVR software.

I'd like to suggest that every suggestion isn't an attack on the existing code. It feels like gbpvr pitbulls run out and growl "Grrr, it sounds like you aren't appreciating things enough, how dare you even suggest something that would improve this product!"

Please settle down and think carefully about what you are saying.

Have you read the XMLTV DTD? Pretty much 99% of it is optional. Try grabbing xmltv info from various countries and see how much the content varies.

Again...no such things as "standard" xmltv - optional maybe, very little mandatory.

Yes I have read it. The .DTD defines the standard. Content is optional, but if it happens to be there why not use it? Why aim for the lowest common denominator? It really is just more columns in a database.

Yep - simple as that. Sigh! .

All due respects sir but you're talking out of your ear.

No, I'm quite confident that what I'm saying makes sense as it is in plugins and other products already. Please look at xmltvextras before you "talk out of your ear". My suggestions were to make gbpvr more impressive out of the box instead of having every new user find and figure out all these extra plugins.

You seem to be overly defensive for some unknown reason. It is a suggestion for improvement. It is beyond me why you would take such a harsh stand against people offering suggestions for the obvious improvement of gbpvr.

[sub]

The reality is that very few EPG sources supply more than title, subtitle, description, time, duration and genre iin listings. It has improved marginally over the years, with a couple xmltv sources now providing extra stuff like the first run date, but even those might only have this info on certain channels. This still leaves the bulk of xmltv and dvb epg users without any of this extra stuff though.

I dont really have any problem with collecting this extra EPG info, and have been considering some additions recently. It is harder to decide how to make use of this info though. ie, having places on the screens to displayed this info if the bulk of users wont have this info, or providing scheduling options that wont work for the bulk of users (or might only work on a couple of their channels).

[jdg]

The reality is that very few EPG sources supply more than title, subtitle, description, time, duration and genre iin listings. It has improved marginally over the years, with a couple xmltv sources now providing extra stuff like the first run date, but even those might only have this info on certain channels. This still leaves the bulk of xmltv and dvb epg users without any of this extra stuff though.

I wonder what you base that on ("very few EPG sources supply...")? I think about scheduels direct which has a lot of cast info, and mc2xml which has the same cast info, start date, episode number, mpaa ratings, tv ratings and advistories and all that, but I'm sure it depends on which country is used. The mc2xml web page says the latest version also has those program/movie thumbnail images in there which I think is most fun.

North america is a big market.

Europe has cast info, category info, date, movie star-ratings as well. Even the "HD" sign indicating an HD program.

I dont really have any problem with collecting this extra EPG info, and have been considering some additions recently. It is harder to decide how to make use of this info though. ie, having places on the screens to displayed this info if the bulk of users wont have this info, or providing scheduling options that wont work for the bulk of users (or might only work on a couple of their channels).

Well, that is a design issue, but if you collect as much information as possible the rest is just design which is fun stuff. For scheduling, I again am not sure how you can say the "bulk of users" won't have those options, but if it is all configurable dependant on what really is available (ie: try to use as much info as possible when determining what is "new", unless it isn't there (column data is empty), in which case fallback to option 2 to determine what is "new"...).

It then works for everyone. I'd bet most users don't even know what they are missing out on since the data they already have isn't being used.

Aim high and fall back if not available, rather than aiming low and stopping there.

[sub]

Trust me. I've looked at more xmltv files than you, including those from just about every country in the world. I know what is available and how common this extra data.

I also know what information isnt available via the DVB EPG, and where the general location break down of GB-PVR users are. The majority of users dont have this extra epg information available. North American users are pretty much the only users that get a good reliable source of this extra info. Outside of North America, this info is sparse and patchy at best.

[jdg]

Trust me. I've looked at more xmltv files than you, including those from just about every country in the world. I know what is available and how common this extra data.

I also know what information isnt available via the DVB EPG, and where the general location break down of GB-PVR users are. The majority of users dont have this extra epg information available. North American users are pretty much the only users that get a good reliable source of this extra info. Outside of North America, this info is sparse and patchy at best.

I just looked at Japan, Norway, India and Brazil from mc2xml. Maybe you are using output from old scrapers that don't collect that info but that extra info looks to be available (not as great as North America, but if it is there why not use it?). Even patchy (available on some channels and not others) is better than none as those "some channels" might be good ones.

I guess my point is, even if 1 person has a full xmltv file, I don't see why gbpvr wouldn't want to take advantage of it. If designed/engineered properly it shouldn't hurt anyone else that doesn't have full xmltv files if gbpvr only uses the info if it is available, and doesn't use it if it isn't. One day those users with sparse xmltv files may get more data and gbpvr would already be ready to handle it.

(And north america has more than 1 person in it. )