Problems with Replay 5040 - Reboots often - Page 7 - AVS Forum
Forum Jump: 
Reply
 
Thread Tools
post #181 of 331 Old 01-02-2008, 10:10 AM
AVS Special Member
 
hdonzis's Avatar
 
Join Date: Mar 2003
Location: San Antonio, TX
Posts: 2,015
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 0 Post(s)
Liked: 11
Quote:
Originally Posted by KenL View Post

Quote:
Originally Posted by BaysideBas View Post

And I forgot to mention that that unit is a 5500, which apparently is immune to this reboot virus.

So it seems to be basic IVS *capability* being targeted here? As opposed to open ports or actual sharing.

Don't both the 5500 and 5000 run the same latest version of the firmware? I thought the only thing that kept the 5500 from running IVS was the inability to get to the port configuration screen. I think that even a 5000 after a factory reset also doesn't have access to the IVS configuration screen until after it connects to DNNA. So, it would be interesting to check, but I would think that even an IVS disabled Replay would still be sending RDDNS updates (as I posted awhile back)...

Henry
hdonzis is offline  
Sponsored Links
Advertisement
 
post #182 of 331 Old 01-02-2008, 10:18 AM
Senior Member
 
Murphy's Avatar
 
Join Date: Sep 2001
Location: Horsham, PA, USA
Posts: 474
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 0 Post(s)
Liked: 10
Quote:
Originally Posted by hdonzis View Post

Don't both the 5500 and 5000 run the same latest version of the firmware? I thought the only thing that kept the 5500 from running IVS was the inability to get to the port configuration screen. I think that even a 5000 after a factory reset also doesn't have access to the IVS configuration screen until after it connects to DNNA. So, it would be interesting to check, but I would think that even an IVS disabled Replay would still be sending RDDNS updates (as I posted awhile back)...

Henry

Correct. I disabled IVS (set port to 00000) on all three of my 5040s and removed the port forwarding from the router. They kept right on rebooting and sending rddns requests. I now have rddns-rns.replaytv.net (64.124.73.123) blocked in my router for all three units. The router log verifies that the requests are being blocked. It's only been an hour since I did that so it will be awhile before I have any results. In the 24 hours before the change I had eight reboots spread across the three units.
Murphy is offline  
post #183 of 331 Old 01-02-2008, 10:18 AM
AVS Special Member
 
icecow's Avatar
 
Join Date: Apr 2003
Location: Redlands, California
Posts: 7,899
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 1 Post(s)
Liked: 10
It is true that ReplayTVs owned by those who religiously record a lot of Star Trek may have taken on some cloaking abilities via holistic osmosis, but my version of the cowspiracy theory is DTV is sneakcretly tweaking the parts of the rtv software that collect info on watching habits, or they merely began utilizing the existing collection software and the bugs showing up (top sneakcret spyware).

I figure DTV is likely to start messing with the 'user information' thing, but for all I know that stuff is still under the fingers of the DNNA house.

Who knows. I don't :whistle:

bla bla bla
icecow is offline  
post #184 of 331 Old 01-02-2008, 10:26 AM
AVS Special Member
 
KenL's Avatar
 
Join Date: Nov 2001
Posts: 5,131
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 0 Post(s)
Liked: 10
Quote:
Originally Posted by hdonzis View Post

Uh, actually, the oldest post is when I posted the problem in the WiRNS forum on PlanetReplay...

Besides, of all forums, why would it get posted in the WiRNS forum if someone's Replay was rebooting?

Sorry, guess I didn't distinguish that from the regular WiRNS troubleshooting, or your dependable remote-replayguide-refresh-while-recording reboots/lockups. But if I started seeing them, and knew it wasn't my hardware/network/behavior, the first thing I'd check is WiRNS.

Which brings us back to your earlier query: Is anyone connecting thru WiRNS getting the daily/hourly reboots - double reboots described in this thread?
KenL is offline  
post #185 of 331 Old 01-02-2008, 10:33 AM
AVS Special Member
 
hdonzis's Avatar
 
Join Date: Mar 2003
Location: San Antonio, TX
Posts: 2,015
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 0 Post(s)
Liked: 11
Quote:
Originally Posted by icecow View Post

