Problems with Replay 5040 - Reboots often - Page 4 - AVS Forum
Forum Jump: 
Reply
 
Thread Tools
post #91 of 331 Old 12-29-2007, 04:22 PM
Senior Member
 
Paco II's Avatar
 
Join Date: Aug 2002
Location: San Francisco, CA
Posts: 431
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 0 Post(s)
Liked: 10
Add my 5120 to the list as well. Getting really annoying. Pretty bizarre.
Paco II is offline  
Sponsored Links
Advertisement
 
post #92 of 331 Old 12-29-2007, 04:24 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 adone36 View Post

It cannot be WIRNS or MyReplaytv.com, etc, etc. because the problem occurs during playback on the machine you are watching w/o streaming or web access involved. So the question becomes "what are the Replays doing ALL the time, regardless of web connections, etc.". That would seem to be polling other units for guide updates.

Maybe tribune made a change in guide formatting or made a mistake in the code (ie: a missing "new line" command or something). The only way to find out would be to monitor the traffic on the Replay and see what was happening during each reboot.

I'm with you Tony, I've been saying from the very beginning that this probably has nothing to do with myreplaytv, and since I'm not running WiRNS, but my RTVs are rebooting prior to the 7 day reboot cycle, that rules out WiRNS.

3 or 4 days ago I closed the IVS ports on my RTVs and my router.

Apparently, one of my RTV's rebooted about 5 hours ago, so that means it was up for about 3days 17 hours IIRC.

Durring that period, I have not watched a single show in part or in whole, nor have I recorded anything. The unit has been sitting idle except forme flipping it on occationally to see if the 411-zones screen had vanished, which would indicate a reboot has occurred.

Guide update connects occur once every 25 hours on ethernet connected 5k's, so unelss I'm remembering the uptime incorrectly (to the order of 12 hours) my unit probably did not reboot due to a netconnect.

*sigh*

Still no news from New Zealand.
If we ever get any, we'll be sure to let you know.
rm -rf *.* is offline  
post #93 of 331 Old 12-29-2007, 04:29 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 adone36 View Post

Maybe tribune made a change in guide formatting or made a mistake in the code (ie: a missing "new line" command or something). The only way to find out would be to monitor the traffic on the Replay and see what was happening during each reboot.

Where does WiRNS draw it's guide data from?

I would think that if such was the case, then debug-level logging of WiRNS might reveal something.

That also does not address the issue of why those that have left the ethernet unplugged from their RTV's have gone the entire 7 day cycle without an unexplained reboot. Unless of course that the reboot is occuring during guide parsing, in which case, refer back to the previous paragraph.

Still no news from New Zealand.
If we ever get any, we'll be sure to let you know.
rm -rf *.* is offline  
post #94 of 331 Old 12-29-2007, 04:40 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 rm -rf *.* View Post

OK. I stand corrected.

I've never had the need to run WiRNS so, I had no idea that feature had been added since my initial tinkering with it for fun when it first came out.

Somehow though, I don't think myreplaytv.com has anything to do with the problem.

I don't think that there was any correction here. It has been so long, I'm not sure exactly what it does. IIRC, when I first started using WiRNS MyReplayTV.com didn't get updated. Then Ryan added a checkbox which allowed updating MyReplayTV.com. I never really questioned it or checked it out much. I have it checked because I liked using MyReplayTV.com to double check both what WiRNS and DVArchive showed was going to record (since MyReplayTV.com followed the same rules as the Replay itself). I'm not sure why WiRNS was blocking this connection in the first place such that it necessitated adding a checkbox...

I also don't see what updating MyReplayTV.com can have to do with anything, either, since it is performed during the net connect...

Henry
hdonzis is offline  
post #95 of 331 Old 12-29-2007, 04:40 PM
AVS Special Member
 
bron's Avatar
 
