[quindel]

Anyone see the problem that when using WIRNS 3, and MSN XML Scrapper, it somehow corrupts the zipcode and doesn't load provider or channel guide into it?


On the bad zipcode, after swapping back from WIRNS 3.0, and going back to the original dns and dmna servers, setting the bad zipcode still comes back with

Connection failed

Replaytv was unable to connect to the replaytv service to get local phone numbers and tv channels

unexpected result code.(93a6000b)


The providers list is blanked for zipcode. So no cable providers are listed now. Using the dmna servers, a forced net connect shows a blank channel guide with no errors. I still cannot choose a provider. All other zipcodes work fine.


THe problem started when I tried WIRNS 3, and MSN XML Scrapper on a Windows 7 machine.


How do I put the provider list back in for that zipcode?


Thanks

 

[Space]



Quote:
Originally Posted by quindel /forum/post/20764902


...

How do I put the provider list back in for that zipcode?


Thanks

Did you try the procedure mentioned in "Switching back?" in this post ?

 

[joblo]

Can someone explain why a previously unused zip code is required to switch back to DNNA?


How exactly does WiNRS corrupt a zip code? Especially when you presumably switched to a different zip code when you connected to WiRNS in the first place?


I mean, I can halfway understand how WiRNS might corrupt any zip you use while talking to it - although if WiRNS is well written it doesn't seem like it should - but how does WiRNS corrupt other zip codes used before you connected to it?

 

[rlichtefeld]



Quote:
Originally Posted by joblo /forum/post/20775148


Can someone explain why a previously unused zip code is required to switch back to DNNA?


How exactly does WiNRS corrupt a zip code? Especially when you presumably switched to a different zip code when you connected to WiRNS in the first place?


I mean, I can halfway understand how WiRNS might corrupt any zip you use while talking to it - although if WiRNS is well written it doesn't seem like it should - but how does WiRNS corrupt other zip codes used before you connected to it?

WiRNS doesn't corrupt it. The ReplayTV caches information about a zip code. You have to change to a new one, so that it will not read out of the cache and will contact the mothership to get new info.


Rob

 

[mlloyd]



Quote:
Originally Posted by rlichtefeld /forum/post/20775192


WiRNS doesn't corrupt it. The ReplayTV caches information about a zip code. You have to change to a new one, so that it will not read out of the cache and will contact the mothership to get new info.


Rob

This cache should have a finite size, and earlier data would be discarded. For example (with a 4-ZIP cache) these are all new ZIP codes:


11111,11112,11113,11114,11115,11111


The last one IS new because it has been removed from the cache to make room for 11115.

 

[joblo]



Quote:
Originally Posted by rlichtefeld /forum/post/20775192


WiRNS doesn't corrupt it. The ReplayTV caches information about a zip code. You have to change to a new one, so that it will not read out of the cache and will contact the mothership to get new info.

My SS contacts DNNA whenever I change the zip in setup from whatever it was to something else. I can switch back and forth between two zip codes A and B all day long, and it will contact the server every time, and never report any errors.


But according to the referenced document, if I use zip code A to contact DNNA, then use zip B to contact WiRNS, and then go back to zip A to contact DNNA again, I may get an error and a failed connection. (At least that's my reading of it; am I misunderstanding that?)


Now what does that have to do with caching exactly? How does contacting WiRNS using zip code B interfere with DNNA's ability to refresh information about zip code A?

Quote:
Originally Posted by mlloyd /forum/post/20775287


This cache should have a finite size, and earlier data would be discarded. For example (with a 4-ZIP cache) these are all new ZIP codes:


11111,11112,11113,11114,11115,11111


The last one IS new because it has been removed from the cache to make room for 11115.

Actually, my SS has lineups for dozens of zip codes, some of them YEARS old. That is, I can still browse these lineups as they existed when I obtained them years ago, because I haven't actually done any recent connections with those zip codes to update the lineup info.


But if I connect to DNNA using one of those codes, no matter how stale the info for it is, DNNA will refresh if without any problems. The question is, how does an intervening connection to WiRNS interfere with that process?