It is true that ReplayTVs owned by those who religiously record a lot of Star Trek may have taken on some cloaking abilities via holistic osmosis, but my version of the cowspiracy theory is DTV is sneakcretly tweaking the parts of the rtv software that collect info on watching habits, or they merely began utilizing the existing collection software and the bugs showing up (top sneakcret spyware).

I figure DTV is likely to start messing with the 'user information' thing, but for all I know that stuff is still under the fingers of the DNNA house.

Who knows. I don't :whistle:

bla bla bla

Well, I DO have a pretty big collection of "Enterprise" on one of my Replays. You think if I delete all the shows and the recording schedule that the problem will go away? Or, is it too late because I've already been marked as "Trekker" by DNNA?

Henry
hdonzis is offline  
post #186 of 331 Old 01-02-2008, 10:40 AM
AVS Special Member
 
hdonzis's Avatar
 
Join Date: Mar 2003
Location: San Antonio, TX
Posts: 2,015
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 0 Post(s)
Liked: 11
Quote:
Originally Posted by KenL View Post

Sorry, guess I didn't distinguish that from the regular WiRNS troubleshooting, or your dependable remote-replayguide-refresh-while-recording reboots/lockups. But if I started seeing them, and knew it wasn't my hardware/network/behavior, the first thing I'd check is WiRNS.

Yeah, which is why I originally reported it in the WiRNS forum because a couple of reboots seemed to correspond with WiRNS guide refreshing. But, it was just a couple of the reboots versus several others that happened when WiRNS wasn't doing anything. I was kind of hoping that maybe the others were some kind of after effect from WiRNS guide refreshing because I had no other explanation. But, after this thread, I think the couple that happened while WiRNS was guide refreshing were just a normal statistical event that if the Replay is randomly rebooting, it will eventually happen while WiRNS is guide refreshing. I can't say that I've really had any more happen during a guide refresh even though I've continued to get multi-segment recording on all four of my Replays (even after clearing the channel guide data on all four units). I'm hoping that my changing RDDNS to go through WiRNS (I don't proxy my units since they are all 5000's and I live in the US) will make the difference. Unfortunately, WiRNS doesn't log the RDDNS events since they happen so regularly, so I can't tell for sure (except to WireShark WiRNS) that the change I made in my router is making a difference or not. But, hopefully, time will tell...

Henry
hdonzis is offline  
post #187 of 331 Old 01-02-2008, 10:53 AM
Newbie
 
FreyGuy's Avatar
 
Join Date: Jan 2008
Location: Manchester, NH
Posts: 1
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 0 Post(s)
Liked: 10
Hiya;

I have a 4500 series with an upgraded HD - Have had this unit w/Lifetime subscription since 2001 I believe.

My random, frequent crashes/reboots started early Dec. 2007 (I think around Dec 4, but not certain). It reboots anywhere from every 20 minutes to every few hours. It can happen watching live tv, or live tv in bypass mode, or watching a recorded show. Yesterday, it rebooted at least 4 times during the afternoon while we were watching that series of Summer Olympic specials that Showtime or HBO was showing... Painful.

I have Comcast cable, so all this talk of DirectTV messing with stuff is incorrect.

I have only one replay on my network, connected via Ethernet.