Join Date: Apr 2001
Posts: 1,087
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 0 Post(s)
Liked: 10
Just to add another data point, I have a 5500 upgraded to 320 GB and a 5000 upgraded to 250 GB. Myreplaytv enabled on the 55xx and not enabled on the 50xx. I have noticed the occasional 2 segment shows due to a reboot on the 5500 in the past (since I got it several years ago, not too frequent, but has happened off and on for last 2-3 years at least. Had not noticed it on the 5000 until recently, but only reconnected it a few months ago. Still have seen only a few times on the 5000, but both within the last week or two. I checked and the 5000 has been up about 22 hrs. and the 5500 3 days 17 hrs. Pretty sure the 5000 has gone for the prior 6 weeks plus without this occurring. It happened once last week while watching a show while another was recording.
bron is offline  
post #96 of 331 Old 12-29-2007, 04:48 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 adone36 View Post

It cannot be WIRNS or MyReplaytv.com, etc, etc. because the problem occurs during playback on the machine you are watching w/o streaming or web access involved. So the question becomes "what are the Replays doing ALL the time, regardless of web connections, etc.". That would seem to be polling other units for guide updates.

Maybe tribune made a change in guide formatting or made a mistake in the code (ie: a missing "new line" command or something). The only way to find out would be to monitor the traffic on the Replay and see what was happening during each reboot.

The IVS update happens about once an hour. The MyReplayTV.com update happens during the net connect. The guide update also only happens during the net conect.

You'd think that my having two of my four Replays duplicate recording the same shows and only having one of the two reboot for any given show kind of indicates that it is something more random than the guide data, like the IVS update for example. The guide data changes happened back a little before Zap2It shut down its free service. I'm sure we all remember when the DNNA guide data started saying "Repeat" on almost all of the shows. And, now it says "Repeat" quite a bit more often than it used to in years past.

I wish I could say how long ago I started noticing the problem. It started with just one of my four Replays at least the begining of November. I noticed it because of the split recording segments. But, that Replay has the biggest Replay Guide and I just chalked it up to having too many shows on it. Progressively it got worse until all four of my Replays have been doing it since about mid November. Although, the first one is still doing it quite a bit more than the other four. The one duplicating recordings and also has a rather large Replay Guide is having the problem about second most. My third most recorded shows is having the problem about third most. And, my un-upgraded 5060 with the fewest recorded shows is having the problem the least and also was the last one to exhibit the problem. But, that Replay never ever had split recordings before and now it has happened a couple of times...

Henry
hdonzis is offline  
post #97 of 331 Old 12-29-2007, 04:52 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 ForumAmbulator View Post

It sounds like we come to the same conclusions about the likely causes of the problem. We differ on the solution. I think the vendor should work on it, aided by their knowledge of things they have changed recently, and you think we should be monitoring traffic on our units. I'm sure you are right. The vendor is unlikely to fix the problem that they most likely have caused, and we should each undertake a technical analysis. Once we determine more details of the problem, what can we do then? I'm not sure I see where this goes, toward being able to make the problem stop, which is the desired outcome.

The vendor has almost no technical employees! They didn't change the guide data, Tribune changed the guide data. DNNA is completely in a sustaining role on keeping the Replays going as they are considered to be a mature product. I don't think that it's that they don't care, but rather than the don't have any of the people who know enough about how the Replay works. They have completely located everything to Waco, TX where they only have a support/repair group. They repair broken and warrenty units and answer phone calls. I don't think that suing them would make any difference in what they could do about the problem...

Henry
hdonzis is offline  
post #98 of 331 Old 12-29-2007, 04: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 rm -rf *.* View Post

Where does WiRNS draw it's guide data from?

I would think that if such was the case, then debug-level logging of WiRNS might reveal something.

That also does not address the issue of why those that have left the ethernet unplugged from their RTV's have gone the entire 7 day cycle without an unexplained reboot. Unless of course that the reboot is occuring during guide parsing, in which case, refer back to the previous paragraph.

You can configure WiRNS to draw its guide data from DNNA using a Replay or scrapping it from one of the guide services (some XML format). I have WiRNS configured to draw its gudie data from DNNA using my Replays. I've never seen WiRNS have any problem with the guide data.

Using an Ethernet sniffer should reveal the Replay sending IVS updates about once an hour. It certainly could be interesting if that coresponded with the time that a segment was split. From my WiRNS logs I can also tell that the Replay has rebooted when it wasn't recording and just happened to occur when WiRNS was refreshing its Replay Guide data (which is why I originally blamed the problem on WiRNS). It makes some sense that channel guide data could cause a problem when the Replay was recording and figuring out what to record next. But, if the Replay is also rebooting when it isn't recording, then it seems like it might be something more like the IVS update...

Henry
hdonzis is offline  
post #99 of 331 Old 12-29-2007, 06: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 hdonzis View Post

But, if the Replay is also rebooting when it isn't recording, then it seems like it might be something more like the IVS update...

IVS is shut off on my RTVs. (port 00000).

No joy, still having reboots.

If I can find a local phone number, I'll change one over to dialup.

Still no news from New Zealand.
If we ever get any, we'll be sure to let you know.
rm -rf *.* is offline  
post #100 of 331 Old 12-29-2007, 07:26 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 hdonzis View Post

I don't think that there was any correction here. It has been so long, I'm not sure exactly what it does. IIRC, when I first started using WiRNS MyReplayTV.com didn't get updated. Then Ryan added a checkbox which allowed updating MyReplayTV.com. I never really questioned it or checked it out much. I have it checked because I liked using MyReplayTV.com to double check both what WiRNS and DVArchive showed was going to record (since MyReplayTV.com followed the same rules as the Replay itself). I'm not sure why WiRNS was blocking this connection in the first place such that it necessitated adding a checkbox...

I also don't see what updating MyReplayTV.com can have to do with anything, either, since it is performed during the net connect...

Henry


OK, now that I go back and re-read your post a bit more slowly, I realize that it wasn't a correction to what I said here

Still no news from New Zealand.
If we ever get any, we'll be sure to let you know.
rm -rf *.* is offline  
post #101 of 331 Old 12-29-2007, 10:44 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 rm -rf *.* View Post

IVS is shut off on my RTVs. (port 00000).

No joy, still having reboots.

If I can find a local phone number, I'll change one over to dialup.

You'd need to check with WireShark, but I wouldn't be surprised if the Replay still sent the IVS update even with the port number set to 00000 and even on a 55xx model. RDDNS has no expiration, so the only way to disable the IVS lookup when you disable it on your Replay would be for the Replay to send the IVS update when you changed the port number. Now, while that could happen just one time when you set the port back to 00000, I wouldn't be surprised if the Replay sent the IVS update all the time, even on the 55xx series, and simply sends port 00000 in the update, which disables the lookup at the DNNA side. It makes the code a lot simpler that way...

However, I would certainly have to assume that switching to dialup would have to completely disable the IVS update. If you disconnected the Ethernet, I can't imagine that it is dialing any more than the one time per night for the net connect. So, that might help pin down that it was Ethernet traffic related...

Henry
hdonzis is offline  
post #102 of 331 Old 12-29-2007, 11:55 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 hdonzis View Post

You'd need to check with WireShark, but I wouldn't be surprised if the Replay still sent the IVS update even with the port number set to 00000 and even on a 55xx model. RDDNS has no expiration, so the only way to disable the IVS lookup when you disable it on your Replay would be for the Replay to send the IVS update when you changed the port number. Now, while that could happen just one time when you set the port back to 00000, I wouldn't be surprised if the Replay sent the IVS update all the time, even on the 55xx series, and simply sends port 00000 in the update, which disables the lookup at the DNNA side. It makes the code a lot simpler that way...

So, I've read that about 6 times now and all that comes to mind is "Say what Willis?"

AFAIK, IVS id is a push from the RTV to the server, so I fail to see how the server plays a part in this. If it did, then the RTV would be crashing everytime it tried to update the IVS info which in turn updates the RDDNS info.

The idea behind closing off the IVS ports was two fold:
1) setting the port to 00000 does stop the daemon that runs on the IVS port.
2) There is a way to cause a reboot on an RTV via the IVS port. This can be done to the target RTV reliably and repeatdily at will. By shutting of the daemon and closing the ports on my router, this possiblility is eliminated.

