It's called a cablemodem, people. And I have a stack of paychecks that says they'll f*** that up just as bad as cablecard installs. And, btw, doing it like this is in violation of the cablecard spec and UDCP license. (and would still require the SDV client app within the device. not a huge issue for tivo, but certainly is for everyone else -- how do you update the firmware on your TV?)
54-796MHz is the analog band. Give or take. It properly goes all the way to CH137 @ 858MHz, but I've never known anyone to go above CH125. And I've never seen a TV that would go higher than 125.
The "technical reason" is simply to keep the different systems from steping on each other. Analog cable broadcast gear can be quite old. However, I stand corrected... I just rescanned and see TW/Raleigh is now broadcasting digital as low as CH78 -- 10 to 16 stations per channel, btw; analog broadcasts go up to CH76. (125 used to be the EBS channel. It doesn't appear to be there anymore.) The last time I looked, there was nothing below CH100 -- the last published lineup change was 1/23/07. Cablemodems are taking some of those channels as well; my modem is currently locked @ 609MHz (~ch88.)
The point is, they have plenty of "capacity", if they would just use it. There's over 150 channels below 1GHz. Packin' a dozen stations each... But they are simply too greed oriented. They'll do everything they can to make you keep giving them as much money as possible. Plus, they're pissed at the FCC for forcing them to eat their own dog food -- they designed the cablecard but they refuse to use them and go out of their way to make sure they don't work.
No they aren't. Digital cable is in the 250MHz above the 750MHz range of analog cable. There are technical reasons for that, but they disappear when analog cable is shutoff. There have been numerous articles written about this from all over the country. So, your individual milage may vary. For TW/Raleigh, they're all in the upper 250MHz band; I've looked.
Nothing new to see here. SDV has been a problem for 3rd party cable hardware from the get-go. Tivo owners have been in this mess since the Series 3 was released A YEAR AGO. The only thing that's changed is the price for the Tivo HD... it's now cheap enough for some of the village idiots to aford one.
As for the BS comments w.r.t. cablecard requirements... SDV isn't part of those requirements. And wouldn't matter if it did. All the products on the market (and there are things other than tivo's that cannot support SDV, btw) are UNIDIRECTIONAL devices. There are no certification paths for bidirectional devices. (partly because there's no set standard because the cable companies keep changing their mind.) SDV is 100% unnecessary. Cable companies have plenty of capacity if they drop analog cable entirely or even start using the parts that no longer carry stations. (TW/Raleigh has room for ~40 HD stations above the analog broadcasts. That number goes up every year as they reduce the analog tier.)
The reason SDV exists -- and, btw, it was created by Time Warner and Scientific Atlanta -- is to subvert the cablecard mandate and attempt to push back the "integration ban" that took effect (finally) July 1. It's the difference between "spirit" and "letter". However, as SDV is linked in the UDCP license, there may yet be a loophole to their loophole. But I'm pretty sure no cableco will go along with it -- they're doing a bang up job keeping cablecards from working properly in the first place.
Unless you update often, you'll find your system(s) wanting to update dozens, if not hundreds, of packages. And you will run into situations where portage, python, glibc, or some other critical package gets updated which makes almost everything else on the system (re)update. Count yourself lucky that you've never had an update fuck the system up completely -- it happens, and even once is far too often. Portage is a bunch of pyhton scripts that are rather easy to break. That means everything is dependant on python which is equally easy to screw up. And let's not talk about the number of times glibc updates have made the system completely unusable... If I weren't in VMware, these things would be fatal -- thankfully, I can simply revert to a previous snapshot.
It all just feels "primative" to me. And in a large enterprise (where you have more than one server), one (or more) machines need to be set aside as build/maint. machines to generate binary packages for all the other servers -- those servers have actual work to be doing instead of compiling updates for possibly hours.
As for issues with rpms... rpm is just a container (like tar and zip.) There are several rpm based distros. Mixing them can (and as you've seen, WILL) be messy.
AMD64 optimized code in an intel 64bit Core 2 without loss of performance.
Actually, no. Properly optimized AMD code (k8, etc.) will use instructions that do not exist on an EM64T (intel) processor. And k8 optimized code does run faster on k8 systems. I've been down this road many times. "Generic" != "optimal"; generic simply runs "everywhere" making your life as a distro builder easier.
Where every ounce of performance is necessary, custom compiled, fully optimized code is the right way to go. However, that's usually specific to a single application or group of apps. The whole f'ing system doesn't need to be custom compiled for speed. How often do you use ls that a 0.1% speed increase is worth the effort? (Ask a distro maintainer how long it takes to build the entire world.)
(But, ultimately, you're at the mercy of whomever wrote the code. The quality of many modern software projects is simply crap; there's not much a compiler can do to make it much better.)
More often than not, this makes no difference. The browser cannot (or won't) render the page until it has all the elements. Sites that care about this sort of issue put the ads inside iframe's. But even that doesn't always work.
Then they aren't even remotely credible. This is 100% pure paranoid, vengeful bull****. Mainline is written in python. There's no hiding what it does. uTorrent has always been closed source; so no one has ever known exactly what it's doing. Yet, it's only banned once Bittorrent, Inc. buys them. Lame. Now, there are lots of reasons to ban various versions of uTorrent, but "closed source" and "who owns them" aren't on the list.
The bans are a political statement. It has next to nothing to do with "privacy". (there's no such thing when it comes to bittorrent.)
I've seen it with my own eyes, so yes. I don't know what firmware it's running as it's not mine -- I'm not a DISH subscriber, but it's fairly recent release; maybe a week or two?
Actually "HD Lite" (1080i that's 1280x1080) doesn't actually look that bad. Now TNT HD... holy hell what are they thinking. (that's TNT, not DTV/DISH/Cable's fault.)
it's actually better than even this new HD Tivo (Faster interface, more recording time, etc...). Plus, allowing for the recent release date of this Tivo box, it's also going to have a lot less bugs than this new box for a while yet.
Well, seeing as no one has this new box yet, performance comparisions are meaningless. It'll be faster than the S3, which IS faster than a 622. And Tivo's gear is significantly more stable than DISH and DTV hardware. The current firmware on the 622 has a nice handful of bugs that stop it from fetching guide data. I've seen it fist hand -- and find it amusing... "that wouldn't be happening if you still had your tivo." It also fetches guide data once per day unlike the DTV systems that get guide data in "real time" (i.e. continuous download.) Granted, the SA tivos (S1-S3 & "Tivo HD") will only fetch guide data once per day, but those with network connectivity can get "urgent" updates as it's connecting to tivo every hour.
Recording time is a function of the hard drive. You can easily replace the drive with a "much" larger one, and far cheaper than buying the same capacity direct from Tivo. Given the choice, I'll buy the 80GB Tivo HD and put in my own 750-1000GB drive.
DTV is putting very little error correction data in the HD streams -- more bandwidth for the HD. The result... a single drop of rain can cause errors. My dish is aimed perfectly -- power level is high enough set things on fire:-) -- and yet the slightest bit of rain causes pixelation. They don't have that much HD (yet?) so it's rarely a problem.
This is perfectly doable, just not with the bloated crap we call Apache these days. I don't want to sound like an ad, so email me if you want to know more. And bit rate is less important that request rate... a 600M iso image is 600M, but only one request.
Multiconnected distribution mesh. Whatever. The system I was remembering was on slashdot a few years ago, but I still don't remember what it was called.
What I'm suggesting is precisely preseeded Bittorrent...
Nope. What you are describing is the distribution properties of bittorrent. However, bittorrent can never work in this manner. BT is designed for distributing a static block of data; flip a single bit and it's a different block. Guide data is highly variable. So, unless you are going to seed the data file(s) you are getting directly from TMS without much or any modification, then maybe BT would do, but that supposes everyone wants the same data -- i.e. everything.
What you are talking about is much closer to the search system for Kazaa/Fasttrack/etc. In a way... an internet sized spanning tree.
Translation: because it has always been done this way, there can't possibly be a better way.
Translation: I'm smarter than everyone else on Earth. In one afternoon I'll think up a better system than those who've been doing it for a decade.
If there were a better solution, someone would've thought of something different by now. And you're going to create one (that works) on the back of a cocktail napkin in response to a slashdot post? Right. I'll be sure to hold by breath.
How is writing the tool in the first place mooching off everyone else?
Writing it isn't -- and I didn't say so. Throwing it to the community hoping someone else will fix the problem before you have to invest any more of your expensive time. In your own words:
If I wrote one and threw it out to the community to maintain it, the cumulative cost to me for helping to maintain it when I notice something wrong is nearly zero, as chances are, someone will already have fixed it before I notice the problem 9 times out of 10.
The "$50" figure was an estimate. The cheapest selection is $39.99, or so. Add in tax, tag, and the other BS and 50 is good round number. Plus, it's a good bet your subscribed to more than the absolute dirt cheapest minimum package. I see I'm wrong.
Billing is simple if you only do it once a year...
Hah. For someone who makes as much as you claim, you should have better sense. You do realize how businesses actually work? You're going to be picking up new customers one at a time spread out over time. Do you plan to stack up everyone's bill and process them all on one day a year? And presumablly not allow them access until then? See. Laughable.
The service will be charging people the instant they sign up. And there must be confirmation that a bill has been paid. There has to a channel ("CUSTOMER SUPPORT") for dealing with billing errors -- there will be errors... even the teenager taking your order at McDonald's messes up occassionally and they're 2 f'ing feet in front of you. If you think you can use paypal without any such support, and a "no refund" policy, I will warn you not to hang your entire business on it. Paypal is a very dangerous way to fund a business -- paypal has and will continue to close accounts for unspecified reasons (and you may never get your money out of the account.)
Customer service is only mandatory if you're trying to make money or if you're charging enough that you might reasonably get sued if things don't work.
Making money: Check. Charging for something: Check. You are vastly underestimating people's willingness to sue, esp. when a $60 trip to small claims court can put you on the hook for much more than that. (and ruin your credit rating. etc. etc. If you won't spend 5$ for guide data, why would you waste a day for to defend yourself in small claims court?) There's a great deal of satisfaction in screwing the one who screwed you.
As for servers and bandwidth,... would probably be pretty minimal if you designed the distribution protocol correctly...
A bittorrent inspired push model is doomed to fail, for a miriade of reasons. Not the least of which is the port forwarding for an inbound connection from nearly random outside hosts. Granted, MythTV users tend not to be complete idiots, so the expectation of the users getting the port forwarding setup correctly is better than average, but still not 100%. (btw, the spider web distribution you appear to be suggesting is patented. it's been around as long at bittorrent.)
The simplest method with the least complexity that will Just Work(tm), is a simple http request. Each user asks for the data of interest to them. That's how tivo does it; it's how everybody does it. Tivo's been doing this for a decade. If there were a better way to do it reliablly, others would already be doing it.
As an expensive hobby, it might be doable for a single DMA. I know of torrent sites that cost as much (and more) per month to operate. But even that can be a non-trivial amount of work with the variations in cable lineups. But I still think this is a perfect project for Google!
Protected Flash 9 applet fetching data via https with a custom certificate chain... NEXT.
(the custom CA certificate makes a man-in-the-middle ssl proxy impossible. the protected applet makes it very hard to hack the flash into accepting an invalid cert... and the applet can be changed regularly.)
No, $5 per month is way more than the data is worth to me. I'd drop my DirecTV subscription...
I do love the hypocrisy. You refuse to pay 5$/month for clearly useful information, but you're already paying over 50$/month for hours of content you won't ever care to watch. (BTW, as a DTV subscriber, you're already paying TMS for guide data... that's where the program guide comes from.)
If you think it's so easy to write and maintain a scraper, Go. Right. Ahead. I'll sit quitely over here and time you. And "throwing it to the community" to maintain it isn't "maintain[ing] a scraper myself." That's not your time being invested... that's you mooching off everyone else -- translation, your time is more valuable.
Put yet another way, as I understand it...
Please tell me you have professionals managing your finances. Providing a tv listings service will take far more than the $500/month paid to TMS for the data itself. You're ignoring the cost of servers, co-lo rack space, bandwidth, billing, and of course, customer support -- just to name a few things. It'll take a fair ball of cash up front and at least a year to get it back (if you ever do.) [there's much more to a business plan than a rant on slashdot.]
The tivo service fee isn't 100% "to pay for the guide data". Yes, Tivo, Inc. has to pay TMS per unit, but it also costs tivo to serve the files to each tivo -- a lot still use DIALUP -- and develop the software it's running. And I'll remind everyone again, Tivo, Inc. still isn't profitable.
(The fee for 2+ units is $6.95, so you get some break with more than one tivo.)
Ok, so you'll need to get a handful of people in every DMA to key in the guide data for every station in that DMA. Every. Day. At least a day ahead of time. That'll cover the thousand or so broadcast stations. This doesn't address how they know what's going to be on -- paying for newspapers, TV Guide, etc. or manually reentering data from various web pages.
And then get a second bunch of suckers, err, people to do the same for all the premium/non-broadcast channels. (btw, some of them don't even update their own listings correctly.)
In total, it'll take thousands of people all over the country constantly pushing updates. TMS has a dedicated, experienced staff with direct data feeds from the stations... and they still mess it up frequently. One might think this is just like CDDB, but TV listings are highly dynamic and time sensitive making it much more difficult to maintain -- nobody cares what was on last week; MythTV cannot record things in the past. It's closest to the undertaking of Moiveminder... and that was more than enough work for a dozen people to keep up with the slowly changing movie listings for RDU. TV lists are many orders of magnitude more work.
The best you could do is what Tivo, ReplayTV, cable companies, DISH, DTV, et. al. do... get a commercial data feed from TMS, transform it for the specific system(s) and push it to the receivers. This is VERY non-free. It takes infrastructure... mainly people and bandwidth. And then people will do to you what they've been doing to zap2it/xmltv... buy one account and use it on thousands of commercial systems.
I would love to see someone sell tv listing data feeds. It's far cheaper and more useful than dead-tree listings. Neither TV Guide nor local newspapers provide a "digital subscription." However, this still wouldn't address those cheap bastards that refuse to pay at all, but it'd be a start. (and it would still have the same issues of today's zap2it... commericial devices sold using a "personal" account.)
Yep. Because people would rather spend more time and money building their own "crap" than buy a commercial product and pay for a subscription to tv listings.
Slashdot Mirror
It's called a cablemodem, people. And I have a stack of paychecks that says they'll f*** that up just as bad as cablecard installs. And, btw, doing it like this is in violation of the cablecard spec and UDCP license. (and would still require the SDV client app within the device. not a huge issue for tivo, but certainly is for everyone else -- how do you update the firmware on your TV?)
54-796MHz is the analog band. Give or take. It properly goes all the way to CH137 @ 858MHz, but I've never known anyone to go above CH125. And I've never seen a TV that would go higher than 125.
The "technical reason" is simply to keep the different systems from steping on each other. Analog cable broadcast gear can be quite old. However, I stand corrected... I just rescanned and see TW/Raleigh is now broadcasting digital as low as CH78 -- 10 to 16 stations per channel, btw; analog broadcasts go up to CH76. (125 used to be the EBS channel. It doesn't appear to be there anymore.) The last time I looked, there was nothing below CH100 -- the last published lineup change was 1/23/07. Cablemodems are taking some of those channels as well; my modem is currently locked @ 609MHz (~ch88.)
The point is, they have plenty of "capacity", if they would just use it. There's over 150 channels below 1GHz. Packin' a dozen stations each... But they are simply too greed oriented. They'll do everything they can to make you keep giving them as much money as possible. Plus, they're pissed at the FCC for forcing them to eat their own dog food -- they designed the cablecard but they refuse to use them and go out of their way to make sure they don't work.
No they aren't. Digital cable is in the 250MHz above the 750MHz range of analog cable. There are technical reasons for that, but they disappear when analog cable is shutoff. There have been numerous articles written about this from all over the country. So, your individual milage may vary. For TW/Raleigh, they're all in the upper 250MHz band; I've looked.
Some places charge far more than that. And there's the "additional outlet" fee charged for each card even when they're in the same device.
Nothing new to see here. SDV has been a problem for 3rd party cable hardware from the get-go. Tivo owners have been in this mess since the Series 3 was released A YEAR AGO. The only thing that's changed is the price for the Tivo HD... it's now cheap enough for some of the village idiots to aford one.
As for the BS comments w.r.t. cablecard requirements... SDV isn't part of those requirements. And wouldn't matter if it did. All the products on the market (and there are things other than tivo's that cannot support SDV, btw) are UNIDIRECTIONAL devices. There are no certification paths for bidirectional devices. (partly because there's no set standard because the cable companies keep changing their mind.) SDV is 100% unnecessary. Cable companies have plenty of capacity if they drop analog cable entirely or even start using the parts that no longer carry stations. (TW/Raleigh has room for ~40 HD stations above the analog broadcasts. That number goes up every year as they reduce the analog tier.)
The reason SDV exists -- and, btw, it was created by Time Warner and Scientific Atlanta -- is to subvert the cablecard mandate and attempt to push back the "integration ban" that took effect (finally) July 1. It's the difference between "spirit" and "letter". However, as SDV is linked in the UDCP license, there may yet be a loophole to their loophole. But I'm pretty sure no cableco will go along with it -- they're doing a bang up job keeping cablecards from working properly in the first place.
Unless you update often, you'll find your system(s) wanting to update dozens, if not hundreds, of packages. And you will run into situations where portage, python, glibc, or some other critical package gets updated which makes almost everything else on the system (re)update. Count yourself lucky that you've never had an update fuck the system up completely -- it happens, and even once is far too often. Portage is a bunch of pyhton scripts that are rather easy to break. That means everything is dependant on python which is equally easy to screw up. And let's not talk about the number of times glibc updates have made the system completely unusable... If I weren't in VMware, these things would be fatal -- thankfully, I can simply revert to a previous snapshot.
It all just feels "primative" to me. And in a large enterprise (where you have more than one server), one (or more) machines need to be set aside as build/maint. machines to generate binary packages for all the other servers -- those servers have actual work to be doing instead of compiling updates for possibly hours.
As for issues with rpms... rpm is just a container (like tar and zip.) There are several rpm based distros. Mixing them can (and as you've seen, WILL) be messy.
Where every ounce of performance is necessary, custom compiled, fully optimized code is the right way to go. However, that's usually specific to a single application or group of apps. The whole f'ing system doesn't need to be custom compiled for speed. How often do you use ls that a 0.1% speed increase is worth the effort? (Ask a distro maintainer how long it takes to build the entire world.)
(But, ultimately, you're at the mercy of whomever wrote the code. The quality of many modern software projects is simply crap; there's not much a compiler can do to make it much better.)
Not at all. There are ISPs all over the world already doing this -- and have been for a very long time.
More often than not, this makes no difference. The browser cannot (or won't) render the page until it has all the elements. Sites that care about this sort of issue put the ads inside iframe's. But even that doesn't always work.
So, parking tickets are unconstitutional as well? They ticket the CAR's OWNER, not the idiot who was driving it.
That's from a different episode. The picture on the wiki page shows a tether, but the youtube snippet doesn't.
I remember that episode... He didn't bounce it off the ship. He threw it to Adric(?) -- standing on the ship -- who then threw it back to him.
But, then Dr. isn't human, so who knows what space would do to him.
The bans are a political statement. It has next to nothing to do with "privacy". (there's no such thing when it comes to bittorrent.)
I've seen it with my own eyes, so yes. I don't know what firmware it's running as it's not mine -- I'm not a DISH subscriber, but it's fairly recent release; maybe a week or two?
Actually "HD Lite" (1080i that's 1280x1080) doesn't actually look that bad. Now TNT HD... holy hell what are they thinking. (that's TNT, not DTV/DISH/Cable's fault.)
Recording time is a function of the hard drive. You can easily replace the drive with a "much" larger one, and far cheaper than buying the same capacity direct from Tivo. Given the choice, I'll buy the 80GB Tivo HD and put in my own 750-1000GB drive.
DTV is putting very little error correction data in the HD streams -- more bandwidth for the HD. The result... a single drop of rain can cause errors. My dish is aimed perfectly -- power level is high enough set things on fire :-) -- and yet the slightest bit of rain causes pixelation. They don't have that much HD (yet?) so it's rarely a problem.
This is perfectly doable, just not with the bloated crap we call Apache these days. I don't want to sound like an ad, so email me if you want to know more. And bit rate is less important that request rate... a 600M iso image is 600M, but only one request.
What you are talking about is much closer to the search system for Kazaa/Fasttrack/etc. In a way... an internet sized spanning tree.Translation: I'm smarter than everyone else on Earth. In one afternoon I'll think up a better system than those who've been doing it for a decade.
If there were a better solution, someone would've thought of something different by now. And you're going to create one (that works) on the back of a cocktail napkin in response to a slashdot post? Right. I'll be sure to hold by breath.
The "$50" figure was an estimate. The cheapest selection is $39.99, or so. Add in tax, tag, and the other BS and 50 is good round number. Plus, it's a good bet your subscribed to more than the absolute dirt cheapest minimum package. I see I'm wrong.Hah. For someone who makes as much as you claim, you should have better sense. You do realize how businesses actually work? You're going to be picking up new customers one at a time spread out over time. Do you plan to stack up everyone's bill and process them all on one day a year? And presumablly not allow them access until then? See. Laughable.
The service will be charging people the instant they sign up. And there must be confirmation that a bill has been paid. There has to a channel ("CUSTOMER SUPPORT") for dealing with billing errors -- there will be errors... even the teenager taking your order at McDonald's messes up occassionally and they're 2 f'ing feet in front of you. If you think you can use paypal without any such support, and a "no refund" policy, I will warn you not to hang your entire business on it. Paypal is a very dangerous way to fund a business -- paypal has and will continue to close accounts for unspecified reasons (and you may never get your money out of the account.)Making money: Check. Charging for something: Check. You are vastly underestimating people's willingness to sue, esp. when a $60 trip to small claims court can put you on the hook for much more than that. (and ruin your credit rating. etc. etc. If you won't spend 5$ for guide data, why would you waste a day for to defend yourself in small claims court?) There's a great deal of satisfaction in screwing the one who screwed you.A bittorrent inspired push model is doomed to fail, for a miriade of reasons. Not the least of which is the port forwarding for an inbound connection from nearly random outside hosts. Granted, MythTV users tend not to be complete idiots, so the expectation of the users getting the port forwarding setup correctly is better than average, but still not 100%. (btw, the spider web distribution you appear to be suggesting is patented. it's been around as long at bittorrent.)
The simplest method with the least complexity that will Just Work(tm), is a simple http request. Each user asks for the data of interest to them. That's how tivo does it; it's how everybody does it. Tivo's been doing this for a decade. If there were a better way to do it reliablly, others would already be doing it.
As an expensive hobby, it might be doable for a single DMA. I know of torrent sites that cost as much (and more) per month to operate. But even that can be a non-trivial amount of work with the variations in cable lineups. But I still think this is a perfect project for Google!
Protected Flash 9 applet fetching data via https with a custom certificate chain... NEXT.
(the custom CA certificate makes a man-in-the-middle ssl proxy impossible. the protected applet makes it very hard to hack the flash into accepting an invalid cert... and the applet can be changed regularly.)
If you think it's so easy to write and maintain a scraper, Go. Right. Ahead. I'll sit quitely over here and time you. And "throwing it to the community" to maintain it isn't "maintain[ing] a scraper myself." That's not your time being invested... that's you mooching off everyone else -- translation, your time is more valuable.Please tell me you have professionals managing your finances. Providing a tv listings service will take far more than the $500/month paid to TMS for the data itself. You're ignoring the cost of servers, co-lo rack space, bandwidth, billing, and of course, customer support -- just to name a few things. It'll take a fair ball of cash up front and at least a year to get it back (if you ever do.) [there's much more to a business plan than a rant on slashdot.]
The tivo service fee isn't 100% "to pay for the guide data". Yes, Tivo, Inc. has to pay TMS per unit, but it also costs tivo to serve the files to each tivo -- a lot still use DIALUP -- and develop the software it's running. And I'll remind everyone again, Tivo, Inc. still isn't profitable.
(The fee for 2+ units is $6.95, so you get some break with more than one tivo.)
Ok, so you'll need to get a handful of people in every DMA to key in the guide data for every station in that DMA. Every. Day. At least a day ahead of time. That'll cover the thousand or so broadcast stations. This doesn't address how they know what's going to be on -- paying for newspapers, TV Guide, etc. or manually reentering data from various web pages.
And then get a second bunch of suckers, err, people to do the same for all the premium/non-broadcast channels. (btw, some of them don't even update their own listings correctly.)
In total, it'll take thousands of people all over the country constantly pushing updates. TMS has a dedicated, experienced staff with direct data feeds from the stations... and they still mess it up frequently. One might think this is just like CDDB, but TV listings are highly dynamic and time sensitive making it much more difficult to maintain -- nobody cares what was on last week; MythTV cannot record things in the past. It's closest to the undertaking of Moiveminder... and that was more than enough work for a dozen people to keep up with the slowly changing movie listings for RDU. TV lists are many orders of magnitude more work.
The best you could do is what Tivo, ReplayTV, cable companies, DISH, DTV, et. al. do... get a commercial data feed from TMS, transform it for the specific system(s) and push it to the receivers. This is VERY non-free. It takes infrastructure... mainly people and bandwidth. And then people will do to you what they've been doing to zap2it/xmltv... buy one account and use it on thousands of commercial systems.
I would love to see someone sell tv listing data feeds. It's far cheaper and more useful than dead-tree listings. Neither TV Guide nor local newspapers provide a "digital subscription." However, this still wouldn't address those cheap bastards that refuse to pay at all, but it'd be a start. (and it would still have the same issues of today's zap2it... commericial devices sold using a "personal" account.)
Yep. Because people would rather spend more time and money building their own "crap" than buy a commercial product and pay for a subscription to tv listings.
Sometimes I'm amazed by how cheap people can be.