One thing I have tried is deleting a "received" show that was pending downloading (I had accepted it, but it wouldn't complete) that I received from my dad's unit (over the Internet) - The show was in a "downloading" state for a like a month; I forgot about it, but in light of these problems, I have deleted the show last night and I haven't had a reboot since (my ethernet cable is still plugged in). It hasn't been 24 hours yet, though, but the very frequent reboots stopped after I removed this pending download.

On another, perhaps related, note: My Dad's 4500 unit (also Lifetime sub) shows as "Deactivated" now. When he goes to the web address shown on the screen, it still shows "Lifetime sub" activated. Hmmm... this just happened to him yesterday.

And, mpgruett, I think the technical content is great (I'm a network geek myself), and this confirms what we had been inferring before - that this is a crash (kernel panic) that is caused by some kind of network data received. Now, perhaps we need to grab the data portion of these captures and start analyzing the data received that might be crashing the units (but then again, we aren't the engineer responsible for replay OS diagnosis, so we won't know what is out of the ordinary).

Thanks to all and we'll keep this thread going until we get through it. I'll have my dad open a support issue about this when he calls in the subscription problem he is experiencing.

Warm regards;

KevFrey
FreyGuy is offline  
post #188 of 331 Old 01-02-2008, 11:01 AM
Member
 
MyReplay's Avatar
 
Join Date: Jun 2003
Location: Los Angeles, CA
Posts: 82
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 0 Post(s)
Liked: 10
My solid 5000 has been rebooting for over a week now. I went out of town, came back and saw a lot of shows split in half due to reboots. Also had it happen a bunch of times since I've been back.

I was thinking this was a dying hard drive or maybe overheating from dust -- then I came across this. Looks like the issue is more wide spread than I thought.

Oddly enough, my 5500 unit that had not received updates in a week was fine. Must have something to do with the network.
MyReplay is offline  
post #189 of 331 Old 01-02-2008, 11:12 AM
Member
 
jimmcq's Avatar
 
Join Date: May 2002
Posts: 177
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 0 Post(s)
Liked: 10
I've got a pair of 50x0 units, and for the past month I've also been seeing a lot of recorded shows split in half because of a reboot.
jimmcq is offline  
post #190 of 331 Old 01-02-2008, 11:17 AM
AVS Special Member
 
KenL's Avatar
 
Join Date: Nov 2001
Posts: 5,131
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 0 Post(s)
Liked: 10
Quote:
Originally Posted by hdonzis View Post

...Unfortunately, WiRNS doesn't log the RDDNS events since they happen so regularly...

Are you sure?

What is this business:
Code:
[1/2/2008 05:32:56] [DNS] Using file: C:\\WiRNS\\Plugins\\IVSProvider.hosts
[1/2/2008 05:32:56] [DNS] Returning 192.168.x.1xx for rddns-production.replaytv.net to 192.168.x.x0x
[1/2/2008 05:32:56] [PLUGIN] IVSProvider received an update request from  ISN 00004-54xxx-xxxxx
[1/2/2008 05:32:56] [IVSPROVIDER] Getting backup.rddns.cc for rddns-production.replaytv.net
Does that once every hour, to a different minute/second for each replay pointed at that instance of WiRNS. Miles and miles of that all day long, every hour of every day for every replay.
KenL is offline  
post #191 of 331 Old 01-02-2008, 12:36 PM
Newbie
 
mpgruett's Avatar
 
Join Date: Oct 2002
Posts: 7
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 0 Post(s)
Liked: 10
OK, after analyzing my packet capture, I tried pulling down this file that it's getting:

wget http://64.124.73.123/rd/servlet/ul?q=930af40ac6..... [remaining deleted - see packet capture if you really want to see the entire setting for the "q" variable]

Also ran the 2nd attempt to the rrdns server (wget http://64.124.73.123/rd/servlet/ul?q=2086374bf.......)

(BTW, MIME type according to the server is application/vnd.replay.rd)

It's quite obvious that the rrdns server does not respond correctly most of the time if you try this. It sends 163 bytes of data and then just hangs and never finishes sending the data. If I repeat this command enough times I finally do get a successful download of the entire file which is 163 bytes. (You can even just do wget http://64.124.73.123/rd/servel/ul?q=foo over and over and see how many times it fails before you finally get a successful download - i.e. it doesn't hang).

A majority of the time (based on my testing of 1 in 17 tries succeeding being the worst, 1 in 2 being the best) the rrdns server at 64.124.73.123 is failing to close the connection after all 163 bytes have been downloaded.

My digging into this would suggest that if the rrdns server doesn't respond correctly (which it seems to most of the time) it reboots. It would then seem that upon reboot that the replay did get a successful close to the http get and doesn't reboot anymore. If a Replay tried and got a bad response, rebooted and tried again and got a bad response and then rebooted a 2nd time and got a valid response that would seem to account for the double rebooting. However, given the odds I saw from testing (see above) you'd think that the odds of a replay doing this HTTP GET to the RRDNS server, failing, rebooting and completing the exact same transaction successfully would be slim. Perhaps another factor is whether the Replay has been up for a couple of days?

So, now we need to get tech support to dive into the configuration of the rrdns server and find out why it's so inconsistent. (Interestingly, this server appears to be called server-0107).
mpgruett is offline  
post #192 of 331 Old 01-02-2008, 01:01 PM
Member
 
tlgs333's Avatar
 
Join Date: Aug 2002
Location: Long Island
Posts: 149
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 0 Post(s)
Liked: 10
The problem is not confined to exposed 5000 units. I have no ports open on my router that point to the replays and i have this problem.

From the data that have been collected, it sure seems that this has something to do with the rddns updates.

Good work, those of you who have called tech support and pointed them to this forum! You are heroes.
Also, mpgruett, for your capture of data i wasn't able to get!

Everyone else - Call replay and point out this problem today!
tlgs333 is offline  
post #193 of 331 Old 01-02-2008, 01:01 PM
AVS Special Member
 
rm -rf *.*'s Avatar
 
Join Date: Nov 2003
Location: Uberglitch, Switzerland
Posts: 3,152
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 0 Post(s)
Liked: 10
Quote:
Originally Posted by mpgruett View Post

(Interestingly, this server appears to be called server-0107).

At least it's not called "server-03Q1"



You mentioned having a full packet capture? I'd like to take a look at the output. Do you have the files available for download?

Still no news from New Zealand.
If we ever get any, we'll be sure to let you know.
rm -rf *.* is offline  
post #194 of 331 Old 01-02-2008, 01:26 PM
Member
 
jweinel's Avatar
 
Join Date: May 2001
Location: Greensboro, NC, USA
Posts: 116
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 3 Post(s)
Liked: 10
Quote:
Originally Posted by FreyGuy View Post

I have Comcast cable, so all this talk of DirectTV messing with stuff is incorrect.

FreyGuy, I think that the references to suspected DirecTv involvement relate to the previously-discussed (in other threads) purchase of ReplayTV assets by DirectTV. I wouldn't put it past DTV to try something but only after the deal is done!
Jim

----------
Jim
jweinel is offline  
post #195 of 331 Old 01-02-2008, 01:37 PM
Senior Member
 
Murphy's Avatar
 
Join Date: Sep 2001
Location: Horsham, PA, USA
Posts: 474
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 0 Post(s)
Liked: 10
DNNA is keeping the guide update service so DirecTV is/will not be involved.
Murphy is offline  
post #196 of 331 Old 01-02-2008, 01:40 PM
AVS Special Member
 
icecow's Avatar
 
Join Date: Apr 2003
Location: Redlands, California
Posts: 7,899
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 1 Post(s)
Liked: 10
Oh sure, that's what the media channels report to the masses.
icecow is offline  
post #197 of 331 Old 01-02-2008, 01:42 PM
Newbie
 
mpgruett's Avatar
 
Join Date: Oct 2002
Posts: 7
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 0 Post(s)
Liked: 10
Quote:
Originally Posted by rm -rf *.* View Post

At least it's not called "server-03Q1"



You mentioned having a full packet capture? I'd like to take a look at the output. Do you have the files available for download?

The full packet capture is attached to my post in this thread - #160

mpgruett is offline  
post #198 of 331 Old 01-02-2008, 01:46 PM
AVS Special Member
 
rm -rf *.*'s Avatar
 
Join Date: Nov 2003
Location: Uberglitch, Switzerland
Posts: 3,152
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 0 Post(s)
Liked: 10
Quote:
Originally Posted by mpgruett View Post

The full packet capture is attached to my post in this thread - #160


I just realized that a few minutes ago... (*duh*)

I'm getting a error everytime I try to download it. If you don't mind, I'll shoot you a PM with my email address in a moment, if you could just email it to me I'd appreciate it.

Still no news from New Zealand.
If we ever get any, we'll be sure to let you know.
rm -rf *.* is offline  
post #199 of 331 Old 01-02-2008, 01:51 PM
Newbie
 
theotherguy's Avatar
 
Join Date: Feb 2003
Posts: 9
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 0 Post(s)
Liked: 10
Add me to the list. My 5040 (with a 160GB HD in it) has been rebooting frequently the last couple of weeks. Yesterday it rebooted about 4-5 times while I was watching football on it live all day. I assumed my HD was on it's last legs until I found this thread. It's on a network with two xp machines. DVArchive and Poopli running 24/7. Guide info: Comcast / Michigan / 49508.
theotherguy is offline  
post #200 of 331 Old 01-02-2008, 01:56 PM
AVS Special Member
 
Join Date: Sep 2004
Location: In the ATL
Posts: 4,371
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 2 Post(s)
Liked: 253
Quote:
Originally Posted by KenL View Post

Could be a possibility?

I have 3 50xx still pointing at WiRNS and no extra reboots whatsoever. Everything running normally for months or longer. Been watching them closely for the last 10 days or so: no segmented recordings, only expected/announced 7 day reboots. Notice there is not even a mention of this in the WiRNS forum.

I started to suspect something along these lines when some were describing persistent reboots at the same time after the hour. Of course WiRNS intercepts those hourly transactions with the replays are pointed there.

So the next question would be how, why, and who? Was this supposed to be some kind of covert mass retirement *nudge* from the mothership?

Same here, both of my 55xx's are routed through WiRNS to enable IVS/CA and no reboots.
slowbiscuit is offline  
post #201 of 331 Old 01-02-2008, 01:57 PM
Newbie
 
drewfidelic's Avatar
 
Join Date: Jun 2003
Posts: 9
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 0 Post(s)
Liked: 10
To add another data point, I've been having the random reboots with my stock lifetime, ethernet-connected 5040 for a couple of weeks now. I thought that this was the result of the hard drive going bad, but I'm guessing that it is the same issue that everyone else here is having.
drewfidelic is offline  
post #202 of 331 Old 01-02-2008, 02:03 PM
AVS Special Member
 
hdonzis's Avatar
 
Join Date: Mar 2003
Location: San Antonio, TX
Posts: 2,015
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 0 Post(s)
Liked: 11
Quote:
Originally Posted by KenL View Post

Are you sure?

What is this business:
Code:
[1/2/2008 05:32:56] [DNS] Using file: C:\\WiRNS\\Plugins\\IVSProvider.hosts
[1/2/2008 05:32:56] [DNS] Returning 192.168.x.1xx for rddns-production.replaytv.net to 192.168.x.x0x
[1/2/2008 05:32:56] [PLUGIN] IVSProvider received an update request from  ISN 00004-54xxx-xxxxx
[1/2/2008 05:32:56] [IVSPROVIDER] Getting backup.rddns.cc for rddns-production.replaytv.net
Does that once every hour, to a different minute/second for each replay pointed at that instance of WiRNS. Miles and miles of that all day long, every hour of every day for every replay.

That's because you are proxying through WiRNS, which I am not. Although the [PLUGIN] IVSProvider log entry looks like what I was expecting. I'll have to check the source code and see if I should be expecting any logging or not. Maybe I didn't change things the way I expected...

Thanks!

Henry
hdonzis is offline  
post #203 of 331 Old 01-02-2008, 02:33 PM
AVS Special Member
 
KenL's Avatar
 
Join Date: Nov 2001
Posts: 5,131
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 0 Post(s)
Liked: 10
Quote:
Originally Posted by tlgs333 View Post

The problem is not confined to exposed 5000 units. I have no ports open on my router that point to the replays and i have this problem.

It may well include any IVS capable units exposed to that server.

But I doubt it includes 55xx, simply because few could/would run a 55xx (for long) both with IVS enabled software, and wide open to that server.

You'd think the fix would ordinarily be pretty straightforward. But I wouldn't hold my breath in light of mitigating circumstances. Perhaps server assets were included in the salvage when DNNA dismantled the brand? And/or the scheduled shuttering of the activation server was/is already looming.

Perhaps within weeks?

Wasn't there a leaked internal memo posted several years ago claiming activation would cease "January 2008 or sooner"? But then many had high hopes (obviously before it was released) ReplayPC might keep the brand on life support. But last month DNNA dismantled the brand and sold the patents along with other assets to D*. Apparently without liability for the long discontinued products.

Cow always feared they would unceremoniously still be selling *lifetime* on the day it's scheduled to go dark for the last time.

And perhaps even the day after that.
KenL is offline  
post #204 of 331 Old 01-02-2008, 02:58 PM
AVS Special Member
 
hdonzis's Avatar
 
Join Date: Mar 2003
Location: San Antonio, TX
Posts: 2,015
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 0 Post(s)
Liked: 11
Quote:
Originally Posted by mpgruett View Post

OK, after analyzing my packet capture, I tried pulling down this file that it's getting:

wget http://64.124.73.123/rd/servlet/ul?q=930af40ac6..... [remaining deleted - see packet capture if you really want to see the entire setting for the "q" variable]

Also ran the 2nd attempt to the rrdns server (wget http://64.124.73.123/rd/servlet/ul?q=2086374bf.......)

(BTW, MIME type according to the server is application/vnd.replay.rd)

It's quite obvious that the rrdns server does not respond correctly most of the time if you try this. It sends 163 bytes of data and then just hangs and never finishes sending the data. If I repeat this command enough times I finally do get a successful download of the entire file which is 163 bytes. (You can even just do wget http://64.124.73.123/rd/servel/ul?q=foo over and over and see how many times it fails before you finally get a successful download - i.e. it doesn't hang).

A majority of the time (based on my testing of 1 in 17 tries succeeding being the worst, 1 in 2 being the best) the rrdns server at 64.124.73.123 is failing to close the connection after all 163 bytes have been downloaded.

My digging into this would suggest that if the rrdns server doesn't respond correctly (which it seems to most of the time) it reboots. It would then seem that upon reboot that the replay did get a successful close to the http get and doesn't reboot anymore. If a Replay tried and got a bad response, rebooted and tried again and got a bad response and then rebooted a 2nd time and got a valid response that would seem to account for the double rebooting. However, given the odds I saw from testing (see above) you'd think that the odds of a replay doing this HTTP GET to the RRDNS server, failing, rebooting and completing the exact same transaction successfully would be slim. Perhaps another factor is whether the Replay has been up for a couple of days?

So, now we need to get tech support to dive into the configuration of the rrdns server and find out why it's so inconsistent. (Interestingly, this server appears to be called server-0107).

The message is encrypted using the current time, so using a captured packet at a later time wouldn't be valid. I think both your using old data and nonsense data, like foo, is creating invalid requests, which is why the server doesn't respond...

Henry
hdonzis is offline  
post #205 of 331 Old 01-02-2008, 02:59 PM
AVS Special Member
 
KenL's Avatar
 
Join Date: Nov 2001
Posts: 5,131
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 0 Post(s)
Liked: 10
Quote:
Originally Posted by hdonzis View Post

...I'll have to check the source code and see if I should be expecting any logging or not. Maybe I didn't change things the way I expected...

Thanks!

Henry

Actually that's WiRNS 1.3 in my case.

I assume 2.0 still does it, I have one replay hitting a version of WiRNS 2.0 and it also seems to be immune to the reboots. I'd guess the logging shouldn't matter as long as WiRNS intercepts the transaction?
KenL is offline  
post #206 of 331 Old 01-02-2008, 03:03 PM
AVS Special Member
 
hdonzis's Avatar
 
Join Date: Mar 2003
Location: San Antonio, TX
Posts: 2,015
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 0 Post(s)
Liked: 11
Quote:
Originally Posted by KenL View Post

Actually that's WiRNS 1.3 in my case.

I assume 2.0 still does it, I have one replay hitting a version of WiRNS 2.0 and it also seems to be immune to the reboots. I'd guess the logging shouldn't matter as long as WiRNS intercepts the transaction?

Well, I just looked at the code and I should be getting at least the last two lines that are in your log. So, maybe I haven't quite got things setup as I want. I don't want to proxy my Replays through WiRNS, but I would like to proxy my RDDNS updates through WiRNS. I'll have to check to see what I did wrong.

By the way, in looking at the code in WiRNS, it ALWAYS returns an OK response to the RDDNS update message. So, that could be a reason that running THROUGH WiRNS makes the difference...

Henry
hdonzis is offline  
post #207 of 331 Old 01-02-2008, 03:06 PM
AVS Special Member
 
hdonzis's Avatar
 
Join Date: Mar 2003
Location: San Antonio, TX
Posts: 2,015
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 0 Post(s)
Liked: 11
Quote:
Originally Posted by KenL View Post

Actually that's WiRNS 1.3 in my case.

Yeah, I put in that feature you requested to "lock" the provider channel lineup and here you are still on 1.3 without even as much as a "thank you"! See if I pay attention to your feature requests in the future!

Henry
hdonzis is offline  
post #208 of 331 Old 01-02-2008, 03:10 PM
AVS Special Member
 
hdonzis's Avatar
 
Join Date: Mar 2003
Location: San Antonio, TX
Posts: 2,015
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 0 Post(s)
Liked: 11
Quote:
Originally Posted by KenL View Post

Are you sure?

What is this business:
Code:
[1/2/2008 05:32:56] [DNS] Using file: C:\\WiRNS\\Plugins\\IVSProvider.hosts
[1/2/2008 05:32:56] [DNS] Returning 192.168.x.1xx for rddns-production.replaytv.net to 192.168.x.x0x
[1/2/2008 05:32:56] [PLUGIN] IVSProvider received an update request from  ISN 00004-54xxx-xxxxx
[1/2/2008 05:32:56] [IVSPROVIDER] Getting backup.rddns.cc for rddns-production.replaytv.net
Does that once every hour, to a different minute/second for each replay pointed at that instance of WiRNS. Miles and miles of that all day long, every hour of every day for every replay.

OK, I copied and pasted from someone else's post to resolve "rddns-rns.replaytv.net" to WiRNS instead of "rddns-production.replaytv.net". I now have both in there, so we'll see if that doesn't make the difference...

Henry
hdonzis is offline  
post #209 of 331 Old 01-02-2008, 03:51 PM
AVS Special Member
 
hdonzis's Avatar
 
Join Date: Mar 2003
Location: San Antonio, TX
Posts: 2,015
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 0 Post(s)
Liked: 11
Quote:
Originally Posted by KenL View Post

Are you sure?

What is this business:
Code:
[1/2/2008 05:32:56] [DNS] Using file: C:\\WiRNS\\Plugins\\IVSProvider.hosts
[1/2/2008 05:32:56] [DNS] Returning 192.168.x.1xx for rddns-production.replaytv.net to 192.168.x.x0x
[1/2/2008 05:32:56] [PLUGIN] IVSProvider received an update request from  ISN 00004-54xxx-xxxxx
[1/2/2008 05:32:56] [IVSPROVIDER] Getting backup.rddns.cc for rddns-production.replaytv.net
Does that once every hour, to a different minute/second for each replay pointed at that instance of WiRNS. Miles and miles of that all day long, every hour of every day for every replay.

Yeah, now it's working for me, too!

Code:
[1/2/08 17:29:07] [PLUGIN] IVSProvider received an update request from ISN 00004-549xx-xxxxx
[1/2/08 17:29:07] [IVSPROVIDER] Getting backup.rddns.cc for rddns-production.replaytv.net
[1/2/08 17:45:28] [PLUGIN] IVSProvider received an update request from ISN 00004-548xx-xxxxx
[1/2/08 17:45:28] [IVSPROVIDER] Getting backup.rddns.cc for rddns-production.replaytv.net
Seems that having the correct host name can make all the difference! And, of course, I don't have the same first two lines as you since I'm not proxying through WiRNS...

I can't wait to see if this stops the problem or not! It will be cool to be able to fix the problem and still have IVS working!

Henry
hdonzis is offline  
post #210 of 331 Old 01-02-2008, 03:56 PM
Member
 
tlgs333's Avatar
 
Join Date: Aug 2002
Location: Long Island
Posts: 149
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 0 Post(s)
Liked: 10
Howdy, folks

I just got this email from the gent i was speaking with at replay.

Eric,
There was a problem with the RDDNS server on the backend. This appears
to be fixed now. Based on the information provided on the AVS forum,
this is likely the cause of the problem and should now be resolved.

Kudos to all of you who helped make it happen!
Everyone plug in your network cables and lets see if it is better!

Regards
Eric
tlgs333 is offline  
Reply ReplayTV & Showstopper PVRs

User Tag List

Thread Tools
Show Printable Version Show Printable Version
Email this Page Email this Page


Forum Jump: 

Posting Rules  
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are Off
Pingbacks are Off
Refbacks are Off