Still no news from New Zealand.
If we ever get any, we'll be sure to let you know.
rm -rf *.* is offline  
post #103 of 331 Old 12-30-2007, 07:00 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 rm -rf *.* View Post

So, I've read that about 6 times now and all that comes to mind is "Say what Willis?"

AFAIK, IVS id is a push from the RTV to the server, so I fail to see how the server plays a part in this. If it did, then the RTV would be crashing everytime it tried to update the IVS info which in turn updates the RDDNS info.

The idea behind closing off the IVS ports was two fold:
1) setting the port to 00000 does stop the daemon that runs on the IVS port.
2) There is a way to cause a reboot on an RTV via the IVS port. This can be done to the target RTV reliably and repeatdily at will. By shutting of the daemon and closing the ports on my router, this possiblility is eliminated.

IVS is twofold: The IVS server daemon and the IVS announce, which uses RDDNS. The Replay sends the announce to DNNA about once an hour. The reason being that your router address is subject to change at any time so the RDDNS info needs to be updated regularly. If you are familiar with how DDNS works, it is a push from the client to the server. And, the DDNS protocol has no expiration on the data from the client side of things (the DNS response has a short expiration to allow the data to be more dynamic, hence DDNS).

Anyway, in order for IVS to work, in addition to their being a server daemon on the Replay, there is also this regular IVS announce that the Replay sends to DNNA, or actually to the RDDNS server (the hostname has rddns in it). And, since RDDNS doesn't expire, the only way for IVS to get disabled in RDDNS would be for the Replay to send an announce that indicates that it has been disabled. I'm not sure if there is a "delete" command in the RDDNS protocol (especially since the 'R' stands for ReplayTV, so it is their own proprietary protocol), so it seems like the easiest way to implement it is to simply send the announce all the time and to have the RDDNS server interpret port 00000 as disabled. Otherwise, when you disabled IVS, RDDNS would still send the old IP and port information and there just wouldn't be a server daemon to accept the connection.

