Zap2it Closing Down

[zed]

You would browse the listings in the TitanTV web page. True, the only data that's downloaded would be for recordings but that's all you really need to keep locally, isn't it? I guess it depends on how you use the system.

The data I saw came in xml format as a specific mime type (see post 183 in this thread). I'd think that a browser plug-in or helper app could be written that would respond to that mime type and do the scheduling. I imagine that that's the way it works with WinTV and the others that handle it. I think that the GB-PVR scheduling methods are exposed since there's a couple of existing plug-ins that must use them.

I'd tackle this but I don't know if my programming skills are up to it. I'm more a Java guy rather than C#.NET...

[pastro]

You would browse the listings in the TitanTV web page. True, the only data that's downloaded would be for recordings but that's all you really need to keep locally, isn't it? I guess it depends on how you use the system.

The data I saw came in xml format as a specific mime type (see post 183 in this thread). I'd think that a browser plug-in or helper app could be written that would respond to that mime type and do the scheduling. I imagine that that's the way it works with WinTV and the others that handle it. I think that the GB-PVR scheduling methods are exposed since there's a couple of existing plug-ins that must use them.

I'd tackle this but I don't know if my programming skills are up to it. I'm more a Java guy rather than C#.NET...

It seems to me it is doable. I would think you could design it somewhat like the weather plugin that would go out on the net every 20 minutes or so and check to see if there are new recordings to download. If new schedules come in then schedule them within GBPVR. I don't know if you need an EPG to do this or not. Looks like a fun project to work on.

[whurlston]

I'd be interested in something like this. Maybe as a plugin for those that would use it? Maybe an option for those that don't want to pay for listings (Sub mentioned that it's a Work in Progress), but don't mind using a browser?

This could be done but I don't have the time to work on it at the moment. It would not pass the WAF test for me, which is my number one priority.

I'm not convinced yet that Yahoo! won't figure out what's going on and somehow disable access unless it's from its client or that Titan TV won't figure out all of the UUIDs that are being used and disable them.

I am actually using the Yahoo software to download the listings. I'm just telling it WHEN and then exporting the data from it.

[soccerdad]

Looking at just a few of their forums posts will show that many others are not happy with it in it's current form (beta).

I am VERY happy with their program. IT GETS EPG DATA! I wish it a long long long life! I will even keep using my other Yahoo programs, and sometimes I will even use their TV app.

[FirstTeamOPS]

I brought this up in the early part of this thread (posts 183 & 190). It seems like a viable approach to me. I looked at the data it sends and I don't think it really matters what device you specify. In any case, it could be written to expect a specific one that you'd select in your profile. You don't really have to have the device installed.

I'd imagine that a browser plug-in could be written that would take the data from your selection and schedule a recording in GB-PVR. I've never written anything like that but it might be interesting to try.

The upside would be that you wouldn't need to download several meg of data every night. Downside is that you'd need a browser running...probably not a show-stopper for many folks. It's a different approach but I think it could be made to work.

Awesome. Sounds good. I would still like to have EPG data in GB-PVR for a DVR machine but some would probably use TTV exclusively. I would love to be able to use TitanTV's favorites since that's what I reference when I'm scheduling shows for the week.

[-Oz-]

My yahoo EPG downloader is ready for testing. You don't need Yahoo's program to get listings this way.

http://forums.nextpvr.com/showthread.php?p=205143

[dragonfiregum]

If you actually need testers i will be happy to test it. But if not i dont want to try it until around august as i dont want to accelerate its breakage.

[pBS]

any news on converting the MCE data yet?
it's the closest to the old zap2it as far as i can tell, and has ability to do digital and select individual channels for the lineup..[presumably shrinking d/l size]

[ARogan]

First a big thanks to all those working hard and writing these programs to find alternative ways to get guide data.

I've been working on my own unreleased PVR software for the last 3 years (also written in c#). I use xmltv as my source of guide data so I'm in the same boat.

My comment/question is I noticed in all the little utilities the resultant xmltv compatible file is missing this tag:
<episode-num system="xmltv_ns">2 . 9 . 0/1</episode-num>

http://xmltv.cvs.sourceforge.net/xmltv/x...iew=markup
As defined in the DTD it reads:

<!-- Episode number
351
352 Not the title of the episode, its number or ID. There are several
353 ways of numbering episodes, so the 'system' attribute lets you specify
354 which you mean.
355
356 There are two predefined numbering systems, 'xmltv_ns' and
357 'onscreen'.
358
359 xmltv_ns: This is intended to be a general way to number episodes and
360 parts of multi-part episodes. It is three numbers separated by dots,
361 the first is the series or season, the second the episode number
362 within that series, and the third the part number, if the programme is
363 part of a two-parter. All these numbers are indexed from zero, and
364 they can be given in the form 'X/Y' to show series X out of Y series
365 made, or episode X out of Y episodes in this series, or part X of a
366 Y-part episode. If any of these aren't known they can be omitted.
367 You can put spaces whereever you like to make things easier to read.
368
369 (NB 'part number' is not used when a whole programme is split in two
370 for purely scheduling reasons; it's intended for cases where there
371 really is a 'Part One' and 'Part Two'. The format doesn't currently
372 have a way to represent a whole programme that happens to be split
373 across two or more timeslots.)
374
375 Some examples will make things clearer. The first episode of the
376 second series is '1.0.0/1' . If it were a two-part episode, then the
377 first half would be '1.0.0/2' and the second half '1.0.1/2'. If you
378 know that an episode is from the first season, but you don't know
379 which episode it is or whether it is part of a multiparter, you could
380 give the episode-num as '0..'. Here the second and third numbers have
381 been omitted. If you know that this is the first part of a three-part
382 episode, which is the last episode of the first series of thirteen,
383 its number would be '0 . 12/13 . 0/3'. The series number is just '0'
384 because you don't know how many series there are in total - perhaps
385 the show is still being made!
386
387 The other predefined system, onscreen, is to simply copy what the
388 programme makers write in the credits - 'Episode #FFEE' would
389 translate to '#FFEE'.
390
391 You are encouraged to use one of these two if possible; if xmltv_ns is
392 not general enough for your needs, let me know. But if you want, you
393 can use your own system and give the 'system' attribute as a URL
394 describing the system you use.
395 -->

I'm not too familiar with GBPVR but in my app this number is pretty critical in the use of creating season passes. I use that series/season ID to schedule all shows for a given season. I then use that with the episode number to prevent duplicate shows from recording. Granted you can move to less precise data like <title> and <desc> <sub-title> but that is no where near as clean as the all important <episode-num>. This doesn't really impact browsing in a grid but I don't see how a clean season pass can be created without this crucial piece of data.

some examples:
EP229827.0220
EP229827.0188
EP229827.0211

In this case EP229827 is Southpark and doesn't change for the entire season (and sometimes is consistent for the series season to season) and .0220, .0188, .0211 are individual episodes.

[sub]

This tag is usually not present in an xmltv file, so GB-PVR doesnt even bother to look for it. It can use some alternative formats though, like zap2it format common in north american xmltv files, for example:

<episode-num system="dd_progid" ="SH809154.0000"/>