Broadband Guide update failing

[Guest]

Archived from groups: alt.video.ptv.replaytv (More info?)

Hmmm,

I tried clearing the guide but only once. I'll try clearing the guide twice
and see if that makes a difference.

George


Mark Lloyd <mlloyd@5xxxmail.com5xxx> writes:

>On Sun, 10 Apr 2005 21:03:34 -0500, george@agora.rdrop.com (George
>Rachor) wrote:

>>Mark,
>>
>>
>>I bypassed the linksys and got the same result (Most of the way through the transaction
>>to replay then a failure message.
>>
>>I put a sniffer on the network line between the replay and my homenetwork.
>>
>>1. The replay is getting the time via ntp from production.replaytv.net
>>2. On the first HTTP Get to production.replaytv.net I see the following curious
>> line:
>> Dissector bug, protocol HTTP: "Request URI" - "http.request.uri" invalid length: -5 (proto.c:2104)
>>
>>
>>The following HTTP Gets have the same curious line...
>>
>>Any new thoughts?
>>

>The problem may involve merging new information with an existing
>(corrupted) guide. Try clearing the Replay guide using 2-4-3-Zones
>option 2 (people say you need to do this 2 times), then requesting a
>new guide (manual connect).

>>George Rachor
>>
>>
>>Mark Lloyd <mlloyd@5xxxmail.com5xxx> writes:
>>
>>>On Sat, 02 Apr 2005 10:01:03 -0600, george@agora.rdrop.com (George
>>>Rachor) wrote:
>>
>>>>I've got a replaytv model 5508 that up until 2 weeks ago was updateing
>>>>the program guide just fine
>>>>via my internet connection.
>>>>
>>>>My connection consists of the replaytv on a home network
>>>>behind a linksys router. That router is then connected to the ISP's equipment.
>>>>
>>>>I had to change the settings last night to start updating
>>>>via phone line because something has changed and now updating
>>>>the program guide via the network connection is failing. In watching
>>>>the progress it looks like we get most of the way through
>>>>before getting a message that the update has failed and it will
>>>>try again later. The last message I see is "combining data ..."
>>>>
>>>>I'm trying to figure out if something has changed upstream with my
>>>>ISP or if something has happened to my Linksys.
>>>>
>>>>Any thoughts would be appreciated.
>>
>>>The way the Replay handles errors can be misleading. There can be a
>>>failure near the beginning, then the process seems to get all the way
>>>through before you're told about it.
>>
>>>Is your Replay set to get a dynamic local IP from the router? If so,
>>>you may need to refresh it (because of ISP making changes). Otherwise,
>>>check carefully. The ISP could have changed DNS servers.
>>
>>>--
>>>Mark Lloyd
>>>has a Replay 5xxx
>>>http/notstupid.laughingsquid.com
>>
>>>"The idea that there is an invisible being who
>>>created and still runs this old universe is so
>>>childish, so obviously contrived, that it is hard to
>>>believe anyone with even a modicum of education can
>>>still fall for that scam."

>--
>Mark Lloyd
>has a Replay 5xxx
>http/notstupid.laughingsquid.com

>"The idea that there is an invisible being who
>created and still runs this old universe is so
>childish, so obviously contrived, that it is hard to
>believe anyone with even a modicum of education can
>still fall for that scam."
--
=========================================================
George L. Rachor Jr. george@rachors.com
Hillsboro, Oregon http:rachors.com
United States of America Amateur Radio : KD7DCX

 

[Guest]

Archived from groups: alt.video.ptv.replaytv (More info?)

OK... Cleared the guide twice but still getting the error right after 'combining data'.

I had to change back to dialup to get the guide re-populated...

I'm tempted to buy another replay and see if it has the same problem. That would let me determine
if the problem is in the unit (bad software) or upstream in my network.
I was thinking about another replay anyway.

George


Mark Lloyd <mlloyd@5xxxmail.com5xxx> writes:

>On Sun, 10 Apr 2005 21:03:34 -0500, george@agora.rdrop.com (George
>Rachor) wrote:

>>Mark,
>>
>>
>>I bypassed the linksys and got the same result (Most of the way through the transaction
>>to replay then a failure message.
>>
>>I put a sniffer on the network line between the replay and my homenetwork.
>>
>>1. The replay is getting the time via ntp from production.replaytv.net
>>2. On the first HTTP Get to production.replaytv.net I see the following curious
>> line:
>> Dissector bug, protocol HTTP: "Request URI" - "http.request.uri" invalid length: -5 (proto.c:2104)
>>
>>
>>The following HTTP Gets have the same curious line...
>>
>>Any new thoughts?
>>

>The problem may involve merging new information with an existing
>(corrupted) guide. Try clearing the Replay guide using 2-4-3-Zones
>option 2 (people say you need to do this 2 times), then requesting a
>new guide (manual connect).

>>George Rachor
>>
>>
>>Mark Lloyd <mlloyd@5xxxmail.com5xxx> writes:
>>
>>>On Sat, 02 Apr 2005 10:01:03 -0600, george@agora.rdrop.com (George
>>>Rachor) wrote:
>>
>>>>I've got a replaytv model 5508 that up until 2 weeks ago was updateing
>>>>the program guide just fine
>>>>via my internet connection.
>>>>
>>>>My connection consists of the replaytv on a home network
>>>>behind a linksys router. That router is then connected to the ISP's equipment.
>>>>
>>>>I had to change the settings last night to start updating
>>>>via phone line because something has changed and now updating
>>>>the program guide via the network connection is failing. In watching
>>>>the progress it looks like we get most of the way through
>>>>before getting a message that the update has failed and it will
>>>>try again later. The last message I see is "combining data ..."
>>>>
>>>>I'm trying to figure out if something has changed upstream with my
>>>>ISP or if something has happened to my Linksys.
>>>>
>>>>Any thoughts would be appreciated.
>>
>>>The way the Replay handles errors can be misleading. There can be a
>>>failure near the beginning, then the process seems to get all the way
>>>through before you're told about it.
>>
>>>Is your Replay set to get a dynamic local IP from the router? If so,
>>>you may need to refresh it (because of ISP making changes). Otherwise,
>>>check carefully. The ISP could have changed DNS servers.
>>
>>>--
>>>Mark Lloyd
>>>has a Replay 5xxx
>>>http/notstupid.laughingsquid.com
>>
>>>"The idea that there is an invisible being who
>>>created and still runs this old universe is so
>>>childish, so obviously contrived, that it is hard to
>>>believe anyone with even a modicum of education can
>>>still fall for that scam."

>--
>Mark Lloyd
>has a Replay 5xxx
>http/notstupid.laughingsquid.com

>"The idea that there is an invisible being who
>created and still runs this old universe is so
>childish, so obviously contrived, that it is hard to
>believe anyone with even a modicum of education can
>still fall for that scam."
--
=========================================================
George L. Rachor Jr. george@rachors.com
Hillsboro, Oregon http:rachors.com
United States of America Amateur Radio : KD7DCX

 

[Guest]

Archived from groups: alt.video.ptv.replaytv (More info?)

On Tue, 12 Apr 2005 11:53:19 -0500, george@agora.rdrop.com (George
Rachor) wrote:

>
>OK... Cleared the guide twice but still getting the error right after 'combining data'.
>
>I had to change back to dialup to get the guide re-populated...
>
>I'm tempted to buy another replay and see if it has the same problem. That would let me determine
>if the problem is in the unit (bad software) or upstream in my network.
>I was thinking about another replay anyway.
>
>George
>

It's spending more money, but probably a good idea. Problems are
easier to locate when you have multiple units.

>Mark Lloyd <mlloyd@5xxxmail.com5xxx> writes:
>
>>On Sun, 10 Apr 2005 21:03:34 -0500, george@agora.rdrop.com (George
>>Rachor) wrote:
>
>>>Mark,
>>>
>>>
>>>I bypassed the linksys and got the same result (Most of the way through the transaction
>>>to replay then a failure message.
>>>
>>>I put a sniffer on the network line between the replay and my homenetwork.
>>>
>>>1. The replay is getting the time via ntp from production.replaytv.net
>>>2. On the first HTTP Get to production.replaytv.net I see the following curious
>>> line:
>>> Dissector bug, protocol HTTP: "Request URI" - "http.request.uri" invalid length: -5 (proto.c:2104)
>>>
>>>
>>>The following HTTP Gets have the same curious line...
>>>
>>>Any new thoughts?
>>>
>
>>The problem may involve merging new information with an existing
>>(corrupted) guide. Try clearing the Replay guide using 2-4-3-Zones
>>option 2 (people say you need to do this 2 times), then requesting a
>>new guide (manual connect).
>
>>>George Rachor
>>>
>>>
>>>Mark Lloyd <mlloyd@5xxxmail.com5xxx> writes:
>>>
>>>>On Sat, 02 Apr 2005 10:01:03 -0600, george@agora.rdrop.com (George
>>>>Rachor) wrote:
>>>
>>>>>I've got a replaytv model 5508 that up until 2 weeks ago was updateing
>>>>>the program guide just fine
>>>>>via my internet connection.
>>>>>
>>>>>My connection consists of the replaytv on a home network
>>>>>behind a linksys router. That router is then connected to the ISP's equipment.
>>>>>
>>>>>I had to change the settings last night to start updating
>>>>>via phone line because something has changed and now updating
>>>>>the program guide via the network connection is failing. In watching
>>>>>the progress it looks like we get most of the way through
>>>>>before getting a message that the update has failed and it will
>>>>>try again later. The last message I see is "combining data ..."
>>>>>
>>>>>I'm trying to figure out if something has changed upstream with my
>>>>>ISP or if something has happened to my Linksys.
>>>>>
>>>>>Any thoughts would be appreciated.
>>>
>>>>The way the Replay handles errors can be misleading. There can be a
>>>>failure near the beginning, then the process seems to get all the way
>>>>through before you're told about it.
>>>
>>>>Is your Replay set to get a dynamic local IP from the router? If so,
>>>>you may need to refresh it (because of ISP making changes). Otherwise,
>>>>check carefully. The ISP could have changed DNS servers.
>>>
>>>>--
>>>>Mark Lloyd
>>>>has a Replay 5xxx
>>>>http/notstupid.laughingsquid.com
>>>
>>>>"The idea that there is an invisible being who
>>>>created and still runs this old universe is so
>>>>childish, so obviously contrived, that it is hard to
>>>>believe anyone with even a modicum of education can
>>>>still fall for that scam."
>
>>--
>>Mark Lloyd
>>has a Replay 5xxx
>>http/notstupid.laughingsquid.com
>
>>"The idea that there is an invisible being who
>>created and still runs this old universe is so
>>childish, so obviously contrived, that it is hard to
>>believe anyone with even a modicum of education can
>>still fall for that scam."

--
Mark Lloyd
has a Replay 5xxx
http/notstupid.laughingsquid.com

"The idea that there is an invisible being who
created and still runs this old universe is so
childish, so obviously contrived, that it is hard to
believe anyone with even a modicum of education can
still fall for that scam."

 

[Guest]

Archived from groups: alt.video.ptv.replaytv (More info?)

I was going to get one anyway.... Might as well do it now.

I did notice one more difference between dialup conversations
and ethernet conversation.

When doing Ethernet based conversations I see dialog about getting replayzones. There
is a seperate message for zones 1-16 and I don't see this with the phone based
conversations.

Thanks for the suggestions.

George Rachor
george@rachors.com

Mark Lloyd <mlloyd@5xxxmail.com5xxx> writes:


>On Tue, 12 Apr 2005 11:53:19 -0500, george@agora.rdrop.com (George
>Rachor) wrote:

>>
>>OK... Cleared the guide twice but still getting the error right after 'combining data'.
>>
>>I had to change back to dialup to get the guide re-populated...
>>
>>I'm tempted to buy another replay and see if it has the same problem. That would let me determine
>>if the problem is in the unit (bad software) or upstream in my network.
>>I was thinking about another replay anyway.
>>
>>George
>>

>It's spending more money, but probably a good idea. Problems are
>easier to locate when you have multiple units.

>>Mark Lloyd <mlloyd@5xxxmail.com5xxx> writes:
>>
>>>On Sun, 10 Apr 2005 21:03:34 -0500, george@agora.rdrop.com (George
>>>Rachor) wrote:
>>
>>>>Mark,
>>>>
>>>>
>>>>I bypassed the linksys and got the same result (Most of the way through the transaction
>>>>to replay then a failure message.
>>>>
>>>>I put a sniffer on the network line between the replay and my homenetwork.
>>>>
>>>>1. The replay is getting the time via ntp from production.replaytv.net
>>>>2. On the first HTTP Get to production.replaytv.net I see the following curious
>>>> line:
>>>> Dissector bug, protocol HTTP: "Request URI" - "http.request.uri" invalid length: -5 (proto.c:2104)
>>>>
>>>>
>>>>The following HTTP Gets have the same curious line...
>>>>
>>>>Any new thoughts?
>>>>
>>
>>>The problem may involve merging new information with an existing
>>>(corrupted) guide. Try clearing the Replay guide using 2-4-3-Zones
>>>option 2 (people say you need to do this 2 times), then requesting a
>>>new guide (manual connect).
>>
>>>>George Rachor
>>>>
>>>>
>>>>Mark Lloyd <mlloyd@5xxxmail.com5xxx> writes:
>>>>
>>>>>On Sat, 02 Apr 2005 10:01:03 -0600, george@agora.rdrop.com (George
>>>>>Rachor) wrote:
>>>>
>>>>>>I've got a replaytv model 5508 that up until 2 weeks ago was updateing
>>>>>>the program guide just fine
>>>>>>via my internet connection.
>>>>>>
>>>>>>My connection consists of the replaytv on a home network
>>>>>>behind a linksys router. That router is then connected to the ISP's equipment.
>>>>>>
>>>>>>I had to change the settings last night to start updating
>>>>>>via phone line because something has changed and now updating
>>>>>>the program guide via the network connection is failing. In watching
>>>>>>the progress it looks like we get most of the way through
>>>>>>before getting a message that the update has failed and it will
>>>>>>try again later. The last message I see is "combining data ..."
>>>>>>
>>>>>>I'm trying to figure out if something has changed upstream with my
>>>>>>ISP or if something has happened to my Linksys.
>>>>>>
>>>>>>Any thoughts would be appreciated.
>>>>
>>>>>The way the Replay handles errors can be misleading. There can be a
>>>>>failure near the beginning, then the process seems to get all the way
>>>>>through before you're told about it.
>>>>
>>>>>Is your Replay set to get a dynamic local IP from the router? If so,
>>>>>you may need to refresh it (because of ISP making changes). Otherwise,
>>>>>check carefully. The ISP could have changed DNS servers.
>>>>
>>>>>--
>>>>>Mark Lloyd
>>>>>has a Replay 5xxx
>>>>>http/notstupid.laughingsquid.com
>>>>
>>>>>"The idea that there is an invisible being who
>>>>>created and still runs this old universe is so
>>>>>childish, so obviously contrived, that it is hard to
>>>>>believe anyone with even a modicum of education can
>>>>>still fall for that scam."
>>
>>>--
>>>Mark Lloyd
>>>has a Replay 5xxx
>>>http/notstupid.laughingsquid.com
>>
>>>"The idea that there is an invisible being who
>>>created and still runs this old universe is so
>>>childish, so obviously contrived, that it is hard to
>>>believe anyone with even a modicum of education can
>>>still fall for that scam."

>--
>Mark Lloyd
>has a Replay 5xxx
>http/notstupid.laughingsquid.com

>"The idea that there is an invisible being who
>created and still runs this old universe is so
>childish, so obviously contrived, that it is hard to
>believe anyone with even a modicum of education can
>still fall for that scam."
--
=========================================================
George L. Rachor Jr. george@rachors.com
Hillsboro, Oregon http:rachors.com
United States of America Amateur Radio : KD7DCX

 

[Guest]

Archived from groups: alt.video.ptv.replaytv (More info?)

george@agora.rdrop.com (George Rachor) writes:
OK... Looked again at Etherreal packets between my replay and production.replaytv.net and discovered that my replaytv
is sending a series of commands for which production.replaytv.net is returning the message
"400- Bad Request"

so it looks like my replay is requesting bad information. Funny how that doesn't screw
things up when dialing.

George


>I was going to get one anyway.... Might as well do it now.

>I did notice one more difference between dialup conversations
>and ethernet conversation.

>When doing Ethernet based conversations I see dialog about getting replayzones. There
>is a seperate message for zones 1-16 and I don't see this with the phone based
>conversations.

>Thanks for the suggestions.

>George Rachor
>george@rachors.com

>Mark Lloyd <mlloyd@5xxxmail.com5xxx> writes:


>>On Tue, 12 Apr 2005 11:53:19 -0500, george@agora.rdrop.com (George
>>Rachor) wrote:

>>>
>>>OK... Cleared the guide twice but still getting the error right after 'combining data'.
>>>
>>>I had to change back to dialup to get the guide re-populated...
>>>
>>>I'm tempted to buy another replay and see if it has the same problem. That would let me determine
>>>if the problem is in the unit (bad software) or upstream in my network.
>>>I was thinking about another replay anyway.
>>>
>>>George
>>>

>>It's spending more money, but probably a good idea. Problems are
>>easier to locate when you have multiple units.

>>>Mark Lloyd <mlloyd@5xxxmail.com5xxx> writes:
>>>
>>>>On Sun, 10 Apr 2005 21:03:34 -0500, george@agora.rdrop.com (George
>>>>Rachor) wrote:
>>>
>>>>>Mark,
>>>>>
>>>>>
>>>>>I bypassed the linksys and got the same result (Most of the way through the transaction
>>>>>to replay then a failure message.
>>>>>
>>>>>I put a sniffer on the network line between the replay and my homenetwork.
>>>>>
>>>>>1. The replay is getting the time via ntp from production.replaytv.net
>>>>>2. On the first HTTP Get to production.replaytv.net I see the following curious
>>>>> line:
>>>>> Dissector bug, protocol HTTP: "Request URI" - "http.request.uri" invalid length: -5 (proto.c:2104)
>>>>>
>>>>>
>>>>>The following HTTP Gets have the same curious line...
>>>>>
>>>>>Any new thoughts?
>>>>>
>>>
>>>>The problem may involve merging new information with an existing
>>>>(corrupted) guide. Try clearing the Replay guide using 2-4-3-Zones
>>>>option 2 (people say you need to do this 2 times), then requesting a
>>>>new guide (manual connect).
>>>
>>>>>George Rachor
>>>>>
>>>>>
>>>>>Mark Lloyd <mlloyd@5xxxmail.com5xxx> writes:
>>>>>
>>>>>>On Sat, 02 Apr 2005 10:01:03 -0600, george@agora.rdrop.com (George
>>>>>>Rachor) wrote:
>>>>>
>>>>>>>I've got a replaytv model 5508 that up until 2 weeks ago was updateing
>>>>>>>the program guide just fine
>>>>>>>via my internet connection.
>>>>>>>
>>>>>>>My connection consists of the replaytv on a home network
>>>>>>>behind a linksys router. That router is then connected to the ISP's equipment.
>>>>>>>
>>>>>>>I had to change the settings last night to start updating
>>>>>>>via phone line because something has changed and now updating
>>>>>>>the program guide via the network connection is failing. In watching
>>>>>>>the progress it looks like we get most of the way through
>>>>>>>before getting a message that the update has failed and it will
>>>>>>>try again later. The last message I see is "combining data ..."
>>>>>>>
>>>>>>>I'm trying to figure out if something has changed upstream with my
>>>>>>>ISP or if something has happened to my Linksys.
>>>>>>>
>>>>>>>Any thoughts would be appreciated.
>>>>>
>>>>>>The way the Replay handles errors can be misleading. There can be a
>>>>>>failure near the beginning, then the process seems to get all the way
>>>>>>through before you're told about it.
>>>>>
>>>>>>Is your Replay set to get a dynamic local IP from the router? If so,
>>>>>>you may need to refresh it (because of ISP making changes). Otherwise,
>>>>>>check carefully. The ISP could have changed DNS servers.
>>>>>
>>>>>>--
>>>>>>Mark Lloyd
>>>>>>has a Replay 5xxx
>>>>>>http/notstupid.laughingsquid.com
>>>>>
>>>>>>"The idea that there is an invisible being who
>>>>>>created and still runs this old universe is so
>>>>>>childish, so obviously contrived, that it is hard to
>>>>>>believe anyone with even a modicum of education can
>>>>>>still fall for that scam."
>>>
>>>>--
>>>>Mark Lloyd
>>>>has a Replay 5xxx
>>>>http/notstupid.laughingsquid.com
>>>
>>>>"The idea that there is an invisible being who
>>>>created and still runs this old universe is so
>>>>childish, so obviously contrived, that it is hard to
>>>>believe anyone with even a modicum of education can
>>>>still fall for that scam."

>>--
>>Mark Lloyd
>>has a Replay 5xxx
>>http/notstupid.laughingsquid.com

>>"The idea that there is an invisible being who
>>created and still runs this old universe is so
>>childish, so obviously contrived, that it is hard to
>>believe anyone with even a modicum of education can
>>still fall for that scam."
>--
>=========================================================
>George L. Rachor Jr. george@rachors.com
>Hillsboro, Oregon http:rachors.com
>United States of America Amateur Radio : KD7DCX
--
=========================================================
George L. Rachor Jr. george@rachors.com
Hillsboro, Oregon http:rachors.com
United States of America Amateur Radio : KD7DCX

 

[Guest]

Archived from groups: alt.video.ptv.replaytv (More info?)

On Tue, 12 Apr 2005 23:42:06 -0500, george@agora.rdrop.com (George
Rachor) wrote:

>george@agora.rdrop.com (George Rachor) writes:
>OK... Looked again at Etherreal packets between my replay and production.replaytv.net and discovered that my replaytv
>is sending a series of commands for which production.replaytv.net is returning the message
>"400- Bad Request"
>
>so it looks like my replay is requesting bad information. Funny how that doesn't screw
>things up when dialing.
>
>George
>

The software could be so corrrupted that the only thing you can do is
restore a new software image. This will mean you lose all your
personal settings (such as theme channels) and recorded shows, but
will not affect activation.

>
>>I was going to get one anyway.... Might as well do it now.
>
>>I did notice one more difference between dialup conversations
>>and ethernet conversation.
>
>>When doing Ethernet based conversations I see dialog about getting replayzones. There
>>is a seperate message for zones 1-16 and I don't see this with the phone based
>>conversations.
>
>>Thanks for the suggestions.
>
>>George Rachor
>>george@rachors.com
>
>>Mark Lloyd <mlloyd@5xxxmail.com5xxx> writes:
>
>
>>>On Tue, 12 Apr 2005 11:53:19 -0500, george@agora.rdrop.com (George
>>>Rachor) wrote:
>
>>>>
>>>>OK... Cleared the guide twice but still getting the error right after 'combining data'.
>>>>
>>>>I had to change back to dialup to get the guide re-populated...
>>>>
>>>>I'm tempted to buy another replay and see if it has the same problem. That would let me determine
>>>>if the problem is in the unit (bad software) or upstream in my network.
>>>>I was thinking about another replay anyway.
>>>>
>>>>George
>>>>
>
>>>It's spending more money, but probably a good idea. Problems are
>>>easier to locate when you have multiple units.
>
>>>>Mark Lloyd <mlloyd@5xxxmail.com5xxx> writes:
>>>>
>>>>>On Sun, 10 Apr 2005 21:03:34 -0500, george@agora.rdrop.com (George
>>>>>Rachor) wrote:
>>>>
>>>>>>Mark,
>>>>>>
>>>>>>
>>>>>>I bypassed the linksys and got the same result (Most of the way through the transaction
>>>>>>to replay then a failure message.
>>>>>>
>>>>>>I put a sniffer on the network line between the replay and my homenetwork.
>>>>>>
>>>>>>1. The replay is getting the time via ntp from production.replaytv.net
>>>>>>2. On the first HTTP Get to production.replaytv.net I see the following curious
>>>>>> line:
>>>>>> Dissector bug, protocol HTTP: "Request URI" - "http.request.uri" invalid length: -5 (proto.c:2104)
>>>>>>
>>>>>>
>>>>>>The following HTTP Gets have the same curious line...
>>>>>>
>>>>>>Any new thoughts?
>>>>>>
>>>>
>>>>>The problem may involve merging new information with an existing
>>>>>(corrupted) guide. Try clearing the Replay guide using 2-4-3-Zones
>>>>>option 2 (people say you need to do this 2 times), then requesting a
>>>>>new guide (manual connect).
>>>>
>>>>>>George Rachor
>>>>>>
>>>>>>
>>>>>>Mark Lloyd <mlloyd@5xxxmail.com5xxx> writes:
>>>>>>
>>>>>>>On Sat, 02 Apr 2005 10:01:03 -0600, george@agora.rdrop.com (George
>>>>>>>Rachor) wrote:
>>>>>>
>>>>>>>>I've got a replaytv model 5508 that up until 2 weeks ago was updateing
>>>>>>>>the program guide just fine
>>>>>>>>via my internet connection.
>>>>>>>>
>>>>>>>>My connection consists of the replaytv on a home network
>>>>>>>>behind a linksys router. That router is then connected to the ISP's equipment.
>>>>>>>>
>>>>>>>>I had to change the settings last night to start updating
>>>>>>>>via phone line because something has changed and now updating
>>>>>>>>the program guide via the network connection is failing. In watching
>>>>>>>>the progress it looks like we get most of the way through
>>>>>>>>before getting a message that the update has failed and it will
>>>>>>>>try again later. The last message I see is "combining data ..."
>>>>>>>>
>>>>>>>>I'm trying to figure out if something has changed upstream with my
>>>>>>>>ISP or if something has happened to my Linksys.
>>>>>>>>
>>>>>>>>Any thoughts would be appreciated.
>>>>>>
>>>>>>>The way the Replay handles errors can be misleading. There can be a
>>>>>>>failure near the beginning, then the process seems to get all the way
>>>>>>>through before you're told about it.
>>>>>>
>>>>>>>Is your Replay set to get a dynamic local IP from the router? If so,
>>>>>>>you may need to refresh it (because of ISP making changes). Otherwise,
>>>>>>>check carefully. The ISP could have changed DNS servers.
>>>>>>
>>>>>>>--
>>>>>>>Mark Lloyd
>>>>>>>has a Replay 5xxx
>>>>>>>http/notstupid.laughingsquid.com
>>>>>>
>>>>>>>"The idea that there is an invisible being who
>>>>>>>created and still runs this old universe is so
>>>>>>>childish, so obviously contrived, that it is hard to
>>>>>>>believe anyone with even a modicum of education can
>>>>>>>still fall for that scam."
>>>>
>>>>>--
>>>>>Mark Lloyd
>>>>>has a Replay 5xxx
>>>>>http/notstupid.laughingsquid.com
>>>>
>>>>>"The idea that there is an invisible being who
>>>>>created and still runs this old universe is so
>>>>>childish, so obviously contrived, that it is hard to
>>>>>believe anyone with even a modicum of education can
>>>>>still fall for that scam."
>
>>>--
>>>Mark Lloyd
>>>has a Replay 5xxx
>>>http/notstupid.laughingsquid.com
>
>>>"The idea that there is an invisible being who
>>>created and still runs this old universe is so
>>>childish, so obviously contrived, that it is hard to
>>>believe anyone with even a modicum of education can
>>>still fall for that scam."
>>--
>>=========================================================
>>George L. Rachor Jr. george@rachors.com
>>Hillsboro, Oregon http:rachors.com
>>United States of America Amateur Radio : KD7DCX

--
Mark Lloyd
has a Replay 5xxx
http/notstupid.laughingsquid.com

"The idea that there is an invisible being who
created and still runs this old universe is so
childish, so obviously contrived, that it is hard to
believe anyone with even a modicum of education can
still fall for that scam."

 

[sydnoremery]

I don't imagine anyone posting six years ago will be reading this, but maybe someone will google the issue like I did and run across my post.

I had the exact same issue for months. After reading this thread, I took a look at my ReplayTV 5K's DNS settings. I had installed WIRNS some time back; and as per the WIRNS instructions, I set my ReplayTV's DNS IP to the WIRNS box's IP. So after reading this thread, I changed the ReplayTV's DNS IP back to my router's IP - and now my internet channel guide updates work perfectly again.

Hope this helps someone!