The easiest way to tell would be to enable IVS and try the IVS tester. Then disable IVS and try the tester again and see if it doesn't say that the ISN doesn't resolve. Or, to use WireShark to see if the Replay doesn't send regular RDDNS updates to DNNA (you'll see a resolve of the DNNA RDDNS server) even after you disable IVS...

Henry
hdonzis is offline  
post #104 of 331 Old 12-30-2007, 11:27 AM
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
So i've plugged both my units in and have wireshark watching both of them.
needless to say, neither have rebooted since wireshark has been watching them!

all i have to say at this point is W-T-F.

Has anyone here gotten a reboot event wiresharked? My replays have been working fine for 5 and 3 days! Not that i'm complaining, but i'd like to see some resolution!

What do we all have in common at this point? I've been watching the thread. I don't think we have any identical hardware on our networks, we don't have identical replays, We have varying replay assist software (wirns, dvarchive, nothing), we do and do not IVS, room to room streaming...

I just don't think it is a local problem. the only common denominator is copper ethernet cable. tho i bet a few of you are wireless!

I'd like to see some people switch over to modem (i don't have a landline phone) and i'd also like to see some people use WIRNS and a screen scraper (i.e. no DNNA guide data)

I'm a failure at WIRNS. Can a few of you here chime in and say "i'll do it" to phone based guide data and to WIRNS with alternate guide data?

thanks!
Eric
tlgs333 is offline  
post #105 of 331 Old 12-30-2007, 01:30 PM
Newbie
 
nvlady's Avatar
 
Join Date: Mar 2007
Posts: 13
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 0 Post(s)
Liked: 10
Hello everyone,

I have been having this problem with my 5040 as well, although I think it has been going on for at least a couple of months if not more. I have swapped out the hard drive to no avail. It is using DHCP on my wired network although I am trying to move it to a phone line for testing the theory that the problem is network related (working through 842e000a errors and "unable to contact server" when trying to connect). I did copy the configuration from my original hard drive (which I upgraded from a year or more ago), not the one that was just replaced, which makes me think it isn't a problem with the software on my drive. I have done most of the troubleshooting mentioned on the replaytvparts.com site, except testing voltage as it isn't something I am comfortable doing.

If it helps, I am running the following on my network
2 - Vista Ultimate OS
2 - XP Home
1 - Server 2000
2 - XP Professional laptops (rarely)

I am on Charter cable, no cable box.

I will keep working on getting the modem to connect, but even if I cannot get it to work, I will probably keep it off the network for a few days to see if the problem goes away. If I can provide any further information to help troubleshoot the problem, please let me know.

Thanks,
Beth
nvlady is offline  
post #106 of 331 Old 12-30-2007, 01:48 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 hdonzis View Post

IVS is twofold:
(...)
Henry

That wasn't actually what I meant by "Say what Willis?"

But thanks for the refresher course, I used to know all that $hit 2-3 years ago and have since forgotten all of it because I haven't fiddled around with the RTVs much in the last few years.

Still no news from New Zealand.
If we ever get any, we'll be sure to let you know.
rm -rf *.* is offline  
post #107 of 331 Old 12-30-2007, 02:15 PM
AVS Special Member
 
adone36's Avatar
 
Join Date: Mar 2002
Location: New Jersey
Posts: 2,552
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 0 Post(s)
Liked: 26
Quote:
Originally Posted by hdonzis View Post

I wish I could say how long ago I started noticing the problem. It started with just one of my four Replays at least the begining of November. I noticed it because of the split recording segments. But, that Replay has the biggest Replay Guide and I just chalked it up to having too many shows on it. Progressively it got worse until all four of my Replays have been doing it since about mid November. Although, the first one is still doing it quite a bit more than the other four. The one duplicating recordings and also has a rather large Replay Guide is having the problem about second most. My third most recorded shows is having the problem about third most. And, my un-upgraded 5060 with the fewest recorded shows is having the problem the least and also was the last one to exhibit the problem. But, that Replay never ever had split recordings before and now it has happened a couple of times...

Henry

I have 5 units. I have had maybe 2 shows be split, which is unusual because this was very rare before. What I DO GET is the units rebooting during playback of a local or streamed show. This has happened several times.

I cannot see how this can be related to netconnects, IVS, or myreplaytv. The myreplaytv enabled is just a flag setting, if no server actually asks for the show listing, nothing should be happening.

The size of the local guides could be a factor if there is a guide error that causes a thread to abort improperly in the Replay. If enough open threads accumulate the unit crashes. The question is, how could you ever find this? Replay would have to have Tribune supply Replays with the OLD guide format and see if it "fixes" it. If it does, then you'd have to see what was in the changes.

Has anybody gotten a response from DNNA on this issue?

Tony
adone36 is offline  
post #108 of 331 Old 12-30-2007, 02:20 PM
Member
 
mschmitt's Avatar
 
Join Date: Sep 2003
Posts: 34
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 1 Post(s)
Liked: 10
My 5080 is spontaneously rebooting also.

I only have one ReplayTV, no WiRNS or IVSmagic, I'm not doing DVArchive streaming or anything complicated. There are usually no other computers turned on in the network. I'm registered with myreplaytv.

For me it started rebooting a couple of months ago. Maybe October or November but it could have been earlier. I started to keep a log, but then it cleared up and went a couple of weeks with nothing but the 7 day maintenance restart.

And then it came back. It reboots every couple of days, even while I'm simply watching a recorded show.


I had three theories:

1. I'm on Time Warner Cable and it has a lot of channels. I thought maybe the amount of guide data was causing instability.

2. I suspected a hard drive problem.

3. It started after I uploaded pictures to the photo partition for the first time ever. (That has to be a coincidence. Right?)


The other symptom I have is that it seems to me like the guide updates are sucking up a lot more cpu % than they used to. The machine is completely unresponsive for 5-10 minutes while it updates, and if I show is recording it will cause 5 minutes of disrupted recording. It has got to the point where I try to manually shift the guide update to the wee hours of the morning -- I can't stand it when it updates while I'm trying to watch a show.

On the other hand, maybe it always was like that and I'm just noticing it more now.
mschmitt is offline  
post #109 of 331 Old 12-30-2007, 02:23 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 rm -rf *.* View Post

That wasn't actually what I meant by "Say what Willis?"

But thanks for the refresher course, I used to know all that $hit 2-3 years ago and have since forgotten all of it because I haven't fiddled around with the RTVs much in the last few years.

I guess you didn't get what I was getting at from the beginning. I was pointing out that the Replay is doing something frequently even when nothing else is going on because it is sending IVS update messages to RDDNS. I wasn't even thinking about the IVS daemon receiving traffic, I was only thinking about the RDDNS update daemon which fires off about once an hour. So, I was pointing out that while disabling IVS disables the server daemon, I doubt that it disables the RDDNS update daemon, which I what I think is happening at the random times and possibly causing problems. I hadn't considered that IVS itself could be causing a problem, although it is certainly possible. But, with my router I can see that I haven't had any IVS traffic, but that doesn't mean that someone isn't testing the IVS connection to my four units. I was thinking more that with having four units, two of which recording several of the same shows, and having each of them reboot at different times, that the RDDNS update daemon is the only thing I can think of that occurs frequently and randomly such that it would happen at different times of my four different units. If the problem was that DNNA was having a problem with its RDDNS server, maybe the RDDNS update message gets stuck or has some bug such that it is causing a reboot when it has problems updating the RDDNS server...

Anyway, that is what I was thinking and that's why I didn't think disabling IVS would solve the problem since I didn't think it would disable the RDDNS update message...

Henry
hdonzis is offline  
post #110 of 331 Old 12-30-2007, 02:37 PM
Senior Member
 
jesup's Avatar
 
Join Date: Aug 2001
Location: Tredyffrin, PA, USA
Posts: 222
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 0 Post(s)
Liked: 10
We're getting this too on our 5040 (lifetime, upgraded to 250GB).

Perhaps related, we don't have any guide data past around an hour and a half from now. Manual connect works, but no new guide data is added. Hmmm.

-- Randell
jesup is offline  
post #111 of 331 Old 12-30-2007, 03:20 PM
Member
 
jweinel's Avatar
 
Join Date: May 2001
Location: Greensboro, NC, USA
Posts: 114
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 0 Post(s)
Liked: 10
Add my two 5040's (unmodified) to the collection! I just spotted this thread after having been away for a few weeks, but my problems began at least one month ago, maybe two. I have been putting off troubleshooting and assumed that I had an inhouse problem (complex network configuration, although no recent changes). One 5040 reboots several times a week and sometimes several times a day. The other 5040 is not watched as much but I think it reboots about once per day. (FWIW, I also have a ShowStopper PV-HS2000 (dial-up) that has not rebooted for 30 days.) jesup, I checked guide data and it scheduled out to Thursday 1/3. I did a net connect and the guide extended to Friday 1/11.

What is the best email address to report the problem? If they are understaffed, perhaps it may be better if someone with some spare time could compile a list of the forum subscribers reporting reboots (or do they look at this forum?? Dumb question I guess - the Replay Lyndon days are long gone!)

Jim
jweinel is offline  
post #112 of 331 Old 12-30-2007, 03:27 PM
Newbie
 
nvlady's Avatar
 
Join Date: Mar 2007
Posts: 13
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 0 Post(s)
Liked: 10
Hi Jim,

Attached is a printable version of the thread should you find an email address to send it to. I hope it helps...

Beth

 

Problems with Replay 5040 - Reboots often.doc 368k . file
nvlady is offline  
post #113 of 331 Old 12-30-2007, 03:51 PM
Member
 
boekjar's Avatar
 
Join Date: Mar 2004
Location: Rockford, IL
Posts: 145
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 0 Post(s)
Liked: 10
My ReplayTV returned from a reboot at 1:46pm, 2:04pm, and 3:07pm today. (I was recording Bears vs. Saints.) But last night's Patriots/Giants game had no interruptions.

Oh, oh! And again at 5:50pm (recording another show).

Very annoying.
boekjar is offline  
post #114 of 331 Old 12-30-2007, 05:25 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
For those of you who did not read the entire thread:

I am speaking with someone from DNNA via email. We are attempting to figure out what is going on. It is a slow process, unfortunately.

One of his main points is that there are very few issues like this logged in the system. This does not help me convince him that the problem is not "my" stuff, and is, instead, guide data (my favorite working theory at the moment)

I recommend you all call replaytv and go through the motions of submitting the problem. Here is the number:
Phone: 254-299-2705

Of course they are going to jerk you around, ask you to do silly things like making sure it is plugged in. Just be sure to tell them your problem is not fixed, and you wish to escalate.

I figure this will either cause them undue stress and they'll cancel replay altogether, or it will get enough data into their tech support people (person?) to get them to realize that something has changed on their end.

Meanwhile, I'll ask the gent who i am speaking with at replay if he would like me to have everyone contact him directly. I don't feel comfortable with giving out the email address of a good samaritan without his consent.

Regards
Eric
tlgs333 is offline  
post #115 of 331 Old 12-30-2007, 06:56 PM
AVS Special Member
 
bron's Avatar
 
Join Date: Apr 2001
Posts: 1,087
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 0 Post(s)
Liked: 10
Eric, maybe you can download this thread (Under Thread Tools at top) and send him the text file? Might help him see that this is widespread and not local to any particular configuration or setup.
bron is offline  
post #116 of 331 Old 12-30-2007, 08:14 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 hdonzis View Post

I guess you didn't get what I was getting at from the beginning. I was pointing out that the Replay is doing something frequently even when nothing else is going on because it is sending IVS update messages to RDDNS. I wasn't even thinking about the IVS daemon receiving traffic, I was only thinking about the RDDNS update daemon which fires off about once an hour. So, I was pointing out that while disabling IVS disables the server daemon, I doubt that it disables the RDDNS update daemon, which I what I think is happening at the random times and possibly causing problems. I hadn't considered that IVS itself could be causing a problem, although it is certainly possible. But, with my router I can see that I haven't had any IVS traffic, but that doesn't mean that someone isn't testing the IVS connection to my four units. I was thinking more that with having four units, two of which recording several of the same shows, and having each of them reboot at different times, that the RDDNS update daemon is the only thing I can think of that occurs frequently and randomly such that it would happen at different times of my four different units. If the problem was that DNNA was having a problem with its RDDNS server, maybe the RDDNS update message gets stuck or has some bug such that it is causing a reboot when it has problems updating the RDDNS server...

Anyway, that is what I was thinking and that's why I didn't think disabling IVS would solve the problem since I didn't think it would disable the RDDNS update message...

Henry


Please stop assuming "I wasn't getting what you were saying from the beginning" since I wasn't testing for the same thing that you are describing.

What you are describing will probably be the next thing that I will look into.

Still no news from New Zealand.
If we ever get any, we'll be sure to let you know.
rm -rf *.* is offline  
post #117 of 331 Old 12-30-2007, 08:49 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 replay tech has said he has read this thread. I do not need to send it to him.

That aside, I captured a replay crash with wireshark, and the information is completely ****ing useless. Absolutely nothing shows up out of the ordinary.

This could be for one of two reasons i can think of (chime in with others if you can think of them)

1) There is no unusual network activity because that is not the cause of the reboot
2) the unusual network activity is not showing up because it isn't being detected. Sometimes, even with the best gear, wireshark is unable to snoop on peer to peer tcp communications. This is one of the things that "promiscuous mode" is supposed to deal with, but hey, who knows. If i had all hubs instead of switches, this might actually fix things, but my router is a switch, so there's no real getting around this... well, maybe i could hub a computer and the two replays together... *1

You may view a picture of my wireshark output during the "incident" at
www.ericf.com/reboot.jpg
If you feel like it, pull the plug from your box and plug it back in (power, i mean). Your wireshark will look just like that.
and by "just like that", i mean it will be normal, then all of a sudden, requesting an IP, cos it just rebooted.

anyone else got any other suggestions?
Aside from some people going to modem, and some people doing WIRNS without DNNA data, i got nothing. Can anyone do these?

*1 - Here's an idea... Hub a replay, replay, and computer. that's it. No internet. See if the ****ers crash. I'll do this tomorrow!

Hey, i just realised. It isn't the fault of funky guide data. If it were guide data, then pulling the network connection out of the box wouldn't fix the problem.

damnit.


LL
tlgs333 is offline  
post #118 of 331 Old 12-30-2007, 09: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 rm -rf *.* View Post

Please stop assuming "I wasn't getting what you were saying from the beginning" since I wasn't testing for the same thing that you are describing.

What you are describing will probably be the next thing that I will look into.

OK, I get it now. But just to be clear, you posted:

Quote:
Originally Posted by rm -rf *.* View Post

Quote:
Originally Posted by hdonzis View Post

But, if the Replay is also rebooting when it isn't recording, then it seems like it might be something more like the IVS update...

Henry

IVS is shut off on my RTVs. (port 00000).

No joy, still having reboots.

If I can find a local phone number, I'll change one over to dialup.

Which in my post to "might be something more like the IVS update" you replied "IVS is shut off". So, I thought you didn't understand that shutting off IVS wasn't stopping the IVS update that I was questioning might be a problem and that you quoted in your reply.

I think that using dial up would be an excellent experiment because it removes all possibility of network traffic and only leaves the guide data and the Replay hardware. But, if you were interested, it would still be interesting to see what happens when you disable IVS if the IVS RDDNS updates stop as well...

Henry
hdonzis is offline  
post #119 of 331 Old 12-30-2007, 09:43 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 hdonzis View Post

OK, I get it now. But just to be clear, you posted:



Which in my post to "might be something more like the IVS update" you replied "IVS is shut off". So, I thought you didn't understand that shutting off IVS wasn't stopping the IVS update that I was questioning might be a problem and that you quoted in your reply.

I think that using dial up would be an excellent experiment because it removes all possibility of network traffic and only leaves the guide data and the Replay hardware. But, if you were interested, it would still be interesting to see what happens when you disable IVS if the IVS RDDNS updates stop as well...

Henry

I was after something a bit different, and some of my posts were a bit less descriptive than others - and I was using some terms incorrectly, because I don't quite remember all of them at this point, so that just added to the confusion.

Still no news from New Zealand.
If we ever get any, we'll be sure to let you know.
rm -rf *.* is offline  
post #120 of 331 Old 12-30-2007, 10:01 PM
Member
 
MasterShake's Avatar
 
Join Date: Feb 2003
Posts: 25
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 0 Post(s)
Liked: 10
Quote:
Originally Posted by MasterShake View Post

Hmm. I too am having this problem lately on both Replays here (for at least a couple weeks), and I just checked with a remote family member who is seeing random reboots on their Replay. I'm currently waiting for the drive manufacturer's diagnostics to finish on one (which rebooted twice while watching one show this afternoon). I'm going to try clearing the guide data on one, and unplug the network cable for a week on the other.

Will report back with my results next weekend.

Replying to myself, just because...

So seven days back I cleared guide data on one (still rebooting, couple times) and yanked the cat5 on the other (up almost seven days now, no reboots since).

But that isn't really the point, and skimming through what I'd missed (holidays 'n' all), the discussion of IVS reminded me of something. I still have a copy of the old ReplayPC tools on my PC, and occasionally I use the rddns client included with it (don't ask). Anyway, a few weeks back I noticed that it no longer worked, the reason being that ReplayTV had changed the IP address for "rddns-production.replaytv.net" [1] (these two "discoveries" were several weeks apart, so I don't now exactly how far back this happened). After sticking in the new IP address and recompiling, the program works again to do an IVS lookup.

So I'm wondering, is it possible that there is something the "new" RD-DNS server is doing slightly (and only sometimes?) differently from the old. No idea what that might be if so.


[1]
In case anyone cares, here is the history of the IP address since the last ReplayPC updates (at least, the last one I downloaded):
64.124.73.112 (original source code)
64.124.80.12 (worked until sometime in Fall 2007)
64.124.73.123 (current)
MasterShake 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