# Problems with Replay 5040 - Reboots often



## mikekamerman

My replay 5040 has been exhibiting some strange actions as of late.

Every 2 or 3 days, the replay will reboot for no apparent reason.

Today we were watching a recorded show while the replay was recording

another live show. all of a sudden, screen goes blank and I get the

"please wait" page indicating a reboot. after several minutes, the show that was previously being recorded starts recording again (2nd segment in recorded show list), and I am able to go back and watch the previously recorded program. Pretty anoying...we lose about 5 minutes of the show being recorded.

Any logical reason for this? An suggested fixes...


Thanks

Mike Kamerman


----------



## tlgs333

I have this problem as well, and the HD, upon being tested by the manuf. software, reports no problems. I'll try the mobo screws.


----------



## nded

Diagnostics may "pass" on a drive that is still not cooperating. It could be the software is corrupt, so reimaging the drive with a fresh image at www.replaytvupgrade.com could fix it. On the other hand, it's not that expensive to put in a new compatible hard drive these days. You can always move the old drive a a DVArchive server and have the best of all worlds.


----------



## markjjordan

For the record, this has been happening to me,too... just last night, while watching a show, the unit rebooted out of the blue.


This is like the third time in as many weeks that it has happened. Did the mother ship push an update to us?


----------



## rm -rf *.*

An epidemic!


Must have something to do with DirecTV. They bought the patents and IP and within 24 hours they started pushing out dastardly software to break the RTV's!


It's all part of an evil master plan.


----------



## icecow

We're talking DTV here. I'm not the RTV skyfaller type, but man, I must admit DTV gives me the willies. You may remember their version of a sue campaign. They sued people with an open fish net.. they didn't care who they dragged in. Mo money. My memory is ever sketchy.. I believe some of the first cases DTV took to court made the judges take offence. I think DTV wanted to sue herds of 70 at a time with flimsy evidence. Those where thrown out. After that, DTV got weirder and weirder about their legal tactics. This was before the Bush years mind you, and before the RIAA used a lot of their brassknuckle tactics. Arguably, DTV's legal team was a precursor to the Bush administration and the RIAA strategy







I know that's a silly claim but it fits the reality snuggly.


Last I herd, mumbled by someone in this forum, DTV discontinued their sueing campaign (well I'm guessing they still sue people, but without the psychopath tactics) a year? a few years ago?


I'm biting my lip at the moment. All I can say is I think I'll email archie about records


----------



## mpgruett

Same problem here with two 5040s. Three days ago they started rebooting in the middle of recording shows. Both are running 530511440.


----------



## rm -rf *.*

530511440, AKA: RTV-O/S V5.1 build 144 is the most current release of the OS. There haven't been any OS changes since it was released a few years ago.


I believe the last patch was the DST update in spring of 2007.


----------



## Facilman

Same problem here. I experienced it a few months ago with my 5040 and thought my drive was dying, so I replaced it. I verified the mobo screws were tightened properly at that time. The new drive exhibited the same problem with my previous drive image, so before scrapping my shows and putting in a new image I poked around here some more. The fix of switching to modem and back again did the trick and it has been working fine until a few days ago. The modem-ethernet trick didn't work this time.


Same software version as everybody else.


----------



## icecow

The first thing you should do is do a manual update to get the guide data up to date, then unplug the ethernet cable from the back of the replaytv and reboot the replaytv. Let it go for a week without the network cable plugged in. If you have no reboots in that period plug back in the network cable and do another manual connect to get the guide data again. Then unplug the network cable and reboot the replaytv again. If it goes another week without any problem you are probably looking at a network problem. If that is the problem we'll cross that bridge when we get to it.


If during the period that the network cable is unplugged the replaytv continues to boot as you watch your shows then you are probably looking at a hard drive problem. Before you address the harddrive, you might want to do other--already mentioned--things: make sure the mobo screws are snuggly tightened, look for burn marks around the power adapter, extremely dirty fans..



At that point--if problem persists--just take the plunge and image a new harddrive from a fresh image file. don't copy your existing _problemed_ harddrive, that's stupid. Don't know why there is always a few people doing that. Doing so makes no sense what-so-ever.


preparing a new HD is easy, but if you wouldn't enjoy the prep time and reading time needed to image a drive send a PM to good ole mikeyboy and he'll sell you one you can slide into your replaytv and just go.


In your case maybe imagine one yourself though because it would suck if it wasn't the harddrive after all.


----------



## Space

It's interesting that people are just having this problem now, because my 5040 just started doing it as well after years of flawless operation.


It just reboots in the middle of recording a show, or in the middle of playback of an existing show. It also reboots when it is doing nothing.


I remember that one thing that can be a problem is having too many "Replay channels", so I went through by box and deleted about 10-15 channels that I no longer needed (and should have been cleaned up anyway since many of them are for shows that no longer exist). I am in "wait and see" mode to to see if this fixes the problem.


I don't remember if this "fix" works for the 5000 series or if it was for older models of ReplayTV, but I hope it works.


----------



## Ace987

Wow, I've been having the same problems too with one of my Replays. I'm not sure if it's happening with the other 3 since I don't watch them too often. I thought it was having too many shows on it, but maybe it's just an epidemic. I'll be watching this thread closely and will report back if I find anything.


----------



## chain777

I don't really use my 5040 much anymore, but in the last week I did notice a spontaneous reboot. I wouldn't have bothered posting here, but this thread does seem to be showing a trend. Since the software hasn't changed, I don't know what could be causing this issue.


Maybe something that's being sent from the mothership?


----------



## zabolots

Add me to the list of recent rebooters. Strange that so many are all seeing it out of the blue.


Scott


----------



## Murphy

I have also had a spontaneous reboot in the last week or so. The only thing common to all of us is the guide data. Maybe there is something in the recent guide data that the Replay software is not expecting and it gets into trouble trying to process it.


----------



## icecow

I haven't been watching, but even if it is an epidemic I'd still pull out the ethernet cable to see if it goes away.


What Murphy said is pretty convincing. Has anyone tried deleting the channel guide and re-gettting it?


----------



## hdonzis

I first posted this post at PlanetReplay back in the middle of November when my Replays had started rebooting (at least two of them at the time). I attributed the problem to WiRNS downloading the guide from the Replays. But, as I looked at all of my different recordings that had been interrupted by the Replays rebooting, I couldn't attribute all of them to happening when WiRNS was communicating with the Replays. In fact, only a couple of reboots were at the same time as WiRNS was coummincation with the Replays, which seems like a normal statistical event. Since that time, now all four of my Replays have rebooted while they have been recording. Some of them do it more often than others, but they have all done it now at one time or another...


Henry


----------



## rm -rf *.*

For some reason this topic seems deja vu. Didn't something like this start happening about 3 years ago, then suddenly stopped as mysteriously as it started?


Another question is if the units are rebooting prior to their 7-day reboot cycle.


----------



## Space

Yes, I understand that the 5000 series reboots once a week by design, but it is not supposed to happen while recording a show, plus it has happened at least 5 times in the last 3 days. It just happened again not 10 minutes ago (I guess deleting those Replay channels didn't help).


I suppose it is possible that corrupt guide data is being sent from the Replay server, which I think could only be fixed on the server (I would think that clearing the guide and redownloading will just redownload the corrupt data since many are having the same problem and it is not just a transient problem).


Maybe it is just corrupt data in a single show episode in the guide that will work itself out once that show is no longer in the guide?


----------



## MasterShake

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.


----------



## icecow

Yes, unplugging the network cable would still be a good idea I'd think. Though it's looks to be a widespread problem opposed to an individual problem it would still be good to know if the problem has to do with the network.


----------



## zabolots

Maybe it's the tin whiskers striking again










(Hey, if it works for NASA, why not Replay?)


----------



## Ningyo

This has been happening to me too. At least once a day, with twice yesterday I believe, and often in the middle of a show. The strange thing is that this is happening to two of my friends in the same house, but they're on a different network then mine.


I thought my HD was starting to go, but with my friends and so many people here having the same thing happen suddenly too, it's gotta be something out there.


----------



## Facilman

This problem seems too widespread to be pure coincidence. Something must be up beyond local user network issues. Like Murphy surmised I hope it is a bad bit of data in the guide that will work itself out over the next few days, because reboots in the middle of a recording are pretty annoying.


----------



## hdonzis

Well, I cleared the channel guide TWICE on all four of my units this afternoon with the hopes of the problem going away. Although I was watching a show on one of them a little while ago and about 10 minutes before midnight the Replay screen came up while I was watching the show and then it went away (like maybe it was thinking about rebooting or something). When I deleted the show after watching, the Replay displayed the Replay Guide in the middle of some other Theme show near where it should have been, but I've never seen it come back to the Replay Guide out of place like that before...


Henry


----------



## BaysideBas

Add another one to the list, 4 actually. All born 5040s, have started to spontaneously reboot, before the obligatory 7 day maintenance reboot, for the last few weeks. One of them on a daily basis and when nothing was happening but watching a std show on it.


----------



## Mike Cornwell

All 3 of my units have exhibited this behavior starting about a week ago. With lots of shows on each unit (100-160) and another 150 on DVArchive (at least the shows that are hidden, I have over 1200 that are 'offline'), I'm used to the occasional reboot when trying to access another Replay's list of recorded shows, but lately it's happening in the middle of viewing a local show, when the unit is sitting idle, etc. On average, once a day per unit.


I had the same problem (like others) maybe a month or so ago, and I thought it was related to a virtual Replay I had recently added using IVSmagic, so I deleted the virtual unit, with no success.


Thinking it was bad data in a guide, I cleared all of them, but the problem persists.


I don't run Wirns, just DVA, RTVrc, and IVSmagic.


I too think there's a bad show on a channel we all get that the Replay is somehow choking on. It'd be nice if there was an event log (the sysadmin in me thinking out loud).


----------



## pianoman41

Add me to the list. My 5040 has started doing it within the last week or so. I don't use it that often (Comcast DVR handles all the HD stuff, which is about 80% of my weekly recording) so it may have been doing it longer than that and I just haven't noticed. I recently started taping the NFL games that were being shown on the NFL Network for Poopli since not a lot of people get that channel, and that's when I started noticing it. Many of the games were recorded in two pieces because of a reboot in the middle of the recording. And I've caught it rebooting myself live about 4 times in the last two weeks--and I've *never* seen it do it once in the last 4+ years of owning/using it (even though I know about the maintenance reboots).


I was convinced it was HD or power supply just because of what I know about the hardware and its behavior until I saw this thread. WAY too many similar units doing this so frequently to be coincidence or simultaneous hardware failure for all of us. And since the software hasn't changed, it *has* to be guide data.


----------



## pianoman41

Either that or the Replay engineers programmed a time-release Easter Egg to make the hardware start going wonky right around the time they would have been releasing their big three-HD-tuner, show-sharing, WiFi-enabled, DVD-burner built-in, media streaming new units. You know, gently nudge the consumer into upgrading.


Too bad they couldn't have foreseen the bankruptcy and the subsequent sale(s).


----------



## Vincent Kennedy

Add me to the list too. I have an RTV 5080 that has started rebooting a few times a day. This started just a couple of weeks ago. The system has a fairly new drive in it (Less than a year old). The drive has worked fine for months and now it all of a sudden got weird! It has rebooted when I have been just watching, when I have been cleaning up recordings, while looking at the channel guide, and while recording.


I also have a 5040 and a 5504. Neither have started this behavior... yet.


While I find it annoying, my 18 month old get very irate when it does this during Elmo!


----------



## tlgs333

I've unplugged my network cable and the problems have stopped.


Now i don't believe that all of us are using the same networking hardware (i have a very basic hardwired/wifi setup from verizon fios, nothing weird on the network, been working for years, etc...) so something has gone weird.


BTW, i posted about this weeks ago, and everyone said i was crazy.


Anyway, it has been 4 days, no network hooked up on either of my two boxes, and no problems. I'm gonna wait a few more days, then plug only one of my two boxes into the network.

Perhaps it is interaction between two or more boxes? Does anyone here have the rebooting problem and only have one box?


Eric


----------



## markjjordan

I would like to determine if maybe the external network app(s) may be causing this... I currently run RTVrc, DVArchive, and IVSMagic on a server on the network. For everyone that has experienced these reboots, maybe we can find a common denominator on our respective networks?... Here's my list:


- DVArchive V3.2 on two Windows XP computers on the network... one of them gets unhibernated and hibernated when I use the treadmill (I use it to watch videos with VLC while running)

- RTVrc V0.2 (I keep this running all the time so I can access via VPN from my office)

- IVSMagic V1.0.0.0 Final (I only started running this when I restaged my computer at the end'ish of October. Before I was running a previous version.)


Mark


----------



## markjjordan

By the way... I only have one physical RTV on the network. As I said in my previous posting a couple of minutes ago, I do run 2 instances of DVArchive, though.


----------



## markjjordan

For the record... when I reinstalled IVSMagic at the end'ish of October, I set it up to run in "virtual replay mode". I am going to disable that mode today and see if maybe it is the culprit.


----------



## Vincent Kennedy

I did install a new network management program about the same time. IT is called Network Magic. About the same time I started getting many errors in my DVArchive log. I cannot remember what the exact error is. I will check when I get home.


The timing could be a coincidence, and the error could be from my 5080 going a little wacky.


----------



## Space

The first time I noticed this happening was when I was using DVArchive to offload a bunch of shows from the RepayTV to my PC overnight. Since I removed the limit on the transfer speed, I know that any other activity taking place on the 5040 while transferring can cause reboots, so I initially attributed the problem to this.


However, I don't usually have DVArchive or any other ReplayTV related equipment running on the network other than my 5040, and all subsequent reboots have occured with nothing else on the network (other than maybe a PC or two running non-ReplayTV stuff).


Now that I think of it, I suppose it is possible that one of the recent security patches that Microsoft has pushed out (and I have installed on my Windows XP box) may be causing new network activity (maybe with UPnP?) that could potentially cause the problem. I suppose if disconnecting the network cable from the ReplayTV causes the issue to stop, it is a possibility.


Does everyone experiencing this problem have a Windows XP box running on the same network?


----------



## markl

I noticed my ReplayTVs rebooting a couple of weeks ago also. My set up is:


2 ReplayTV 5040 (upgraded to 160GB) running 530511440

Both hooked directly to Comcast Cable

Both connected via ethernet

No 3rd party apps running

Other devices on the network:

1 Windows XP desktop connected via ethernet and running the latest MS updates

3 Windows XP laptops connected via wireless. All running the latest updates

1 Xbox 360 connected via ethernet (it just showed up yesterday under the tree so the problem preceed the Xbox)

1 HP printer connected via ethernet


My guess is that it is channel guide related. Too much of a coincidence for hardware failure and no new software updates in years.


Mark


----------



## rm -rf *.*




> Quote:
> Originally Posted by *markjjordan* /forum/post/12589315
> 
> 
> I would like to determine if maybe the external network app(s) may be causing this... I currently run RTVrc, DVArchive, and IVSMagic on a server on the network. For everyone that has experienced these reboots, maybe we can find a common denominator on our respective networks?... Here's my list:
> 
> 
> - DVArchive V3.2 on two Windows XP computers on the network... one of them gets unhibernated and hibernated when I use the treadmill (I use it to watch videos with VLC while running)
> 
> - RTVrc V0.2 (I keep this running all the time so I can access via VPN from my office)
> 
> - IVSMagic V1.0.0.0 Final (I only started running this when I restaged my computer at the end'ish of October. Before I was running a previous version.)
> 
> 
> Mark



I'm not running any of the external apps (I only turn on DVA when I need it and I haven't used it in months) and it would appear that one of my RTV-5k's only went about 3 days between reboots.


I don't watch much TV anymore, so all I'm doing is leaving the 411-zone screen up and checking the machine once a day. If it's gone, it rebooted.


I'm going to turn of IVS and close the IVS ports on my router and see what happens. I know that a few years ago, a couple of members (who shall remain nameless for the moment) figured out how to reboot replays remotely via the IVS port, I'm not saying that's what it is, but it's all that makes sense for my unit at this point.


According to the person I gave my 4k to ages ago, it's being affected by the random reboots too, BTW.


----------



## tlgs333

I've got an email into replay tech support, they said they don't know what is going on. They say they're going to look into it.

I don't have any external apps.

I don't have any ports open from the outside world pointing to my replays.

Curious!!!


Oh, and since i unplugged the boxes, no random reboots. So i'm plugging in one for now, leaving one out. I'll report back when/if one screws up!


----------



## pianoman41

Only one 5040 on my network, and although I use DVA, it's only up and running when I'm transferring shows to my PC (not that often). I would safely say all of my reboots have occurred when DVA has not been running. And no new network hardware in the mix.


Now I also have a Showstopper in the house and I don't know if it gets the *exact* same channel guide data/files as the 5XXX series, but it has *not* showed any reboot issues during this same time period.


----------



## pianoman41




> Quote:
> Originally Posted by *Space* /forum/post/12591121
> 
> 
> Now that I think of it, I suppose it is possible that one of the recent security patches that Microsoft has pushed out (and I have installed on my Windows XP box) may be causing new network activity (maybe with UPnP?) that could potentially cause the problem. I suppose if disconnecting the network cable from the ReplayTV causes the issue to stop, it is a possibility.
> 
> 
> Does everyone experiencing this problem have a Windows XP box running on the same network?



This is a good line of thinking too. I'm also running Windows XP and regularly update my OS to keep on top of security holes. I always install the latest critical updates as soon as they are available.


----------



## Ningyo

For me, I have a 5040 on a network without any other Replay units. On occasion, I run DVA to download a show to the PC, but I haven't done that in well over a month. My Replay is connected via ethernet to a NetGear wireless router. The only other things on the network are my PC and Xbox 360.


My friends downstairs have their own network, with both their Replays, PCs and a PS3 hooked in. They've been having the same problem.


I've been watching this my Replay recently, and for the past 2-3 days, it doesn't seem to be happening. I'm going to keep an eye on it however.


----------



## BaysideBas

Well, I'm not running either Wirns nor IVSM. DVArchive is turned only only when I need it, it wasn't on the last two reboots but yesterday an XP box was on. At today's reboot it wasn't. This is being posted from a Vista box. However, yesterday's and today's reboots occured at about the same time, a couple of minutes past 7:30 PM. This lends credence to the bad guide data theory. Something daily at 8:00 PM. I'm now going to look at the visible portion of the guide data in case there is something obvious.


Nope, nothing obvious in the visible portion of the guide.


----------



## Ningyo

I've had most of my reboots in the mornings, between 11am-noon, and some in the wee hours of the mornings, if that helps anything.


Maybe if we talk shows, we can pinpoint it?


I'm on Charter Digital for the Replay (Charter HD for the TV), and these are the two shows I remember it interrupting:


- The Price is Right (Drew rocks







)

- X-Play


----------



## adam1991

Add me to the list. Frequent reboots, while watching/recording, over the last three or so weeks.


Well, couple times a day, anyway.


----------



## rm -rf *.*




> Quote:
> Originally Posted by *BaysideBas* /forum/post/12593926
> 
> 
> Well, I'm not running either Wirns nor IVSM. DVArchive is turned only only when I need it, it wasn't on the last two reboots but yesterday an XP box was on. At today's reboot it wasn't. This is being posted from a Vista box. However, yesterday's and today's reboots occured at about the same time, a couple of minutes past 7:30 PM. This lends credence to the bad guide data theory. Something daily at 8:00 PM. I'm now going to look at the visible portion of the guide data in case there is something obvious.
> 
> 
> Nope, nothing obvious in the visible portion of the guide.



Bayside,


Do you still have some of your 5k's on modem connections?


----------



## tlgs333

So i have two boxes, and i had the network pulled from them for the past few days. I didn't experience any reboots. I just put the network back into one of the two, and next thing i know, a show that got partially recorded. (good eats on verizon FIOS)

I am not running DVA. I am not running windows XP. I am running a linux server and a few win2k boxes that aren't even usually on when this problem happens. Oh, and one mac os computer.

The box that has been disconnected from the network is still okay. No erroneous reboots.

I would blame my network settings if it weren't for the fact that we're all getting this!

I have an email discussion going with a tech at replaytv, but he hasn't gotten back to me after i've presented the most recent details.


Here is the email that i just received from a tech:

-------------

Yes I did read the entire thread that you sent. There are several

things that can cause reboots especially when streaming between multiple

units. As mentioned, heat, disk errors, network errors, status of the

hard drive capacity (approaching max capacity) to mention a few. While

you are eliminating issues with the network by having the units

unplugged, I wanted to see if there are errors reported on our network

from your unit (the reason for your serial number). I'm doing some more

research and will be in touch.

----------------

I have responded to him with the information regarding my recent findings (plugging one unit in caused a reboot mere hours later) and am waiting for a response from him. I did mention that since the problem is so widespread among the community, it is unlikely to be disks, network errors, capacity, etc.


Hopefully they can dust off a few boxes there and reproduce the problem!


anyway, try unplugging your boxes from the network and see if it gets better temporarily! To be sure, delete all of your half shows so you can see if new ones crop up. I am wondering if my fix is merely a coincidence, or fact. Lets gather more data!


Say, i'm going to go install ethereal and watch the box's network activity. maybe i'll see something crazy.

-----------

Ok, overnight, 1 box on the network, one off, and ethereal (apparently, it is now called wireshark) watching the box, no reboots, no odd network traffic so far... I will post info if it comes along!


----------



## riker

This house has three separate apartments, all with one Replay unit each. One is on it's own network and other connections, and two are on the same LAN but with different cable feeds. All three of them have been exhibiting the same behavior, with reboots happening about daily right in the middle of recording or playing. It happens while somoene is actively watching it, or all by itself as evidenced by two-part recorded shows with like a 6 minute segment and a 22 minute segment or something. They all started doing it in the past couple months. Seeing it couldn't possibly be hardware related or an isolated oddity, I came to this forum to see if others had the same experience, and voila. Obviously something big has happened. I was worried this was their way of phasing out the service, they will say there is some problem with the servers and since it's an obsolete product they won't fix it so will be dropping support and the Replay servers. I've owned a Replay since the day they were offered for sale over a decade ago, and have dreaded this moment for most of that period because thoughts of life without a Replay is just terrifying


----------



## RileySmith

Just add me to the list of replaytv 5040 that is rebooting out of the blue (pun intended)

usually watch the poopli forum, new to this site, but looks like a lot of good info here.

Riley


----------



## slowbiscuit

Well, I've got 2 55xx's, a couple of XP's (one running WiRNS), a Myth Linux, and a Vista box all on the same network. So far I've seen no unexpected reboots or partial recordings. Is it isolated to the 50xx's?


----------



## rm -rf *.*




> Quote:
> Originally Posted by *slowbiscuit* /forum/post/12602014
> 
> 
> Well, I've got 2 55xx's, a couple of XP's (one running WiRNS), a Myth Linux, and a Vista box all on the same network. So far I've seen no unexpected reboots or partial recordings. Is it isolated to the 50xx's?



I know of one 4k that rebooted after 3 days rather than 10.


I would say keep an eye on your 411-zones screens, right now, I'm just leaving them up on my 5k's, because I am currently recording so few shows (the last thing I recorded was the ARMY/NAVY game on Dec 1st) and rarely watch tv these days, if someone else hadn't mentioned it I never would have noticed that my RTV's were rebooting. Now it seems like they go about two-three days and then reboot.


----------



## icecow

bla bla bla


tlgs333 said his reboot problems stopped after pulling the ethernet cable. It might be that A-Hole directTV put in a software update without changing the version number. If indeed that conspiracy theory is true, someone might be able to find out by puting on the most current image from the ftp site and do a manual connect. If it says it's doing a software update but shows the same version number when finished: bingo. If not it's still vaguely possible the update will only happen upon a nightly connect (unlikely, but if you want to be thorough).


It would be good if a few others merely did a manual connect then unplugged their network cable for 6 days and report if there were any reboots.


It's possible that a DTV update is screwing up the local LAN connections. And of course I don't rule out it being on purpose.



With all that said, my bet is still on some kinda erronous guide data, and that all of the above isn't. But it would be nice to test a bit and figure out what the heck is going on..


bla bla bla


I'd do it myself but my replaytvs arent hooked up

I'd do it myself but my stupid U-Verse STP isn't hooked up

I'd do it myself but my 42" panasonic plasma TV (got it for $720!!) is still boxed at Liz's house (5 weeks so far).


I'm an idiot


----------



## rm -rf *.*

'cow, the reboots started before DirecTV acquirred the IP and patents.


----------



## tlgs333

Yeah, dude, this has been happening to me for at least 3 weeks, possibly a month. at first i shrugged it off.


anyway, ethereal (wireshark) watching all day, no reboots. so i have no news. The replay tech says he'll be contacting me soon. perhaps they've discovered something.


Has anyone else tested their rig by pulling the network cable(s)? Does anyone else have a network monitor going?


Hey, someone mentioned that they get 6 minutes of a show and 22. I noticed this too - it is never 15 minutes adn 13 minutes. It is always ~6 and ~25. Sometimes it is the first 6 minutes, sometimes the last 6 minutes.

Also, watching the early part of the reboot recorded show near the part where it reboots - crashes my replay. I don't mean that it reboots it - it totally freezes the thing! I guess a messed up mpeg can do that!


----------



## BaysideBas




> Quote:
> Originally Posted by *rm -rf *.** /forum/post/12594998
> 
> 
> Bayside,
> 
> 
> Do you still have some of your 5k's on modem connections?



No, I haven't been on modem in 18 months. No reboot at 7:30 tonight, so there goes that theory. One of the others has been rebooting on and around 11PM [when it was recording]. But the unit I was talking about rebooted yesterday just three hours later. I'll try to keep an eye on reboots both by checking for split recordings and checking 411Z whenever I'm using a unit in non-streaming mode. Pulling a unit out of service would be unfair to my poopli friends as I'm averaging 100 sends per month.


----------



## BaysideBas




> Quote:
> Originally Posted by *tlgs333* /forum/post/12604378
> 
> 
> Y
> 
> 
> Hey, someone mentioned that they get 6 minutes of a show and 22. I noticed this too - it is never 15 minutes adn 13 minutes. It is always ~6 and ~25. Sometimes it is the first 6 minutes, sometimes the last 6 minutes.



I noticed that too. The unit that reboots around 11PM exhibits that behavior, roughly. But the unit that was rebooting in the evening was doing it at 7:34. I never tried to watch the segments though.


----------



## markjjordan

Just throwing this out there... but the www.myreplaytv.com service has been discontinued since Oct. 26, 2007. I wonder in that has anything to do with this. If you goto the http://www.myreplaytv.com , you'll see a page stating the discontinuance of the service.


I know that when I do a 411Zones on my RTV, the last line says the following:

MyReplayTv: ENABLED


----------



## rm -rf *.*




> Quote:
> Originally Posted by *markjjordan* /forum/post/12605475
> 
> 
> Just throwing this out there... but the www.myreplaytv.com service has been discontinued since Oct. 26, 2007. I wonder in that has anything to do with this. If you goto the http://www.myreplaytv.com , you'll see a page stating the discontinuance of the service.
> 
> 
> I know that when I do a 411Zones on my RTV, the last line says the following:
> 
> MyReplayTv: ENABLED



At this point, anything is possible, but I haven't had that service enabled for any of my units for over three or four years now. I suspect that at least some of the other people posting in this thread have similiar situations.


----------



## jbacke

Add me to the list. I started noticing odd behavior 2 or 3 weeks ago. It had rebooted twice in that time while I was watching tv. I believe I was watching a show while recording it. Tonight it happened again. Started watching Deliverance, a few minutes delayed, and just after the dueling banjos, it reboots. When it comes back up it resumes recording. I did a manual net connect to refresh the guide data and while I was in the menu I noticed I had new messages, and there were a bunch in there, going back about 2 months, regarding not being able to contact the network. I very rarely have network outages, can't even remember the last time.


For now I'll leave the Ethernet connected, and maybe refresh the guide data every day. Hopefully, if it is corrupted guide data it'll get flushed soon. My buddy in another state is experiencing this problem as well. A lot of us in the same boat, and who knows how many others that don't frequent this forum.


Only other stuff on the network is a Vista machine with DVArchive, a networked HP printer, and another identical 5160. I just checked that Replay and it has zero messages, and I haven't seen that one reboot but I don't watch tv in that room much at all, mostly just used for conflict resolution. Since there's no error messages on the second Replay I'm wondering if this problem is only affecting the one unit. I know the error messages may not be related to the reboots but makes me think...


----------



## CrazyCanuck

I've been experiencing the same behavior over the past several weeks. Once a night, every night, replay will reboot and then everything seems to be fine for the rest of the evening. I have two 5040s, wired to DLink router, pc windows XP Media Edition, with DVarchive running.


----------



## Eye_Ballz

I've recently seen an increase in the number of shows that have two record sessions due to a reboot.

I thought it was just my hard drive having issues and never considered it to be a software issue.


----------



## tlgs333

Yet another night for me with no reboots. I'm starting to think that it is a watched-pot situation. I've got wireshark monitoring the network activity and it isn't happening anymore!


I'm going to plug in my second box and see if it happens more frequently. I want to see what is going on!


Anyone else pull their network and have the problem "disappear"?


----------



## markjjordan




> Quote:
> Originally Posted by *tlgs333* /forum/post/12608598
> 
> 
> Yet another night for me with no reboots. I'm starting to think that it is a watched-pot situation. I've got wireshark monitoring the network activity and it isn't happening anymore!
> 
> 
> I'm going to plug in my second box and see if it happens more frequently. I want to see what is going on!
> 
> 
> Anyone else pull their network and have the problem "disappear"?



My unit rebooted last night about 10:30 PM Eastern. I think I'll download this WireShark and do some monitoring myself.


----------



## rm -rf *.*

I closed off the IVS ports on my router and disabled IVS on all my RTVs a few days ago. No unexplained reboots yet.


----------



## rm -rf *.*

Maybe it's the guys over at Tivo sending out "pings of death" to all the RTV's.


Their sales are down, company is in the crapper, their DVRs still suck, they need to boost sales, why not start some widespread attacks against loyal ReplayTV owners?


Just a thought.


----------



## slowbiscuit

I'm starting to think it does have something to do with guide data - my 55xx's without probs are still on Comcast analog expanded basic so the channel count is low, like 50 or so. So maybe I've not seen the reboots because of something affecting a channel on the digital or sat tiers?


----------



## markl

My two 5160s are connected to Comcast basic directly. No cable box and no channels above 80. They still reboot.


Only one is set up for IVS but both are rebooting.


----------



## tlgs333

I do not have IVS set up, and i do not have any ports on my router forwarding from the outside world to the replays.


moreover, this problem happened when no changes to my rig were made. no firewall tinkering, no new computers, etc.


it is not IVS. It is not anything getting into the replays that is coming from the outside world.


----------



## Space

Hmmm, my 5040 has gone 2 days and 4 hours without a reboot. It had been rebooting once or twice a day prior to this.


I haven't done anything special to try to fix this problem (at least not since it's last spontanious reboot).


----------



## Xeriph




> Quote:
> Originally Posted by *tlgs333* /forum/post/12608598
> 
> 
> Yet another night for me with no reboots. I'm starting to think that it is a watched-pot situation. I've got wireshark monitoring the network activity and it isn't happening anymore!



Same here. I set up both my replays to record for ~4 hours last night and monitored the network with wireshark. My plan was to check the replays before I went to bed and see if any recordings were split in two...then use the timing of the split recording to see what kind of network activity was going on at that time. Wouldn't you know, neither replay rebooted during this test. Hopefully someone can capture something useful if enough of us keep at it.

edit
_Just checked on both replays and neither one has rebooted for at least 24 hours now._


----------



## Ningyo




> Quote:
> Originally Posted by *jbacke* /forum/post/12606423
> 
> 
> ...and while I was in the menu I noticed I had new messages, and there were a bunch in there, going back about 2 months, regarding not being able to contact the network. I very rarely have network outages, can't even remember the last time.



Ya know, I noticed the same thing on mine. I had a little while where my Internet would die out, but I found I had a bunch of messages telling me it couldn't connect.


It seems to be better as of this week, but I still had a reboot last night after one night without an issue.


I'm going to have to check, when I get home, to see if I have more messages.


----------



## Space




> Quote:
> Originally Posted by *Space* /forum/post/12614038
> 
> 
> Hmmm, my 5040 has gone 2 days and 4 hours without a reboot. It had been rebooting once or twice a day prior to this.
> 
> 
> I haven't done anything special to try to fix this problem (at least not since it's last spontanious reboot).



Well, 2 hours after I posted the above message I see that it has rebooted. Oh well.


----------



## tlgs333

Do we all have myreplaytv enabled? The tech asked me this today. I know that i do.


How do you disable it? I can't figure out how to turn it off (to see if it is part of the problem) and my google-fu is weak tonight. I can't get it to happen.


so

1) do you have it on? Chime in!

2) do you know how to turn it off? Post!


oh, and 2 days .5 jrs since last reboot for me.







but i have a LOT of wireshark logs.


----------



## rm -rf *.*




> Quote:
> Originally Posted by *tlgs333* /forum/post/12617870
> 
> 
> Do we all have myreplaytv enabled? The tech asked me this today. I know that i do.



I already answered that question , and since it hasn't been 24 hours yet, the answer would still be "no"











> Quote:
> Originally Posted by *tlgs333* /forum/post/12617870
> 
> 
> How do you disable it? I can't figure out how to turn it off (to see if it is part of the problem) and my google-fu is weak tonight. I can't get it to happen.



You can't "turn it off" anymore.


The only way to "enable" or "disable" the myreplaytv.com feature was by subscribing (setting up an account for your RTV) or unsubscribing (deleting said account) at the myreplaytv.com website. Since that interface no longer exists, you can't do anything.


Important point of note: The tech asked you if you were connected to an interface and feature that DNNA turned off three months ago, as a possible solution to a problem that started occuring about one month ago.


In short: The tech you talked to is a frickin' tool. Escalate it or we're doomed.


----------



## RileySmith

I have a very simple setup, just the replay, one desktop, and the mobile work laptop (that has dva loaded on, only used rarely). the last reboot during a recording was on 12/26/07 mythbusters. It shows 19 minutes recorded at 8:01 (I think I hit record after the show first started). interesting! I tried to watch the 19 minute segment and the show started, I then hit 30 second advance button, and it went to the play or delete screen, when I said play another recorded show, it locked up! can't select anything. But I had noticed on earlier split recording, that were say 6 minutes, it would not play six minutes. well wife is recording a show now and replay still frozen. don't want to manual reboot for fear of screwing up her recording. (if it's really recording).

As far as disconnecting the internet cable, haven't done that yet. (sending a show)

what the heck! I'm rebooting, there's a commercial on. well the reboot cleared the replay up (missed a little of the show) but there wasn't 19 minutes recorded. and the other segment says it's 38 minutes. Second segment seems to work okay.

Riley


----------



## twisted

I had scheduled "The True Story of Charlie Wilson" on two different Replaytvs. Both rebooted during their recordings on Dec-28: the first at about 2:30PM, the second about 2:38PM. The segments are mostly viewable.


All my Replays are 5040 and 5080. All are rebooting more often for at least the past two weeks, maybe more. Now that I am specifically looking at 411-Zones, all rebooted at least once on Dec-28 at various times. All my Replays have MyReplayTV: ENABLED. I don't think I can disable it without the active website - Is there a WRNS workaround?


Now I will log 411-Zones / reboot status every day.


----------



## hdonzis




> Quote:
> Originally Posted by *twisted* /forum/post/12620443
> 
> 
> I had scheduled "The True Story of Charlie Wilson" on two different Replaytvs. Both rebooted during their recordings on Dec-28: the first at about 2:30PM, the second about 2:38PM. The segments are mostly viewable.



I have two of my four Replays that record many of the same shows all during the day and night and I have never had them both reboot on the same recording. Each one has rebooted and generated two recording segments on different shows randomly. There are 4 daytime shows that they both record and about 3 nighttime shows that they both record. It works out pretty well because, so far, I always have the the whole show on at least one of the two Replays...



> Quote:
> Originally Posted by *twisted* /forum/post/12620443
> 
> 
> All my Replays are 5040 and 5080. All are rebooting more often for at least the past two weeks, maybe more. Now that I am specifically looking at 411-Zones, all rebooted at least once on Dec-28 at various times. All my Replays have MyReplayTV: ENABLED. I don't think I can disable it without the active website - Is there a WRNS workaround?



WiRNS has a checkbox for enabling MyReplayTV, "Update my.replaytv.com". If you are proxying your Replays through WiRNS (have the Replay's DNS addresses set to the WiRNS IP address), then I guess you can uncheck the checkbox and see if it makes any difference. Personally, I am skeptical, however...


Henry


----------



## seidelhd

Add me to the list. I know that my 5040 has been doing it frequently. I'm pretty sure that my 5504 has also, but have only noticed it while trying to pull up the recorded shows from the other unit. I'll have to look for partially recorded shows on each unit.


I was going to reimage and replace the hard drives, thinking this was the issue, but am glad I came here before going through that hassle.


----------



## rm -rf *.*




> Quote:
> Originally Posted by *hdonzis* /forum/post/12620527
> 
> 
> WiRNS has a checkbox for enabling MyReplayTV, "Update my.replaytv.com". If you are proxying your Replays through WiRNS (have the Replay's DNS addresses set to the WiRNS IP address), then I guess you can uncheck the checkbox and see if it makes any difference. Personally, I am skeptical, however...
> 
> 
> Henry



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.


----------



## rm -rf *.*




> Quote:
> Originally Posted by *RileySmith* /forum/post/12619807
> 
> 
> I have a very simple setup, just the replay, one desktop, and the mobile work laptop (that has dva loaded on, only used rarely). the last reboot during a recording was on 12/26/07 mythbusters. It shows 19 minutes recorded at 8:01 (I think I hit record after the show first started). interesting! I tried to watch the 19 minute segment and the show started, I then hit 30 second advance button, and it went to the play or delete screen, when I said play another recorded show, it locked up! can't select anything. But I had noticed on earlier split recording, that were say 6 minutes, it would not play six minutes. well wife is recording a show now and replay still frozen. don't want to manual reboot for fear of screwing up her recording. (if it's really recording).
> 
> As far as disconnecting the internet cable, haven't done that yet. (sending a show)
> 
> what the heck! I'm rebooting, there's a commercial on. well the reboot cleared the replay up (missed a little of the show) but there wasn't 19 minutes recorded. and the other segment says it's 38 minutes. Second segment seems to work okay.
> 
> Riley




Your RTV's problem could be both a disk going south and the mysterious reboot phenomina that's going around.



The split recordings could be the reboot issue, but frozen recordings, recordings that won't play and recordings that lock up or skip part of the way through are all indicators of a possibly failing hard disk.


Delete the affected segments and if you start getting more freezes, lockups, jumps/glitches or pixelations (note that pixelations could be at the carrier/provider end of the transmission) , then head over to www.replaytvupgrade.com and you'll find all the instructions, software and RTV-O/S images needed for replacing a drive.


If you don't want to do it yourself, then contact Mikeyboy at www.replaytvparts.com and he'll sell you a pre-formatted, fully-tested replacement drive.


----------



## mpsan

Add me as well. I have three and started seeing this with the only 5040 I have not upgraded. We had been streaming shows in another room and twice now we lost the RPTV we were streaming from. I thought it was the network, but last night we were watching from that room (bedroom) and it did a reboot while watching. I got the please wait screen for a while and had to restart watching the show.


What can be going on that all of a sudden we are getting this. We all can not have hardware issues within the same week!


----------



## seekins

Is is possible that we are all falling prey to selective observation?


For example, you never notice how many Nissan Maximas there are on the road until you actually buy a Nissan Maxima.


Is it possible that the reboots we are all suddenly noticing are just that - we just started noticing?


I can recall having partial recordings many times in the past. Has the number actually increased in the last few weeks? Or are we just noticing them?


Just a thought (left over from my psychology learnin', or was it sociology?).


Just to pour more fuel on the fire - I have 3 units - one 55xx (unmodified), one 5040 (new HDD added), and one 5040 (unmodified). The two 5040's, both of which where on MyReplayTV, are rebooting during recordings - the 55xx isn't (and also isn't on MyReplayTV).


----------



## bcochell




> Quote:
> Originally Posted by *seekins* /forum/post/12622563
> 
> 
> Is is possible that we are all falling prey to selective observation?



What s/he said.


I've seen it several times in the past.


Although, it does seem to be happening more frequently lately.


Like once or twice on each of my two machines in the past month.


----------



## mpsan




> Quote:
> Originally Posted by *seekins* /forum/post/12622563
> 
> 
> Is is possible that we are all falling prey to selective observation?
> 
> 
> For example, you never notice how many Nissan Maximas there are on the road until you actually buy a Nissan Maxima.
> 
> 
> Is it possible that the reboots we are all suddenly noticing are just that - we just started noticing?
> 
> 
> I can recall having partial recordings many times in the past. Has the number actually increased in the last few weeks? Or are we just noticing them?
> 
> 
> Just a thought (left over from my psychology learnin', or was it sociology?).
> 
> 
> Just to pour more fuel on the fire - I have 3 units - one 55xx (unmodified), one 5040 (new HDD added), and one 5040 (unmodified). The two 5040's, both of which where on MyReplayTV, are rebooting during recordings - the 55xx isn't (and also isn't on MyReplayTV).



Not in my case. We almost always streamed before and never had it go away. We always watched in the bedroom and never had it reboot during viewing.


----------



## mpsan

How do we contact ReplayTV any more to let them know that a lot of people are having this issue?


When I first started seeing this while watching a show in another room it would freeze. I stopped it and the unit I was streaming FROM was no longer showing in my normal list of three ReplayTV's. After a few minutes all was OK again. Since I was in another room I did not know the remote unit was rebooting until last night when we used that unit and saw the Please Wait screen while watching a show. This has been between 10pm and midnighy Pacific time.


----------



## ForumAmbulator




> Quote:
> Originally Posted by *seekins* /forum/post/12622563
> 
> 
> Is is possible that we are all falling prey to selective observation?



NO!!!


This is a real problem. It was almost never the case that I had reboots before. I watch everything I record - I record everything I watch - several hours a day... I would notice any reboot-caused segmentations. This is happening several times a day now, mostly noticed on the machine I mostly use....there we have observational effects....


I started having this problem on two RTV5040s the last few weeks. Until I looked at this message thread, I assumed I had a local hardware issue...MB, HD, etc... Now I am suspicious that it is outside interference over the network connection, or new software bugs... ReplayTV Service should be fixing this problem. Do we see people saying "I have my network connection and I am NOT getting reboots"???? Is it possible this is affecting everyone?


I think we should be looking for a class action law firm..... Fix it, vendor, or be sued!


----------



## adone36




> Quote:
> Originally Posted by *ForumAmbulator* /forum/post/12623633
> 
> 
> NO!!!
> 
> 
> I think we should be looking for a class action law firm..... Fix it, vendor, or be sued!



I think you must be used to being laughed at.


----------



## ForumAmbulator




> Quote:
> Originally Posted by *adone36* /forum/post/12623700
> 
> 
> I think you must be used to being laughed at.



Yes, by the vendors, who have better lawyers who wrote the agreement under which we purchase their services....


----------



## adone36




> Quote:
> Originally Posted by *rm -rf *.** /forum/post/12621052
> 
> 
> 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.



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.


----------



## ForumAmbulator




> Quote:
> Originally Posted by *adone36* /forum/post/12623775
> 
> 
> 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.



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.


----------



## Paco II

Add my 5120 to the list as well. Getting really annoying. Pretty bizarre.


----------



## rm -rf *.*




> Quote:
> Originally Posted by *adone36* /forum/post/12623775
> 
> 
> 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*


----------



## rm -rf *.*




> Quote:
> Originally Posted by *adone36* /forum/post/12623775
> 
> 
> 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.


----------



## hdonzis




> Quote:
> Originally Posted by *rm -rf *.** /forum/post/12621052
> 
> 
> 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


----------



## bron

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.


----------



## hdonzis




> Quote:
> Originally Posted by *adone36* /forum/post/12623775
> 
> 
> 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




> Quote:
> Originally Posted by *ForumAmbulator* /forum/post/12623977
> 
> 
> 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




> Quote:
> Originally Posted by *rm -rf *.** /forum/post/12624110
> 
> 
> 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


----------



## rm -rf *.*




> Quote:
> Originally Posted by *hdonzis* /forum/post/12624321
> 
> 
> 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.


----------



## rm -rf *.*




> Quote:
> Originally Posted by *hdonzis* /forum/post/12624180
> 
> 
> 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


----------



## hdonzis




> Quote:
> Originally Posted by *rm -rf *.** /forum/post/12625171
> 
> 
> 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


----------



## rm -rf *.*




> Quote:
> Originally Posted by *hdonzis* /forum/post/12626846
> 
> 
> 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.


----------



## hdonzis




> Quote:
> Originally Posted by *rm -rf *.** /forum/post/12627169
> 
> 
> 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


----------



## tlgs333

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


----------



## nvlady

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


----------



## rm -rf *.*




> Quote:
> Originally Posted by *hdonzis* /forum/post/12628190
> 
> 
> 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.


----------



## adone36




> Quote:
> Originally Posted by *hdonzis* /forum/post/12624250
> 
> 
> 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?


----------



## mschmitt

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.


----------



## hdonzis




> Quote:
> Originally Posted by *rm -rf *.** /forum/post/12631849
> 
> 
> 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


----------



## jesup

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.


----------



## jweinel

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


----------



## nvlady

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


----------



## boekjar

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.


----------



## tlgs333

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


----------



## bron

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.


----------



## rm -rf *.*




> Quote:
> Originally Posted by *hdonzis* /forum/post/12632106
> 
> 
> 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.


----------



## tlgs333

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.


----------



## hdonzis




> Quote:
> Originally Posted by *rm -rf *.** /forum/post/12635084
> 
> 
> 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 *.** /forum/post/12625171
> 
> 
> 
> 
> Quote:
> Originally Posted by *hdonzis* /forum/post/12624321
> 
> 
> 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.
Click to expand...


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


----------



## rm -rf *.*




> Quote:
> Originally Posted by *hdonzis* /forum/post/12635430
> 
> 
> 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.


----------



## MasterShake




> Quote:
> Originally Posted by *MasterShake* /forum/post/12573861
> 
> 
> 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)


----------



## rm -rf *.*




> Quote:
> Originally Posted by *MasterShake* /forum/post/12635839
> 
> 
> 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.



That's where Henry and I are going with this, once we get past the disfunction caused by the fact that I haven't looked at this in 2-3 years.


It appears that Henry and I are both starting to think that the RDDNS server might be periodically returing an unexpected result that could be causing a panic reboot of the RTVs.



On that note, if anyone's network sniffer grabs any RDDNS traffic between the RTV and _rddns-rns.replaytv.net_ or _rddns-production.replaytv.net_ right around the time of a reboot, please PM me, I'd like to take a look at the traffic, in particular, the respose cyphertext from the RDDNS server.


I'll also need to see a few "good" (non-reboot related) transmissions between your RTV and the RDDNS server and the responses too.


----------



## emmarie

Add me to the list. I have at least one replay that's been doing this for about a month. I've rarely turned this replay on in the last few months, because the shows it records are either in rerun or talk shows that are affected by the writers strike. Even though this machine hasn't been watched much, it is my most active recorder, because it is recording daily talk shows (Olbermann, Stewart, Colbert and some Judge Show I record daily for a poopli friend in LA). My other two machines have barely recorded anything, because I don't watch reality tv and all my regular shows have been halted until after the new year - so other than noticing that the machines have been disappearing from DVA often, I can't see the split recording on those two machines the way I do on the one that's actually recording shows. But I've noticed the blue light come on at various times during the day on all my machines, both when doing nothing and when doing something. I thought it was my hard drive going bad on the one machine. It's a 250GB drive with over 100 hours free space for recording - so it can't be blamed on lack of space, which would be my first thought.


In the beginning, because I thought it was just *My* bad drive, I just deleted the partial shows after watching them to keep people from requesting them through poopli. So unfortunately I have no record of when this all started.


I run DVA, IVSM and the Poopli+IVSM greasemonkey script almost 24/7 - I do not run WiRNS. I have Comcast Cable and am running XP. The machine that is most affected by this odd behavior is one of two machines with a direct coax cable hookup (no digital box). At one point I thought maybe it was IVSM querying my sends' IP addresses for progress. I had noticed, before installing the greasemonkey script, that a lot of times after I hit "Update IP" in IVSM my sends will stop immediately after noting the time of the last update. Now that the greasemonkey script notes the progress for me, I have no idea how the query works and how it's able to keep me constantly posted. I thought maybe it was possible that this constant progress was straining the machine.


Couldn't we just set our machine to record every show on a single station for a 24 hour period to tell us how many times a day it's rebooting? Would this be helpful at all? Would it tell us anything? Do I have a longterm log for DVA, cause couldn't I tell by checking that, how many times each machine rebooted in a day/week/month?


-em


----------



## RChobby

Add mine to the list, as well. Simple network, two replays, wired. No dvarchive, wirns.

Reboots 2x daily, apparently.


----------



## tlgs333

So in order to get a better look at what is going on, i'm going to hub-up ONLY two replays and a computer.

unfortunately, if it is rddns, the boxes will not reboot, and i will see nothing.


does anyone have a good idea on how to get a good spy going on the network traffic and still have an internet connection in there?

I could get a linux box with two network cards and have the traffic pass through it and log it that way... but that'd be beyond my capabilities.


perhaps i'll try plugging one of the ports of the router into the hub and see if the hub being the only connection between the replays and computer is enough to get all the traffic broadcast.


Eric


----------



## twisted

tlgs333, Sure your hub arrangement will work. Better than a software fix.


Of my replays, #1 has rebooted about 3 times every day. #2 went two days then rebooted, #3 rebooted at least once every day. Lots of split shows throughout.


----------



## tlgs333

I'm not trying to "fix" the problem, i'm trying to grab the traffic that occurs before it.


unfortunately, staples no longer sells hubs, so i'm at a loss for what to do at this point. I'm still going to mess around and try to get a better view of the traffic pre-reboot, but i'm not expecting much.


What is RDDNS used for? Is it only to update the replay servers as to what is on the boxes? What if i prevented RDDNS from being contacted? would my box's abilities suffer?


eric


----------



## hdonzis

Walmart still sells a NetGear 5 port hub.


Replay's RDDNS uses an HTTP protocol, so there should be no trouble capturing it. And, you should also see a DNS query for something with rddns in the hostname.


RDDNS is what allows IVS to send a show to another Replay. It uses RDDNS to find out the other Replay's IP address and IVS port number from the ISN that you enter...


Henry


----------



## verbaldave

Hi all,


My 5080 has also been rebooting sporadically. I don't have anything to add to this discussion on the technical end, but I think the simplicity of my setup might be telling.


I have only one Replay, which is completely stock:

It's wired to a hub (plugged into the hub are an XP laptop (though never used for anything RTV related), and a Mac laptop, and sometimes a flaky Apple Airport)

I've never used IVS (blissfully ignorant I guess)

I use my Mac with DVA to archive, occasionally

No WiRNS

I use the IR blaster with a Time Warner digital cable box

I am registered with MyReplaytv


Like others, I've seen split shows in the past, but probably only twice in the 4 years I've had RTV. But in the last couple of months the rebooting has gotten much worse. I don't record a lot, and didn't notice an overwhelming amount of reboots during live, or recorded playback, but after reading this thread, I suspect that it's rebooting daily. When I get home in the evenings the cable box will show channel 62 (the last channel I watched live that morning). But when I turn on the replay and hit "Channel Guide" it will have channel 2 selected (lowest # channel I have). To me this is pretty conclusive proof that it's rebooting daily, and possibly multiple times a day.


I'll use the 411 zones screen from now on in case this is more conclusive.


I wanted to add my name to the list of affected, but also let everyone know that this is happening with a box never set up, or used for IVS.


Thanks,

Dave


----------



## bron




> Quote:
> Originally Posted by *bron* /forum/post/12624186
> 
> 
> 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.



My two units have now gone almost 3 days and 5 days, respectively, without rebooting. (2d21h and 4d23h)


Both still on ethernet and inet. No new split shows.


P.S. Good thinking, MasterShake! (and others)


----------



## anidea




> Quote:
> Originally Posted by *RChobby* /forum/post/12636257
> 
> 
> Add mine to the list, as well. Simple network, two replays, wired. No dvarchive, wirns.
> 
> Reboots 2x daily, apparently.



Sort of ditto here, 2 5080's unmodded and wired, no wirns but yes for dvarchive. For the last month or so, they've done spontaneous reboots (I haven't counted how often but I never noted them before and suddenly it seems like "a lot"). In the last week, one of them sort of "froze" twice on two different recorded programs playing from the other RTV, which made me think it was the HD (of which one, i couldn't be sure), until I read this....


----------



## mpsan




> Quote:
> Originally Posted by *anidea* /forum/post/12640066
> 
> 
> Sort of ditto here, 2 5080's unmodded and wired, no wirns but yes for dvarchive. For the last month or so, they've done spontaneous reboots (I haven't counted how often but I never noted them before and suddenly it seems like "a lot"). In the last week, one of them sort of "froze" twice on two different recorded programs playing from the other RTV, which made me think it was the HD (of which one, i couldn't be sure), until I read this....



That is what happened to me...froze while watching from another room. BUT, I tried a few days ago and did a manual connect before watching. Then, when it was done updating the data, we watched a two hour show with no issues!


----------



## Space

In order to capture packets with Wireshark and still have the Replay connected to the Internet you can use a normal broadcast hub (not a switched hub!) with at least 3 Ethernet ports.


Disconnect the Replay from your existing router/switch then connect a new cable in this port on the router/switch, connect the other end of this cable to your new broadcast hub (note that you may need to use a crossover cable to do this if your hub does not automatically detect (or have a manual switch setting) that it should be in crossover mode). In any case you need to have a link light on the ports at both ends of the cable, if you don't then most likely it is not in crossover mode.


Once this is working, connect your Replay in to another of the ports on the broadcast hub and also hook your Wireshark PC to a third port on this same hub.


Now you should be able to see all traffic to/from the ReplayTV on your Wireshark PC (not just broadcast (and prehaps multicast) traffic like you would if you just hooked you Wireshark PC directly to the switched hub.)


The hard part may be finding a non-switched (broadcast) hub these days, I would think most hubs sold today would be switched.


UPDATE:


Just found this link: http://morichtech.com/NetworkMonitoring.html .

Solution 2 is what I attempted to described above.

They appear to use the Netgear hub mentioned in this thread that is available at Wal-Mart.


----------



## tlgs333

My previous plan of making a two-replays and a computer network failed due to lack of long enough cables and frustration.

I'm going to my parents for NYE, so i will rummage through the museum of antique computer parts for an ancient hub. I knew this would work all along, but i simply don't have that kind of hardware.

Is there anyone else here who wants to do this simultaneously with me so we can get some more data? It may be days before i get a reboot again...

Eric


----------



## snoutmeat

I don't have too much to add except "it's happening to me too".

I went to planetreplay to see if there was any helpful troubleshooting advice on what I'd assumed was a problem with my machine. I found a message there that sent me here. At least now I know I'm not alone, and I know enough not to start taking apart my machine.










I don't know if this makes any difference, but in addition to the random reboots, my machine also locks up in a ~1-second loop. I need to walk up to the machine and hold the power button for a few seconds to get it to reboot. This happened 2x last night in a 1-hour show.

Crap! It just did it while I was watching. I was watching the Simpsons, and it was recording the show as well. I was watching it ~5 minutes delayed. I'm also receiving a show via IVS. The machine must have been somewhat busy; of course, it appears from other posts in the thread that this doesn't seem to be a factor in the reboots.


My machine: 5040 upgraded a couple of years ago with a 200ish GB drive. No WiRNS, using an ethernet connection, IVS enabled, regular Poopli user, haven't used DVArchive since before these problems started appearing. There's also a 5504 (upgraded to 200ish GB more than a year ago) in the bedroom. Both are connected to each other via my wired home network. We don't turn on the TV in the bedroom, but we often stream shows from the 5504 to the 5040.


My level of expertise is somewhat limited -- I can image and install drives without any problem, but I'm not an expert with networking.


If there's anything I can do to help with the troubleshooting, please let me know. Otherwise, I'll sit around and eagerly await the progress of others.


--Shane in Seattle


----------



## nvlady

Hi Shane,


I have also experienced the 'looping' as well (twice) and the only way to resolve it was by holding the power button down. The good news is that I haven't had a reboot since I moved the box from a network to a modem connection.


Happy New Year all!


Beth


----------



## rm -rf *.*




> Quote:
> Originally Posted by *nvlady* /forum/post/12643081
> 
> 
> Hi Shane,
> 
> 
> I have also experienced the 'looping' as well (twice) and the only way to resolve it was by holding the power button down. The good news is that I haven't had a reboot since I moved the box from a network to a modem connection.
> 
> 
> Happy New Year all!
> 
> 
> Beth



How long ago did you switch it to a modem conneciton?


----------



## adam1991

As I mentioned earlier, my two units have been doing this for a couple months now.


I went through one of my 5040s (large HD, though) last night and noticed that virtually all of the partial and split shows showed the reboots to be happening between 8:00 and 8:30 am and 8:00 and 8:30 pm.


Weird, very weird.


----------



## nvlady




> Quote:
> Originally Posted by *rm -rf *.** /forum/post/12643089
> 
> 
> How long ago did you switch it to a modem conneciton?



I made the switch yesterday afternoon around 1:30 PST. Not very long, but I was getting reboots at least once a day and so far none (I am doing the 411 zones thing someone mentioned in an earlier post).


----------



## rm -rf *.*




> Quote:
> Originally Posted by *nvlady* /forum/post/12643171
> 
> 
> I made the switch yesterday afternoon around 1:30 PST. Not very long, but I was getting reboots at least once a day and so far none (I am doing the 411 zones thing someone mentioned in an earlier post).



Thanks.


Please keep us posted on the reboots now that you've made the switch.


----------



## karen514

Just wanted to add my name to the constant reboot list. I can barely get a full recording anymore, especially on one of my Replays. It reboots in the middle of recording every night. Happened tonight 50 minutes into SNL in the 90's show.


One other thing I wanted to add which I haven't seen in this thread... on my other Replay (both are 5xxx) every time I am browsing through my channel guide, and I try to view a channel higher than 254 either by page down, the single down arrow, or typing in the number, my Replay reboots. It only happens on 1 of my 3 Replays. The other two have only been rebooting during recording or viewing.


----------



## rm -rf *.*




> Quote:
> Originally Posted by *karen514* /forum/post/12643636
> 
> 
> Just wanted to add my name to the constant reboot list. I can barely get a full recording anymore, especially on one of my Replays. It reboots in the middle of recording every night. Happened tonight 50 minutes into SNL in the 90's show.
> 
> 
> One other thing I wanted to add which I haven't seen in this thread... on my other Replay (both are 5xxx) every time I am browsing through my channel guide, and I try to view a channel higher than 254 either by page down, the single down arrow, or typing in the number, my Replay reboots. It only happens on 1 of my 3 Replays. The other two have only been rebooting during recording or viewing.



The second problem might not be related to the first.


Try clearing the chanel guide.

243-ZONES -> CLEAR CHANEL GUIDE (RTV will reboot)

do it again

243-ZONES -> CLEAR CHANEL GUIDE (RTV will reboot)

then

243-ZONES -> NETCONNECT


----------



## jweinel

I have an observation related to a reboot that just occurred on one of my 5040's. It rebooted at approximately 10:34 pm EST. I didn't get the exact time until after I had voiced a few comments regarding the interruption. Then, I took a look at the log that my Netgear router constantly records:


[ALLOW:64.124.73.123:80] Source: 192.168.1.149 Monday, 31 Dec 2007 22:29:19

[ALLOW:rss.molar.is] Source: 192.168.1.106 Monday, 31 Dec 2007 22:31:09

[ALLOW: www.murinn.is] Source: 192.168.1.106 Monday, 31 Dec 2007 22:31:10

[ALLOW:feeds.feedburner.com] Source: 192.168.1.106 Monday, 31 Dec 2007 22:31:10

[ALLOW:isapi60.wxbug.com] Source: 192.168.1.103 Monday, 31 Dec 2007 22:31:18

[ALLOW:64.124.73.123:80] Source: 192.168.1.149 Monday, 31 Dec 2007 22:33:15


IP 192.168.1.149 is the 5040. 192.168.1.106 and 103 are pc's, one receiving RSS feeds and the other a Weatherbug update. Neotrace identified the IP that the 5040 talked to as:

Name: 64.124.73.123.replaytv.com

IP Address: 64.124.73.123

Registrant: D&M Holdings US


I'm sure this reveals nothing new to the gurus closely following this saga but I thought I would note it. It's the first time I've been watching live when a reboot occurred and it seems to directly correlate to comms with the Mothership (one contact 4 minutes before the reboot, and a contact which seems to just precede the reboot).


Happy New Year!

Jim


----------



## twisted

FYI I sent an e-mail to customer service on Friday Dec-28 and got two replies. Sunday the director of customer care said "looking into it" and Monday from tier-2 support saying "please call."


So I believe they are taking this seriously and I will call support with my details.


I watched a lot of ReplayTV this weekend and at least one of mine has been rebooting about 3 times a day at seemingly random times. A couple of times it appeared to coincide with remote button presses but the replays were not heavily loaded (in one case I just accepted a receive but nothing was recording, just playback; second case I just started a playback and nothing was recording or sending/receiving; in third case NOTHING external was happening, no recording or playback or sending). FYI if you leave DVA running it will tell you when the replays disappear/reappear.


jweinel - it is odd that there are two connections 5 minutes apart from your replaytv to 64.124.73.123 - that is the current RDDNS address. As I recall there is usually just one connection every hour.


----------



## karen514




> Quote:
> Originally Posted by *rm -rf *.** /forum/post/12643760
> 
> 
> The second problem might not be related to the first.
> 
> 
> Try clearing the chanel guide.
> 
> 243-ZONES -> CLEAR CHANEL GUIDE (RTV will reboot)
> 
> do it again
> 
> 243-ZONES -> CLEAR CHANEL GUIDE (RTV will reboot)
> 
> then
> 
> 243-ZONES -> NETCONNECT



Thanks for your help. I tried what you said and then went to the channel guide to test it out. It made it one more screen down but then rebooted. It even happens when I'm in add/remove channels. Between this and the other rebooting issues, I'm getting incredibly frustrated!


----------



## snoutmeat




> Quote:
> Originally Posted by *nvlady* /forum/post/12643081
> 
> 
> Hi Shane,
> 
> 
> I have also experienced the 'looping' as well (twice) and the only way to resolve it was by holding the power button down. The good news is that I haven't had a reboot since I moved the box from a network to a modem connection.
> 
> 
> Happy New Year all!
> 
> 
> Beth



Good news for you, but not so good for me...we scrapped the land line a year ago, so I can't try the telephone option.











I wonder how widespread the problem is...I wouldn't have come to this forum unless my machine were acting up. It's like someone with a cold going to the drugstore for medicine, and then going to the doctor, and seeing everyone else around sneezing and coughing and assuming that everyone has a cold.







Is there some way to put up a poll where more people can see it -- not just those of us who are affected?


----------



## tlgs333

Some of you are having problems *in addition* to the main problem that everyone else is having.


1 second loop person - I am guessing you are experiencing either very busy/noisy network, or your hard drive is dying. first pull the network out, then pull and test the drive.


channel guide person - you are having channel guide trouble. Reloading it is the first course of action, no matter how difficult it is. It may also be hard drive trobule.


Person who is hooked up to a phone line now - good work. Finally someone takes some initiative. Unfortunately, we're like 99% sure your problem won't occur, since even pulling the network cable solves the problem.


what we need is some good network monitoring. Unfortunately, i wasn't able to get a hub, so i can't view the network to the extent that is necessary.

Between working with customer support and trying to get a hub, i'm tapped.


Everyone PLEASE call tech support. Seriously. They will help us a LOT faster if people CALL to complain. They do not do tech support over email.


Call this number and tell them everything that is happening. Then tell them the problem isn't fixed when they ask you to reboot your box. Also mention that your network hardware hasn't changed in years. (if it hasn't)


Phone: 254-299-2705


Regards

Eric


----------



## DVRDude




> Quote:
> Originally Posted by *tlgs333* /forum/post/12646069
> 
> 
> Everyone PLEASE call tech support. Seriously. They will help us a LOT faster if people CALL to complain. They do not do tech support over email.
> 
> 
> Call this number and tell them everything that is happening. Then tell them the problem isn't fixed when they ask you to reboot your box. Also mention that your network hardware hasn't changed in years. (if it hasn't)
> 
> 
> Phone: 254-299-2705
> 
> 
> Regards
> 
> Eric



Add me to the list of spontaneous reboots. One of my units has been rebooting (split shows) frequently for about a month. This unit records my wifes soaps daily, so I am more likely to see the reboots on that unit. I have seen an ocassional split show on my Replay #2 over the last couple of weeks, but with the holiday season repeats, it isn't recording much right now. I was beginning to think that my Replay #3 (the only non-upgraded one) was not experiencing reboots, but I was just watching a show streamed from it and it rebooted. I will monitor the frequency of reboots today, and call support tomorrow.


----------



## RileySmith

I too will call support tomorrow, but it would be nice if they would just except our problem and not go thru all of the testing.

just on another note, I'm new to this site, is there a choice on reading a forum to go to first unread post and not have to search thru previous threads?

Riley


----------



## Space




> Quote:
> Originally Posted by *RileySmith* /forum/post/12647401
> 
> 
> ...
> 
> I'm new to this site, is there a choice on reading a forum to go to first unread post and not have to search thru previous threads?
> 
> Riley



Yes, just click on the little light blue "down arrow" icon that precedes the topic in the thread list. As a reminder, if you hover the mouse pointer over this icon you will get a tool tip that says "Go to first new post".




> Quote:
> Originally Posted by *jweinel* /forum/post/12643918
> 
> 
> ...
> 
> It's the first time I've been watching live when a reboot occurred and it seems to directly correlate to comms with the Mothership (one contact 4 minutes before the reboot, and a contact which seems to just precede the reboot).



Are you sure that the second contact to the Mothership didn't happen AFTER the reboot?



I just had another reboot, and I have noticed on a few occasions (including this one) that after a spontaneous reboot, my 5040 immediately reboots again.


----------



## DVRDude




> Quote:
> Originally Posted by *Space* /forum/post/12647638
> 
> 
> I just had another reboot, and I have noticed on a few occasions (including this one) that after a spontaneous reboot, my 5040 immediately reboots again.



Exactly the same here. My primary Replay just rebooted and immediately rebooted again.


----------



## Murphy

I cleared the guide data twice on all three of my 5040's (original hard disks). I then did a connect to reload the guide data. Two units completed successfully. The third unit paused for a long time in the combining step at 92% and then rebooted. Since that time one unit rebooted after 3 hours and another rebooted after 4 hours. The third unit has not rebooted (yet). None of the units are recording or being used for playback. They are just sitting there in standby state (i.e. the blue laser is turned off).


----------



## Eye_Ballz

I've gotten so sick of it rebooting I've decided to disconnect the network cable.

I'll connect the cable manually and do a manual update once a day until this gets fixed.

Hopefully this will minimize the broken recordings.

I had it reboot this morning when I paused Planet of the Apes for 10 minutes and no recording was going on.


----------



## tlgs333

EYE-


I am doing the same thing you are - if you remove the network cable, you won't get broken shows, but you also won't have room to room sharing (if you have more than one box).


Please call tech support next chance you get and let them know of your problem.


Regards

Eric


----------



## jweinel

Quote:

Originally Posted by Space...

Are you sure that the second contact to the Mothership didn't happen AFTER the reboot?

----------------------

I think you are correct, Space. I just experienced a reboot on my other 5040 and the Netgear router log again shows 2 comms with one occurring just after reboot:

[ALLOW:64.124.73.123:80] Source: 192.168.1.150 Tuesday, 1 Jan 2008 18:22:17

(5040 rebooted at 18:24 30)

[ALLOW:64.124.73.123:80] Source: 192.168.1.150 Tuesday, 1 Jan 2008 18:25:50


The exchange prior to the reboot must be triggering the reboot and the second exchange takes place when the unit has recovered??


Jim


----------



## bcochell

It must be contagious.


This morning my cable company's Scientific Atlanta 8300 HD DVR rebooted this morning while recording the Cotton Bowl.


----------



## rm -rf *.*




> Quote:
> Originally Posted by *bcochell* /forum/post/12650006
> 
> 
> It must be contagious.
> 
> 
> This morning my cable company's Scientific Atlanta 8300 HD DVR rebooted this morning while recording the Cotton Bowl.



Coincidence.


----------



## Mike Cornwell

Yes, I think he knew that, or are you just trying to pad your post count?


----------



## rm -rf *.*




> Quote:
> Originally Posted by *Mike Cornwell* /forum/post/12650644
> 
> 
> Yes, I think he knew that, or are you just trying to pad your post count?



LOL.


----------



## lt123

just wanted to throw my hat in -- same issues as everyone else. not only split recordings, but lots of reboots, especially when i'm running through the channel guide.


----------



## mpgruett

OK, guys - I got a complete packet capture before and after the Replay rebooted.







Ethereal/Wireshark capture file is attached in ZIP format.


My Replay - 172.20.10.82 - talks to the Replay server at 64.124.73.123 for 10 packets via HTTP, reboots and talks to the same server via HTTP for another 15 packets (of which three are resets) after it comes back up (223 seconds later). This capture was exclusively filtered to 64.124.73.123 ("host 64.124.73.123" if you must know the exact syntax). This capture was taken on my internal network off of a hub I put the Replay onto along with a W2k box where I did the capture so I didn't miss anything that was bound for 64.123.73.123.


Now, incidentally, the Replay had tried the other two servers first. Here's the exact log from my NetScreen firewall:


2008-01-01 22:03:46 0:05:15 172.20.10.82 1053 64.124.73.123 80 HTTP x.x.x.x 1790

2008-01-01 22:02:29 0:00:15 172.20.10.82 1024 64.124.73.123 80 HTTP x.x.x.x 2091

2008-01-01 21:57:43 0:00:52 172.20.10.82 1052 64.124.80.9 80 HTTP x.x.x.x 1856

2008-01-01 21:57:43 0:00:53 172.20.10.82 1051 64.124.73.105 80 HTTP x.x.x.x 1631


(x.x.x.x is me filtering out my outgoing IP after the NAT on the firewall). So the Replay tried 73.105 and 80.9 first so I'm going to run another capture with all three in the filter to see if we learn anything but I figured I'd get this capture up for everyone to see and study ASAP so we can try and figure this out.

 

rrdns-reboot.zip 1.4619140625k . file


----------



## Space




> Quote:
> Originally Posted by *jweinel* /forum/post/12649768
> 
> 
> Quote:
> 
> Originally Posted by Space...
> 
> Are you sure that the second contact to the Mothership didn't happen AFTER the reboot?
> 
> ----------------------
> 
> I think you are correct, Space. I just experienced a reboot on my other 5040 and the Netgear router log again shows 2 comms with one occurring just after reboot:
> 
> [ALLOW:64.124.73.123:80] Source: 192.168.1.150 Tuesday, 1 Jan 2008 18:22:17
> 
> (5040 rebooted at 18:24 30)
> 
> [ALLOW:64.124.73.123:80] Source: 192.168.1.150 Tuesday, 1 Jan 2008 18:25:50
> 
> 
> The exchange prior to the reboot must be triggering the reboot and the second exchange takes place when the unit has recovered??
> 
> 
> Jim



Yes, I believe it does a RDDNS update after a reboot, so that would explain why you see that network activity around the time of the reboot (after not before). I am not sure if the prior RDDNS update has anything to do with the problem, but I would think it unlikely since it happens a couple minutes before, but it is always possible.


----------



## mpgruett

Also, since we've been debating about how often this happens here's my outbound log from the NetScreen for both Replays (.81 and .82) talking to the three Replay IPs:


2008-01-01 22:03:46 0:05:15 172.20.10.82 1053 64.124.73.123 80 HTTP x.x.x.x 1790

2008-01-01 22:02:29 0:00:15 172.20.10.82 1024 64.124.73.123 80 HTTP x.x.x.x 2091

2008-01-01 21:57:55 0:01:04 172.20.10.82 1042 64.124.80.9 123 NETWORK TIME x.x.x.x 1842

2008-01-01 21:57:43 0:00:52 172.20.10.82 1052 64.124.80.9 80 HTTP x.x.x.x 1856

2008-01-01 21:57:43 0:00:53 172.20.10.82 1051 64.124.73.105 80 HTTP x.x.x.x 1631

2008-01-01 21:24:37 0:00:14 172.20.10.81 1053 64.124.73.123 80 HTTP x.x.x.x 1659

2008-01-01 21:09:13 0:00:14 172.20.10.82 1039 64.124.73.123 80 HTTP x.x.x.x 2509

2008-01-01 20:55:30 0:00:12 172.20.10.81 1052 64.124.73.123 80 HTTP x.x.x.x 1864

2008-01-01 20:52:00 0:00:09 172.20.10.81 1051 64.124.80.9 80 HTTP x.x.x.x 1463

2008-01-01 20:52:00 0:00:15 172.20.10.81 1050 64.124.80.9 80 HTTP x.x.x.x 1377

2008-01-01 20:52:00 0:01:13 172.20.10.81 1049 64.124.73.105 80 HTTP x.x.x.x 1168

2008-01-01 20:51:50 0:01:03 172.20.10.81 1049 64.124.73.105 123 NETWORK TIME x.x.x.x 1158

2008-01-01 20:51:48 0:01:03 172.20.10.81 1048 64.124.80.9 80 HTTP x.x.x.x 1390

2008-01-01 20:24:35 0:00:12 172.20.10.81 1047 64.124.73.123 80 HTTP x.x.x.x 1447

2008-01-01 20:09:13 0:00:14 172.20.10.82 1038 64.124.73.123 80 HTTP x.x.x.x 1188

2008-01-01 19:24:35 0:00:13 172.20.10.81 1046 64.124.73.123 80 HTTP x.x.x.x 1252

2008-01-01 19:09:12 0:00:13 172.20.10.82 1037 64.124.73.123 80 HTTP x.x.x.x 1402

2008-01-01 18:24:37 0:00:15 172.20.10.81 1045 64.124.73.123 80 HTTP x.x.x.x 1182

2008-01-01 18:09:12 0:00:14 172.20.10.82 1036 64.124.73.123 80 HTTP x.x.x.x 1296

2008-01-01 17:24:34 0:00:12 172.20.10.81 1044 64.124.73.123 80 HTTP x.x.x.x 2886

2008-01-01 17:09:10 0:00:12 172.20.10.82 1035 64.124.73.123 80 HTTP x.x.x.x 1282

2008-01-01 16:24:34 0:00:13 172.20.10.81 1043 64.124.73.123 80 HTTP x.x.x.x 1154

2008-01-01 16:09:11 0:00:14 172.20.10.82 1034 64.124.73.123 80 HTTP x.x.x.x 1206


So, interesting observations. Looks like Replay #2 at .82 was checking in every hour on the 9s but then at 21:57 it decided to do something else that was not part of it's regular hourly rotation.


Also, notice that the top HTTP connection has a time that lasts for exactly 5:15 and the 2nd one lasts for 0:15. So, apparently a successful and unsuccessful (i.e. causes a reboot) exchange last exactly 15 seconds. However, the first one failed and the TCP connection was never torn down correctly (obviously, the Replay rebooted) so the extra 5 minute timeout for inactivity on the firewall applies and thus, the firewall closes the connection exactly 5 minutes later and logs it, after which time the Replay has already successfully rebooted and open and closed a new connection (the 2nd entry datestamped at 22:02:09).


So when looking above, the 1st connection at 22:03:46 is actually the connection that caused the reboot (subtract 5 minutes to find out when it really happened) and the 2nd one at 22:02:09 is the successful one but it got logged first. So, all of that explanation to come to this conclusion - if the Replay reboots w/o even bothering to tear down the TCP connection, that most certainly would mean that the Replay is not receiving a reboot message but rather the data it gets back is causing a buffer overflow or kernel panic and causing the system to reboot then and there (i.e. no reboot command is ever issued to the Replay I'd guess since if it was, it would most likely go through it's shutdown process and wait for any existing connections to finish).


I apologize to those of you who are getting lost in this thread with my 2 very technical posts but obviously something very wrong is going on here and unless we start trying to do packet captures and analyze log files we're not going to get ourselves a solution any faster.


----------



## Mike Cornwell

Just had a back to back reboot like others.


I'm a big Poopli sender, but don't do much receiving (1750/398 send/receive ratio), but if blocking the RRDNS IP's at my router might keep my Replay from rebooting 1-3x per day, I'll put Poopli on hold, or at least focus everything on my IVSmagic virtual replay.


I'd rather not pull the ethernet cable from my unit's, as we do a lot of in-house streaming...


[EDIT: OK, for $hit$ and giggles I've blocked 64.124.73.123 at my router. Did a manual net connect, and that still works, and my current outbound IVS transfers seem to be going still, I'll keep an eye on them I have DVArchive logging set to high, so I get e-mails every time DVA loses connectivity with one of my (3) units, so I should be able to tell when reboots happen. I'll post with any updates.]


----------



## zabolots




> Quote:
> Originally Posted by *Mike Cornwell* /forum/post/12652341
> 
> 
> 
> I'd rather not pull the ethernet cable from my unit's, as we do a lot of in-house streaming...



Ditto


----------



## nvlady

Just an update....I pulled my network cable Sunday afternoon and have not had any reboots since....I will keep you all posted of any changes


----------



## Mike Cornwell

After some testing, it appears my Linksys WRT54GS router running SVEASOFT firmware doesn't seem to want to block by IP address, but it does work by URL name, which is rddns-rns.replaytv.net


----------



## hdonzis

Easy enough! I changed my router's host file to have rddns-rns.replaytv.net point at my WiRNS machine. That should keep IVS and Poopli happy since WiRNS will continue to update RDDNS on behalf of the Replay without the Replay communicating with DNNA...


Which makes me wonder, is anyone who is using WiRNS to proxy their 55xx Replay or Canadian or whatever having the reboot and segmented recordings problem? I would think that WiRNS would be protecting the Replays if the problem was with the RDDNS update...


By the way, at least in my case, disabling RDDNS instead really shouldn't have much of an impact. Since my ISP never changes my IP address (or, at least rarely) and RDDNS doesn't expire, I would think that stopping the Replays from performing the RDDNS update wouldn't hurt anything with IVS and Poopli...


Henry


----------



## KenL




> Quote:
> Originally Posted by *hdonzis* /forum/post/12652947
> 
> 
> ...Which makes me wonder, is anyone who is using WiRNS to proxy their 55xx Replay or Canadian or whatever having the reboot and segmented recordings problem? I would think that WiRNS would be protecting the Replays if the problem was with the RDDNS update...



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?


----------



## markjjordan

Throwing another couple of thoughts into the ring... not sure if they are relevant or not. But I would be remiss if I didn't express them...


A daylight savings time change occurred in October. I wonder if this is affecting anything, although I can't see how it could.


Also, some have suggested that the guide data could possibly be causing issues. I don't know if maybe there are only certain cable markets this is affecting, but I'll offer my cable guide criteria as the following to see if maybe there's a common denominator:

Provider: Comcast

State: Michigan

Zip Code: 49525
Just offering as fodder for the investigation. No ideas are stupid, right?


----------



## elisherer

OK folks... I've had a 5040 since forever ago, and upgraded to a 300GB HD a long time back (at least 3 years). The Random Reboot is happening every few days on this Master Machine, and I'm pretty sure it's happening on my Stock 5040 and 5000 as well (no HD upgrades there).


Checked all software and all running the latest. Will try the manual connect to see what's what, but I've had no messages saying any of them could not connect in the past months.


As I was looking into the thread, my daughter is sitting watching a recorded show from two days ago. No other Replay on the network (all Ethernet) is running and no shows are recording... all of a sudden... Static and reboot. When I looked, it appears that the last Random Reboot was ~5 days ago...


Strange stuff... and perhaps a matter of legal intrigue, especially for those of us with "Lifetime" subscriptions!


----------



## BaysideBas




> Quote:
> Originally Posted by *elisherer* /forum/post/12654285
> 
> 
> 
> Strange stuff... and perhaps a matter of legal intrigue, especially for those of us with "Lifetime" subscriptions!



Hmmm.... and the conspiracy birds can start flocking. Out of my 5 units, the only one NOT suffering the random reboot syndrome is the only one on a monthly subscription... Ya don't think????


----------



## elisherer

Actually, on the conspiracy front... I've checked with my wife, and she says that the Monthly Replays have NOT been doing the Spontaneous Rebooting (as far as we know).


The Plot Sickens....


----------



## adone36

I had a Replay which said "last boot" 5 days ago. Then I noticed the guide hadn't updated either. My router sometimes locks up during large d/l and I had to reset it a few days ago. Apparently this Replay was working fine on the intranet but not able to get outside. I rebooted it and did a net connect during which it rebooted again and has been happily rebooting every day since.


----------



## BassKozz




> Quote:
> Originally Posted by *elisherer* /forum/post/12654967
> 
> 
> Actually, on the conspiracy front... I've checked with my wife, and she says that the Monthly Replays have NOT been doing the Spontaneous Rebooting (as far as we know).
> 
> 
> The Plot Sickens....





> Quote:
> Originally Posted by *BaysideBas* /forum/post/12654786
> 
> 
> Hmmm.... and the conspiracy birds can start flocking. Out of my 5 units, the only one NOT suffering the random reboot syndrome is the only one on a monthly subscription... Ya don't think????



I've got a monthly subscription on both of my 2-5080's and mine are "spontaneously rebooting"










At first I thought my HD was going bad on one of them, but now I've noticed both units are exhibiting this behavior, must have something to do with a resent software upgrade (over-the-wire)...


What is Replay/DNNA, Inc. up to?


----------



## BaysideBas




> Quote:
> Originally Posted by *BaysideBas* /forum/post/12654786
> 
> 
> Hmmm.... and the conspiracy birds can start flocking. Out of my 5 units, the only one NOT suffering the random reboot syndrome is the only one on a monthly subscription... Ya don't think????



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


----------



## adone36

There has been no "software upgrade".


----------



## DVRDude

I just spoke with Tech Support, and he was unaware of the problem. He suggested the usual troubleshooting tips - unplug the unit for a minute or two, plug it back in and force a net connect. If that didn't work, force a restore of everything. We all know that those things will not solve this problem. I was able to guide him to this thread for him to see all of the others that are having the same problem. He indicated that he would escalate this problem.


Time will tell...


----------



## BassKozz




> Quote:
> Originally Posted by *DVRDude* /forum/post/12655811
> 
> 
> I just spoke with Tech Support, and he was unaware of the problem. He suggested the usual troubleshooting tips - unplug the unit for a minute or two, plug it back in and force a net connect. If that didn't work, force a restore of everything. We all know that those things will not solve this problem. I was able to guide him to this thread for him to see all of the others that are having the same problem. He indicated that he would escalate this problem.
> 
> 
> Time will tell...



Please keep us posted DVRDude.


----------



## KenL




> Quote:
> Originally Posted by *BaysideBas* /forum/post/12655585
> 
> 
> 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.


So let me guess, a converted 5500 is still immune, but naked 50xx are vulnerable so long as they are exposed.


(not that far fetched to wonder if this isn't some 3rd party tactic, perhaps in cahoots with ISPs, to further fleece content providers under the guise of thwarting activities which can be sold as a threat to the vile and ever paranoid MAFIAA™)


----------



## hdonzis




> Quote:
> Originally Posted by *KenL* /forum/post/12653103
> 
> 
> Notice there is not even a mention of this in the WiRNS forum.



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? It is also posted in the 5000/5500 forum on PlanetReplay...


Maybe it's more because people with the problem either aren't subscribed to PlanetReplay or think that AVSForum is a better place to post the problem...


Henry


----------



## hdonzis




> Quote:
> Originally Posted by *KenL* /forum/post/12656206
> 
> 
> 
> 
> Quote:
> Originally Posted by *BaysideBas* /forum/post/12655585
> 
> 
> 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.
Click to expand...


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


----------



## Murphy




> Quote:
> Originally Posted by *hdonzis* /forum/post/12656342
> 
> 
> 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.


----------



## icecow

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 


bla bla bla


----------



## KenL




> Quote:
> Originally Posted by *hdonzis* /forum/post/12656260
> 
> 
> 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?


----------



## hdonzis




> Quote:
> Originally Posted by *icecow* /forum/post/12656440
> 
> 
> 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
> 
> 
> 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




> Quote:
> Originally Posted by *KenL* /forum/post/12656533
> 
> 
> 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


----------



## FreyGuy

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


----------



## MyReplay

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.


----------



## jimmcq

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.


----------



## KenL




> Quote:
> Originally Posted by *hdonzis* /forum/post/12656713
> 
> 
> ...Unfortunately, WiRNS doesn't log the RDDNS events since they happen so regularly...



Are you sure?


What is this business:
Code:


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.


----------



## mpgruett

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).


----------



## tlgs333

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!


----------



## rm -rf *.*




> Quote:
> Originally Posted by *mpgruett* /forum/post/12658228
> 
> 
> (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?


----------



## jweinel




> Quote:
> Originally Posted by *FreyGuy* /forum/post/12656869
> 
> 
> 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


----------



## Murphy

DNNA is keeping the guide update service so DirecTV is/will not be involved.


----------



## icecow

Oh sure, that's what the media channels report to the masses.


----------



## mpgruett




> Quote:
> Originally Posted by *rm -rf *.** /forum/post/12658545
> 
> 
> 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


----------



## rm -rf *.*




> Quote:
> Originally Posted by *mpgruett* /forum/post/12659134
> 
> 
> 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.


----------



## theotherguy

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.


----------



## slowbiscuit




> Quote:
> Originally Posted by *KenL* /forum/post/12653103
> 
> 
> 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.


----------



## drewfidelic

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.


----------



## hdonzis




> Quote:
> Originally Posted by *KenL* /forum/post/12657189
> 
> 
> Are you sure?
> 
> 
> What is this business:
> Code:
> 
> 
> 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


----------



## KenL




> Quote:
> Originally Posted by *tlgs333* /forum/post/12658546
> 
> 
> 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.


----------



## hdonzis




> Quote:
> Originally Posted by *mpgruett* /forum/post/12658228
> 
> 
> 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


----------



## KenL




> Quote:
> Originally Posted by *hdonzis* /forum/post/12659416
> 
> 
> ...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?


----------



## hdonzis




> Quote:
> Originally Posted by *KenL* /forum/post/12660082
> 
> 
> 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




> Quote:
> Originally Posted by *KenL* /forum/post/12660082
> 
> 
> 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




> Quote:
> Originally Posted by *KenL* /forum/post/12657189
> 
> 
> Are you sure?
> 
> 
> What is this business:
> Code:
> 
> 
> 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




> Quote:
> Originally Posted by *KenL* /forum/post/12657189
> 
> 
> Are you sure?
> 
> 
> What is this business:
> Code:
> 
> 
> 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:


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


----------



## tlgs333

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


----------



## KenL




> Quote:
> Originally Posted by *hdonzis* /forum/post/12660139
> 
> 
> ...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



That's good. Actually all DNNA communication still seems to be in order with this configuration. My ip changes fairly often but IVS seems to keep up, what little I do.


Ironically I tried to point the 4th 50xx directly at DNNA to see if I could confirm the reboots. But it couldn't complete a functional net connect (without WiRNS filtering) of my program sources. So I gave up on the reboot testing. Guess I'd have had to use dummy (or obsolete WiRNS listings) to set test records on the extra box to entertain reboots.


> Quote:
> Originally Posted by *hdonzis* /forum/post/12660168
> 
> 
> 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



I downloaded a copy of that back before you'd have a chance to remove the feature. I had about 10 minutes to connect a replay a play around with it, looked like it will work great for my purposes. However I didn't have time to experiment with WiRNS (on the active replays) during (what there was) of the fall season.


Should be able to get to it soon but of course now it seems prudent to entertain the post DNNA future looming large. BTW the versions of WiRNS I'm using ran for all those months without incident or even crashing that I was aware of?


But thanks much for locked lineups! Hopefully we'll get to make full use of that for at least a few months. That is if any season returns and before Replay activation gets the deep six.


----------



## Mike Cornwell




> Quote:
> Originally Posted by *tlgs333* /forum/post/12660723
> 
> 
> Eric,
> 
> There was a problem with the RDDNS server on the backend. This appears
> 
> to be fixed now...



In other words, they rebooted the server?


----------



## tlgs333

Yeah, who knows. What's crazy - I emailed him back to thank him and got a out of office reply saying he no longer worked there and to contact another guy @ a totally different domain.com.


fixed one thing and broke another? Or he was fired for helping for real? who knows... crazy.


----------



## mpsan




> Quote:
> Originally Posted by *tlgs333* /forum/post/12661393
> 
> 
> Yeah, who knows. What's crazy - I emailed him back to thank him and got a out of office reply saying he no longer worked there and to contact another guy @ a totally different domain.com.
> 
> 
> fixed one thing and broke another? Or he was fired for helping for real? who knows... crazy.



...or, it is still broken and he sent the email as he quit!


----------



## twisted

woo hoo?


----------



## tlgs333

Only time will tell!


----------



## hdonzis




> Quote:
> Originally Posted by *KenL* /forum/post/12660897
> 
> 
> Ironically I tried to point the 4th 50xx directly at DNNA to see if I could confirm the reboots. But it couldn't complete a functional net connect (without WiRNS filtering) of my program sources. So I gave up on the reboot testing. Guess I'd have had to use dummy (or obsolete WiRNS listings) to set test records on the extra box to entertain reboots.



You have to clear the channel guide (only once) when you switch from WiRNS to DNNA, or use a different zipcode...


Henry


----------



## KenL




> Quote:
> Originally Posted by *tlgs333* /forum/post/12663190
> 
> 
> Only time will tell!


_Only time will tell_ if anyone tests for reboots before BrettStah or tootsTivo crashes that server again?


Or they all got sacked and _only time will tell_ if it's only a matter of weeks before we are all stuck on the activation nag screen?


----------



## KenL




> Quote:
> Originally Posted by *hdonzis* /forum/post/12663284
> 
> 
> You have to clear the channel guide (only once) when you switch from WiRNS to DNNA, or use a different zipcode...
> 
> 
> Henry



Or both.


However it won't complete the unfiltered DISH lineup for whatever reason from the select lineups menu without unexpected errors... especially when you are watching or in a hurry. And it takes forever. Should have done a simple dummy analog cable box, less than 100 channels. Or better yet forget about the reboots and just use WiRNS!


Hopefully the reboots part is fixed now.


----------



## markjjordan




> Quote:
> Originally Posted by *tlgs333* /forum/post/12660723
> 
> 
> 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



This is good news... but we'll see. My last boot as of this moment was 19'ish hours ago per 411Zones. If it can make it past 24 hours, then I'll be at least 75% confident. My box has not made it past 6 hours of continuous up time prior to today without rebooting.


Gonna monitor throughout the day.


----------



## BaysideBas




> Quote:
> Originally Posted by *Mike Cornwell* /forum/post/12661180
> 
> 
> In other words, they rebooted the server?



That'll teach them to run Vista on the server


----------



## anidea




> Quote:
> Originally Posted by *icecow* /forum/post/12656440
> 
> 
> 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



Huh. Interesting that the machine giving me the most trouble has an episode of Galactica on it...maybe it's sci-fi in general? or spinoffs of cheezy old sci-fi tv series that they're targeting?


Anyway, looking forward to checking the machines tonight.










Edit: I didn't notice any split recordings today, BUT...did anyone notice that commercial advance seems to not be working at all? Even on things it worked on before?


If I try to get into all this WIRNS stuff, can I get it to work again?


----------



## markl

This thread has been quiet for over a day. Does that mean the reboots has subsided? I have been exeriencing power outages today so my uptime data is not accurate.


How is everyone else doing?


----------



## jweinel

Over 2 1/2 days without a reboot on the 5040 that I left connected to the network. I have now reconnected the other 5040 in hopes that the problem has been resolved.


----------



## RileySmith

Just checked my replay in 411 Zones and it said 2:06:09 so I guess that means 2 days.

Riley


----------



## dando

no reboots since the fix. Prior to the fix, I was rebooting every couple of hours.


----------



## adone36

No reboots.


----------



## hdonzis

I'm still redirecting RDDNS through WiRNS and no reboots. Not sure I'll ever go back...


Henry


----------



## twisted

only one out of three rebooted after two days but it didn't split a show. I dunno if it's right but it is better.


----------



## BaysideBas

All units appear to be back to normal operation.


----------



## zabolots

No reboots here either. Nice to everything back to normal.


----------



## markjjordan

3 days of uptime. Good to be back to normal. Long live ReplayTV (please).


----------



## mschmitt

OK, now we know that the problems was an invalid response to the RDDNS update, and that WiRNS users weren't affected because they are proxying RDDNS.


But wouldn't IVSMagic users also be unaffected?


And what about all the users that have their ReplayTVs directed to the backup RDDNS servers? If the backup RDDNS is acting as a proxy for the RDDNS update I'd think that while the backup RDDNS might not like the response from the real RDDNS, it wouldn't pass a bad response back to the requesting ReplayTV.


I don't recall posts in this thread saying that machines using the backup RDDNS did or did not frequently reboot.


And one more thing: wouldn't the backup RDDNS detect bad responses from the real RDDNS? I wonder if the people running the backups noticed anything odd.


----------



## hdonzis




> Quote:
> Originally Posted by *mschmitt* /forum/post/12695352
> 
> 
> OK, now we know that the problems was an invalid response to the RDDNS update, and that WiRNS users weren't affected because they are proxying RDDNS.
> 
> 
> But wouldn't IVSMagic users also be unaffected?
> 
> 
> And what about all the users that have their ReplayTVs directed to the backup RDDNS servers? If the backup RDDNS is acting as a proxy for the RDDNS update I'd think that while the backup RDDNS might not like the response from the real RDDNS, it wouldn't pass a bad response back to the requesting ReplayTV.
> 
> 
> I don't recall posts in this thread saying that machines using the backup RDDNS did or did not frequently reboot.
> 
> 
> And one more thing: wouldn't the backup RDDNS detect bad responses from the real RDDNS? I wonder if the people running the backups noticed anything odd.



Specifically, WiRNS always responds to the Replay's RDDNS update with an OK in all cases. So, I guess that's not technically proxying, although it did proxy the request, just not the resonse...


I'm not sure how IVSmagic handles RDDNS, but the code is public, now, for you to look at...


Since Ryan wrote the backup RDDNS, he would have to say for sure, but since you change your Replay's DNS address in order to use the backup RDDNS instead, I would have to assume that it would be similar to WiRNS (especially since the same guy wrote both things). Since the Replay is communicating with the backup RDDNS, then the response would be coming from there instead of DNNA...


Jon and Ryan are running backup RDDNSes. I'm not sure that the code cares about the response from DNNA. I know it doesn't care if it doesn't get any response because that's what its purpose is, but I think it logs if it doesn't get any response that RDDNS is down. I'm not sure if it logs bad responses and I'm not sure if it checks the response the same way that the Replay does (how would anyone know?)...


Henry


----------



## sfhub

BTW I think the bad responses have been happening for a while. I remember getting corrupted data and non-responses as far back as October 24.


----------



## pianoman41




> Quote:
> Originally Posted by *mschmitt* /forum/post/12695352
> 
> 
> And what about all the users that have their ReplayTVs directed to the backup RDDNS servers? If the backup RDDNS is acting as a proxy for the RDDNS update I'd think that while the backup RDDNS might not like the response from the real RDDNS, it wouldn't pass a bad response back to the requesting ReplayTV.
> 
> 
> I don't recall posts in this thread saying that machines using the backup RDDNS did or did not frequently reboot.



I'm pointing to the backup RDDNS servers and I was having the reboot issue like everyone else (posted at the beginning of this thread). Like the rest, my problems seem to have been solved with the DNNA reboot on their end, so the backup RDDNS servers were definitely prone to this error as well.


----------



## karen514

Not only haven't I had any spontaneous reboots or split recordings since Tues night, but I'm now able to scroll past channel 254 in my channel guide without rebooting as well.


----------



## RileySmith

No reboots on my end for at least three days. Thanks to all the very smart people that tracked this down. If it was a nudge, maybe they decided it wouldn't be as easy as they thought.

Riley


----------



## pianoman41

Well I will say this, if it wasn't for the technically able-minded (and willing) Replay fanatics here on AVS, this problem probably would have never been fixed. Kudos to everyone who took an extra moment of time to help figure this out and solve it for Replay. Now who should DNNA make the check out to?


----------



## adam1991

No reboots anymore here, either. Thanks, everyone.


----------



## nvlady

I am just got around to moving my 5040 back to the network connection and while it was trying to get its network configuration via DHCP, it rebooted. The only change I have had is that I have downloaded WIRNS and am trying to get that going. Could that have caused the reboot?


Thanks!


----------



## rm -rf *.*




> Quote:
> Originally Posted by *nvlady* /forum/post/12713935
> 
> 
> I am just got around to moving my 5040 back to the network connection and while it was trying to get its network configuration via DHCP, it rebooted. The only change I have had is that I have downloaded WIRNS and am trying to get that going. Could that have caused the reboot?
> 
> 
> Thanks!



I think that was just an odd quirk, somehow triggered by the change in network settings.


About a year or so ago, when it finally became necessary to add a DHCP server on my network, and I was switching my RTV-5k's from static IP's to DHCP (to coenside with IP reservations) when I was in the networking system control panel, two of my three RTV's rebooted as soon as I made the swtich. One did not.


Now, I don't run wirns, and your situation is a little bit different, but if it doesn't do it again, then I would just forget about it and not worry.


----------



## nvlady

Thanks for the reply! I am hoping that is the case and plan to keep it on the network just to see what happens. I just could not resist playing with some of the tools mentioned in this thread


----------



## rm -rf *.*

DVArchive has always been a stellar piece of software, Gerry single-handedly created a piece of software for interfacing with DVRs that is well desiged that for almost anyone who uses it, it becomes the benchmark by which similar programs and products are judged.


WiRNS - I haven't used this program since before Ryan took over the project, and from what I've seen recently and what I've heard, he's done an amazing job with it.




Other DVRs should have it so well.



























Nah, not really. Let them be jealous.


----------



## BassKozz




> Quote:
> Originally Posted by *adam1991* /forum/post/12712125
> 
> 
> No reboots anymore here, either. Thanks, everyone.



Ditto


----------



## Elvis_Presley

Add me to the list as well...

I did notice this starting back in December as well on one of my 5040's


In some cases, I witnessed it happen a couple of times right at the time of a scheduled record event. When the RTV switched channels, it simultaneously rebooted. Maybe this is a clue as to what might be causing this?


Is there a concensus that this is a software/guide issue or a contact issue in the power supply?


----------



## rm -rf *.*




> Quote:
> Originally Posted by *Elvis_Presley* /forum/post/12723130
> 
> 
> Is there a concensus that this is a software/guide issue or a contact issue in the power supply?



Neither.


RDDNS.


----------



## verbaldave

My stock 5080's uptime is 3 days, 1 hour and counting (No WiRNS, no IVS). Thanks to those who called tech support!


----------



## n9yty

I was having this problem too on a single 5040, splitting shows because of reboots while recording, or while just sitting idle. I'm glad you guys managed to get them to sort it out. Just did a 411 Zones to get a report, and at this point it's Elapsed time since last boot is: 1:07:22:05


----------



## Senven

Same issue here. I have 3 replay units and all have been acting weird. The one unit running on wireless seems to have the reboot issue more often. This unit also started into what appeared to be an endless reboot loop. I disconnected the unit and opened it up to blow out all of the dust and it is again working. I started to order a new HDD to replace in this one, but that is when i noticed my other Replays acting up also.


The last time it happened was lastnight. I was recording the new One Tree Hill for my wife and i hit replay guide to see if there was something i could watch and it rebooted the instant I hit the replay guide button.


----------



## tlgs333

Well, It has happened to me again. Anyone else? It may be coincidence, as i was recently DVarchiving and might have pulled off too fast. Hopefully it is nothing...


----------



## RileySmith

I hit the 411 zones to see how long it had been since my last reboot and the zones pane (the one that comes up when you just hit the zones button) so I tried again (thought I might not be fast enough) same thing. On the third try the 411 screen popped up for about a fraction of a second. Then my replay would not accept any commands from either of my remotes. (my wife has one too!). So I manually rebooted because I had show going to record in a few minutes.

My question is though, in the past when I tried to do the 411 zones thingy it would always just pop up for a fraction of a second. never could use it, but when we were having the rebooting thing I tried it and it came on and stayed on the screen. weird, any ideas?

Riley


----------



## daviedavo

Add me to the list -


I have:

1 - 5040 - unmodified - static IP (due to IVS) - using built in analog tuner

1 - 55xx - unmodified - DHCP assigned IP - controlling a digital cable box

2 - Windows 2000 machines - not running any RTV software

1 - Windows XP machine - running DVA almost constantly

1 - MAC Mini - sometimes playing around with DVA but usually not on

1 - Linksys 8 port wired router

Cox Cable broadband internet


I started having problems with my 5040 sometime in November - only sporadically at first but increasing in late December. This machine reboots at least once a day at seemingly random times - when I am recording, not recording, watching live tv, streaming from other RTV, downloading via IVS, or even while it is doing nothing . . .


The 55xx started having the same problems sometime in December but with much less frequency as the 5040. My 55xx will sometimes go 2 days or so without rebooting.


I have also gotten split recordings on both RTVs due to the reboots - and like others have noted sometimes if I try to watch a split recording the RTV will freeze and reboot.


I have owned RTVs for the last 5 years and can only remember a (small) hand full of times combined that either box has had any problems.


I just started trying out IVS last week so this would not seem to be the problem - as far as using IVS - I do not know anything about the hourly polling that has been talked about earlier in this thread.


Absolutely nothing in my home network setup has changed in the last ~8 months - far preceding the problems.


Like many others I at first assumed that the HD on my 5040 was dieing . . . until my 55xx exhibited the same symptoms. Even then I thought that coincidentally they both were dieing . . . until today when I stumbled upon this forum.


I virtually only watch TV time shifted so I am positive that all of these problems have just occurred recently - these problems have not been going on prior to November without me noticing!


I am fairly knowledgeable about computer hardware/software but do not have any real networking troubleshooting experience other than the basics of setting up LANs. I did double check all connections and settings on my LAN - nothing has changed and, as far as I can tell, everything is working properly and playing nice together in my home setup.


I would love to help find the solution but since it sounds like the issue must be something to do with RTV networking I will probably be of no use.


Let me know if there is anything I can do to help. In the mean time I will keep an eye on this forum.


DAVE


----------



## daviedavo

Just to clarify my last post - I forgot to add:


I did read that Eric had "fixed" the problem by rebooting the RDDNS server (or whatever he did) but I am still having the same problems almost daily. I have reconnected manually to RTV to get the programing guides but this did not seem to change anything . . . is there something I am missing or does the problem still exist?


Is anyone else still having rebooting problems or am I the only one left with the problem . . . maybe it is the hard drives on both of my machines after all . . .


DAVE


----------



## jweinel

Both of my 5040's seem to be operating normally now, on the network. Today was day 7 without a reboot for both, and they both experienced the weekly maintenance reboot.


----------



## bron

Mine seem to be working OK now, No reboots.


----------



## Mikeyboy




> Quote:
> Originally Posted by *daviedavo* /forum/post/12759479
> 
> 
> Just to clarify my last post - I forgot to add:
> 
> 
> I did read that Eric had "fixed" the problem by rebooting the RDDNS server (or whatever he did) but I am still having the same problems almost daily. I have reconnected manually to RTV to get the programing guides but this did not seem to change anything . . . is there something I am missing or does the problem still exist?
> 
> 
> Is anyone else still having rebooting problems or am I the only one left with the problem . . . maybe it is the hard drives on both of my machines after all . . .
> 
> 
> DAVE



Disconnect the ethernet cable from the 5000, then reboot the recorder. That way it will act as a single unit. If it still reboots during the day, the problem should be power related http://www.replaytvparts.com/5000or5...rproblems.html or the hard drive may be failing.


----------



## tlgs333

Anyone else having the trouble?


One of my two boxes is misbehaving. Could be unrelated. Anyone else experiencing it again?


...perhaps i am crazy...


P.S. It wasn't I who directly fixed the problem, I was the one who convinced a replay tech support person to look into it.


----------



## Mike Cornwell

My 3 have been as stable as they can be with 100-150 shows on them. Definitely better after Replay kicked their server.


----------



## RileySmith

Well, my 411 zones seems to be working okay now. And still no reboots, except the manual one I did last night for the problem I stated earlier in a post.


----------



## denyart

Mine 5060 crashed 3 (or more) times yesterday.


I unhooked the network (again) and it hasn't crashed since.


----------



## Space

6 days 14 hours with no reboots, looks good. Thanks all!


----------



## gizmo91

My boxes have been stable for 6 days also ---- looks like problem solved (for now)


----------



## amdbme

My previously solid 5040 has been constantly rebooting since late November/early December. I wish I had read this thread earlier as I thought like most of you it was just my machine going bad. It started a couple of days ago sticking at a pixelized screen until I would force a soft reboot. As of last night on one of the reboots it just stopped at the "Please Wait" screen and it won't get past it. I did all of the unplugging tests and then finally opened my unaltered box (no biggie - always wanted to put a bigger drive in it).


When I saw that I was not alone and changing my hard drive likely wouldn't work since it is not broken and my fan is working I called the Replay techs. "Steven" said they know nothing of this problem and I could send my unit in for repair for the bargain basement price of $129. I asked for Tier 2 escalation (apparently today's name is "Carl") but he is unavailable. Tripped Steven up when I offered to send him a copy of this thread and he said not necessary as he knew which one I was speaking of. I asked to be contacted by Carl and let them know that if they have a problem that is eventually breaking people's Replays, the right thing to do is replace them while keeping their original lifetime subscription intact.


Anyone have any other suggestions? Anyone else have their Replays hanging after reboots now? I have a 5040 and 5500xx both bridged wirelessly from Buffalo Router. I use Poopli and IVS but have never figured out WIRnS and I already know I should have my head examined for it (least of the reasons).


----------



## hdonzis




> Quote:
> Originally Posted by *amdbme* /forum/post/12784667
> 
> 
> My previously solid 5040 has been constantly rebooting since late November/early December. I wish I had read this thread earlier as I thought like most of you it was just my machine going bad. It started a couple of days ago sticking at a pixelized screen until I would force a soft reboot. As of last night on one of the reboots it just stopped at the "Please Wait" screen and it won't get past it. I did all of the unplugging tests and then finally opened my unaltered box (no biggie - always wanted to put a bigger drive in it).
> 
> 
> When I saw that I was not alone and changing my hard drive likely wouldn't work since it is not broken and my fan is working I called the Replay techs. "Steven" said they know nothing of this problem and I could send my unit in for repair for the bargain basement price of $129. I asked for Tier 2 escalation (apparently today's name is "Carl") but he is unavailable. Tripped Steven up when I offered to send him a copy of this thread and he said not necessary as he knew which one I was speaking of. I asked to be contacted by Carl and let them know that if they have a problem that is eventually breaking people's Replays, the right thing to do is replace them while keeping their original lifetime subscription intact.
> 
> 
> Anyone have any other suggestions? Anyone else have their Replays hanging after reboots now? I have a 5040 and 5500xx both bridged wirelessly from Buffalo Router. I use Poopli and IVS but have never figured out WIRnS and I already know I should have my head examined for it (least of the reasons).



Your problems are clearly hard drive related and not the problem DNNA was having. The problem DNNA was having causes reboots when the machine is operating. If you can't get past the "Please Wait..." screen, then the problem is solely with your hard drive. Here are step-by-step instructions for helping you out. You will see in the links that stuck in the "Please Wait..." screen is a problem with the hard drive...


Henry


----------



## tlgs333

Hey, Denyart - how is your network hooked into your replay? DHCP or static? Are you experiencing any other issues? It may not be the original problem happening to you.


amdbme - your problem is almost guaranteed to be your hard drive. The tricky part will be getting an image to put onto a new drive - but totally doable from the links provided.


To everyone else: My boxes are up for 1 and 3 days - i'm just not satisfied yet. I have been messing with my network, so perhaps it was all my fault. We'll see!


Eric


----------



## amdbme

My problem _now_ is hard drive related - my issue is that there were never any problems until the reset issue started a little over a month ago. I found myself apologizing to guests over the holidays about my Replay resetting itself so often. It was happening about 3+ times/day when it had rarely ever happened before. Since my house was full for the month the Replay was being watched all the time so I know how often it was actually happening.


My issue with Replay is that my system was reset so many times that my otherwise no-problem hard drive has crashed. As with any aging computer, being suddenly shut down over and over in the middle of operation can lead to a host of problems. Instead of just admitting the issue, Replay reps are acting like they've never heard of this but are willing to let me pay them to have it fixed. I suspect others will end up like me sooner or later.


It is a bad analogy, but I am a Sr. Software Engineer at Motorola and I can assure you that if server issues we have cause our customers downtime problems, such as not getting their shipments out because our servers were down, we would be paying out the nose to make it up to them and keep their business. We wouldn't tell them we'll charge them to fix the issue.


----------



## hdonzis




> Quote:
> Originally Posted by *amdbme* /forum/post/12786621
> 
> 
> My problem _now_ is hard drive related - my issue is that there were never any problems until the reset issue started a little over a month ago. I found myself apologizing to guests over the holidays about my Replay resetting itself so often. It was happening about 3+ times/day when it had rarely ever happened before. Since my house was full for the month the Replay was being watched all the time so I know how often it was actually happening.
> 
> 
> My issue with Replay is that my system was reset so many times that my otherwise no-problem hard drive has crashed. As with any aging computer, being suddenly shut down over and over in the middle of operation can lead to a host of problems. Instead of just admitting the issue, Replay reps are acting like they've never heard of this but are willing to let me pay them to have it fixed. I suspect others will end up like me sooner or later.
> 
> 
> It is a bad analogy, but I am a Sr. Software Engineer at Motorola and I can assure you that if server issues we have cause our customers downtime problems, such as not getting their shipments out because our servers were down, we would be paying out the nose to make it up to them and keep their business. We wouldn't tell them we'll charge them to fix the issue.



If you feel strongly that it is just data corruption from rebooting and nothing physically wrong with the hard drive, then you can simply re-image your current hard drive and be on your way. But, I would highly recommend your at least running some hard drive diagnostics on your current hard drive first. A very simple test is to run RTVPatch to backup your system partition. That will tell you if it has any problems reading the operating system part of your hard drive (they part that is keeping it from booting).


Or, you can just take the opportunity to increase your Replay's storage capacity and replace the hard drive...


Henry


----------



## adone36

"Sticking at a pixellated screen" is not the problem in question, but it is an indicator of drive failure. And reboots will not cause physical damage to the drive. Your drive will most likely fail the mfg diagnostic for it.


Try as I can, I can't remember when Motorola has ever offered to "reimburse me" over the years for their various failed equipment or services on their end, never mind when it wasn't their fault to begin with.


----------



## Mike Cornwell

Just noticed that one of my three 5040's missed its weekly reboot, and is at 9+ days, and another is past 10 days. A far cry from the 1-3 reboots I was having.


----------



## amdbme

Improper shutdowns, spontaneous resets, and power failures are all well known causes of data corruption and, in turn, drive failures which is what has happened to mine. I don't mind as much since I had always wanted to replace the hard drive anyway, but my point was that most end users are not tech savvy enough to find threads on forums much less swap hard drives, etc. Replay playing the ignorance card and using the situation to milk more money out of their clientele is atrocious customer service and shows their blatant disregard for us.


That said - I knew the Moto reference would draw fire - I meant customer as carrier (Sprint, Verizon, etc) compared to consumer as end user. Several years ago when Moto realized there was an issue with the GPS trigger in a phone that had just been shipped, management dictated that we do whatever it took to make it right for the end user at our expense. Another good example is when the XBox server went down over the holiday and subscribers couldn't get in. Instead of brushing it under the rug, Microsoft is offering a free game of choice to affected customers. This is how corporate America SHOULD respond - openly, honestly, and with keeping customers long term in mind.


In the case of Replay, the consumer is the direct customer. If I was the first person in this thread saying the Replay Tech said they never heard of the issue I would give them the benefit of the doubt. Instead, others mention Replay saying they haven't heard of it and even that the one tech that did admit to it no longer being employed there within a few days. With DTV now owning the assets, Replay has much deeper pockets to make things right. Unless you work for Replay we should not be attacking each other, rather standing united in letting them know we will not be ignored.


----------



## adone36




> Quote:
> Originally Posted by *amdbme* /forum/post/12787604
> 
> 
> Replay playing the ignorance card and using the situation to milk more money out of their clientele is atrocious customer service and shows their blatant disregard for us.



You called with a bad drive and were quoted the replacement fee.


Those of us who know what we're talking about will stand united. The rest will be ignored.


----------



## hdonzis




> Quote:
> Originally Posted by *amdbme* /forum/post/12787604
> 
> 
> Improper shutdowns, spontaneous resets, and power failures are all well known causes of data corruption and, in turn, drive failures which is what has happened to mine.



Spontaneous reboots might cause data corruption, but they can't cause drive failures. A reboot doesn't even cause the drive to spin down and back up. So, it might be possible to blame data corruption on the problem they were having, but certainly not a drive failure. You probably were starting to have the signs of a drive failure and the rebooting problem just brought it more to light...


Henry


----------



## amdbme




> Quote:
> Originally Posted by *adone36* /forum/post/12788896
> 
> 
> You called with a bad drive and were quoted the replacement fee.
> 
> 
> Those of us who know what we're talking about will stand united. The rest will be ignored.



Unless you are the person "Steven" that took my tech support call how would you know what I called about? I called because I realized the issue was larger than just my system and now that my system was completely shut down I wanted to know what Replay was doing to support the issue.


Your post spoke volumes, though. I know that techies don't tend to be "big picture" people but consider this business case everyone. You have a product that has mostly lived out its lifespan. Most remaining customers have purchased a lifetime subscription so you are no longer generating revenue. Intentional or not, you suddenly have a system problem that generates you $129 per phone call in support revenue. You quickly tell your tech support team to admit to no knowledge of the fact and offer the fix. Suddenly a new, lucrative avenue opens up to you. Wake up, people, cause apparently the ones who know what they are talking about will ignore the rest of us in favor of periodically generating new little issues. If we don't let them know this is not acceptable now, it will just keep happening.


I think, to be fair, Replay should post their service #'s for the last six months (and I don't mean some bogus spreadsheet). If there was a spike in units sent in recently, I rest my case.


Let me assure you, as the only female in my position, I did not get there by going quietly into the night. So, no, Tony/Steven/Carl (whatever your name is), I will not be ignored. I will do my best to stand up for everyone that doesn't know any better and demand that you back up your product for all of us.


----------



## hdonzis




> Quote:
> Originally Posted by *amdbme* /forum/post/12789046
> 
> 
> You have a product that has mostly lived out its lifespan. Most remaining customers have purchased a lifetime subscription so you are no longer generating revenue. Intentional or not, you suddenly have a system problem that generates you $129 per phone call in support revenue. You quickly tell your tech support team to admit to no knowledge of the fact and offer the fix. Suddenly a new, lucrative avenue opens up to you.



That is quite a leap to think that once they found about a problem that they intentionally turned it into a money making opportunity!










I don't know how much you've dealt with their Support previously, but as is common with most mature products, their basic support is to repair broken units with the stash of parts that they have in Waco. It really isn't that atypical to get a Support person answering the call that hears what they want to hear, or finds the closest thing they can find on their check list. I doubt that their check list includes checking the internal RDDNS server, much less being able to figure out from your description of a random reboot problem that the problem is with their internal RDDNS server. A problem call of random reboots would sound to any tech following his checklist like a hard drive problem. Their staffing is quite transitory, now, and I could certainly see where their whole Support team might not be aware that there was an internal problem. I'm not going to excuse the fact that they treated you that way, but it's pretty typical...


Henry


----------



## Lark888

I have one replay that will randomly reboot. In my case, I can see that it is temperature related. The replay is in a small TV stand with a glass door - it is the only electronic item inside that section. The back is open to the air. If I close the door, it will start to randomly reboot within a day or so, and reboot on a regular basis when watching shows. When I open the door, it will not reboot.


I had an older unit that was also temperature sensitive and got worst over time. Eventually, even with additional fan cooling, it would not run well and I replaced the unit.


Some of the random reboots may be due to decreased cooling - dirty fans, dust on the chips. Then again, it may just be a DTV conspiracy.


----------



## denyart

tlgsss-

my replaytv 5060 is connected with a static ip address AND a static ip address reservation on my router/DHCP server. Honestly, nothing has changed on my configuration except hard drive size since day 1.


I thought maybe the problem was reappearing, bu there is one small observation I have. Since the original drive (which was an 80GB drive) I have been unable to have more than ~150 hours (at standard quality) on my Replay without regular crashes.


I am in the process of taking my Replay out of service for me, and just having it serve my wife and kids, and maybe not even that if this keeps up.


PS-I hooked it back up to my network today, after 3 days up time offline. Lets see how it goes.


----------



## denyart

Rebooted here unexpectedly about 4 hours after being reconnected to the network. Currently unhooked. Going to remove some shows and try again tomorrow.


----------



## Murphy

If there are problems with your network that prevent a timely RDDNS response, you could potentially see reboots like the broken RDDNS server was causing.


----------



## RileySmith

Just an update, today at 5:50 my replaytv rebooted while recording a show. Don't know if this has anything to do with it but it had been sitting on the watch another recorded show or delete this show for about 30 minutes while we went to get something to eat. when we got home I selected delete the show and then preceded to delete 3 other old shows and on the third delete selection the replaytv rebooted. and when it came back up it continued the recording of the show it had been recording, just like the old problem. don't know if it's back or not, I'm sure if it is we'll hear about it here. the unit had been stable for several days.

Riley


----------



## denyart

Well, I put mine back on the network a couple of days ago and did a manual update, still up 2-3 days later. 411-zones has it at ~7 days uptime.


I will post again, if it seems to be back but it seems good for now. *Note: I did NOTHING except reconnected it to the network and did a manual connection, no network changes*


----------



## BaysideBas

The problem may not have been completely solved. Last Thursday's Without a Trace recorded in two parts due to an unplanned reboot. Otherwise the units have been behaving.


----------



## Leo the 3rd

Mines (ReplayTV 5040) been doing random rebooting and repeated stuttering. Even after replacing the old 40GB HDD with a larger 500GB HDD. No luck. This is the wife's main recording source. Guess I got a good 7+ years out of my unit. Looking to pick up a DVR from Tivo tomorrow.


----------



## adone36

The drive is either bad or incompatible.


----------



## emmarie




> Quote:
> Originally Posted by *Leo the 3rd* /forum/post/12890103
> 
> 
> Mines (ReplayTV 5040) been doing random rebooting and repeated stuttering. Even after replacing the old 40GB HDD with a larger 500GB HDD. No luck. This is the wife's main recording source. Guess I got a good 7+ years out of my unit. Looking to pick up a DVR from Tivo tomorrow.



Leo, how long have you had the 500gb drive in the machine? Is it a new upgrade? What are the specifics of the drive you installed? When I went looking, in the last year for a 500gb drive, I mistakenly thought that if I stuck to the old standards of 5400/7200 with 8mb cache and stayed away from the 16mb cache drives and stuck with my preference of Seagate drives I'd be okay. I couldn't find a 500gb drive in my price range that fit the bill, but I found a 400. So I bought the 400 and set the whole thing up, only to have it continuously reboot. When I did the homework I should have done previously, I found that the drive I bought was indeed incompatible. I found a smaller drive that worked and added the 400gig to my DVArchive. There's a thread around here where people started posting their experiences with all the newly incompatible drives, I'm sure someone can post a link. Don't give up so soon.


-em


----------



## BaysideBas




> Quote:
> Originally Posted by *Leo the 3rd* /forum/post/12890103
> 
> 
> Mines (ReplayTV 5040) been doing random rebooting and repeated stuttering. Even after replacing the old 40GB HDD with a larger 500GB HDD. No luck. This is the wife's main recording source. Guess I got a good 7+ years out of my unit. Looking to pick up a DVR from Tivo tomorrow.



In my experience, going beyond 200GB capacity is asking for trouble. At 300GB I'm getting unsatisfactory performance, not a showstopper, but annoying delays nevertheless.


----------



## adone36

All my units have 300s. I use medium and might have a hundred shows on each. In cycling through the network, they update in a half second or so. I have to laugh when these people say to move a billion shows to DVA. The Replays with a 100 shows update in half a second, DVA has 10-20 shows and "hangs" for 5 seconds.


----------



## lt123

My unit has been working fine since removing it from the network. I just plug it in and manually do an update every night.


When its plugged back in for an extended period (I did a test of 3 days) I'm back to reboots and split recordings. So for me, at least, its not a hard drive issue but a network issue.


----------



## adam1991

The past week or so I've gotten several half recordings. Not split. The show just stops recording in the middle and never picks back up. I don't know if it's rebooting or not.


----------



## Murphy




> Quote:
> Originally Posted by *adam1991* /forum/post/12917114
> 
> 
> The past week or so I've gotten several half recordings. Not split. The show just stops recording in the middle and never picks back up. I don't know if it's rebooting or not.



411 zones will tell you how long it's been since the last reboot. It should not be more than 7 days.


----------



## Ruiner

My stock HDD 5040 has been rebooting with increasing frequency.

I've manually forced updates but have not unplugged from the network or done diagnostics on the HDD (the likely culprit and due for an upgrade).

I did recently clean the dust out, but forgot to check/tighten the mobo screws.


----------



## grapeshot

I just found this thread. I started having this problem a couple of months ago. Random reboots, and occasional shows being recorded in two segments. I've got one 5040. It's all original equipment. I don't do IVS, and only run DVArchive when I want to shift something to one of my computers. I thought my drive had gone toes up, and I was starting to look around for some "life after Replay" options. Just this afternoon I was watching a recording and it rebooted in the middle. Very annoying. And my 411-zones screen only blips on for a second so the only evidence I have for this is the occasional reboot while I'm watching or the 2-segment recording.


I'm of the opinion if this continues, my love affair with my Replay is going to dwindle in short order. It'll be time for the next generation DVR -- whatever that is.


----------



## jesup

Seriously - try clearing the guide data. I was having this problem recently, and was worried the hardware was becoming unstable, but clearing the guide data basically made the problem disappear (went from 1-4 reboots/night to maybe 1 (non-scheduled) in 4 weeks). The code is XXX-Zones (can't remember the digits; it's here somewhere).


----------



## rm -rf *.*




> Quote:
> Originally Posted by *jesup* /forum/post/13067524
> 
> 
> Seriously - try clearing the guide data. I was having this problem recently, and was worried the hardware was becoming unstable, but clearing the guide data basically made the problem disappear (went from 1-4 reboots/night to maybe 1 (non-scheduled) in 4 weeks). The code is XXX-Zones (can't remember the digits; it's here somewhere).



243-ZONES

Clear Channel Guide

(replaytv will reboot)

243-ZONES

Clear Channel Guide

(replaytv will reboot)


Yes, you should do it twice - second one is to clear the backup guide (supposedly).


----------



## hdonzis

I had two reboots on only one of my Replays during last week. One was on Wednesday morning and the other was on Friday morning (an hour later than the Wednesday reboot). Both resulted in segmented recordings. I have gone back to proxying my IVS updates through WiRNS...


Henry


----------



## Art Doyle




> Quote:
> Originally Posted by *mikekamerman* /forum/post/12531753
> 
> 
> My replay 5040 has been exhibiting some strange actions as of late.
> 
> Every 2 or 3 days, the replay will reboot for no apparent reason.
> 
> Today we were watching a recorded show while the replay was recording
> 
> another live show. all of a sudden, screen goes blank and I get the
> 
> "please wait" page indicating a reboot. after several minutes, the show that was previously being recorded starts recording again (2nd segment in recorded show list), and I am able to go back and watch the previously recorded program. Pretty anoying...we lose about 5 minutes of the show being recorded.
> 
> Any logical reason for this? An suggested fixes...
> 
> 
> Thanks
> 
> Mike Kamerman



All Replays do this when the drive is going marginal. You can gain some additional service life by using a product such as Gibson's Spin Rite, but the fundamental problem still remains - a failing drive. When your Replay starts compensating for the marginal drive, it's average CPU usage eventually trips a watchdog timer - forcing a reboot. This is the same strategy used by most of Nasa's deep space vehicles (Vxworks platform). It works - even under "provocation" from your bad drive.


Google did the only real drive reliability research (100K drives), and even they came away scratching their heads. Their solution involved replacing the drive at earliest indication of failure.


Have no proof (yet).....but we no longer use Maxtor drives. Our Replays equipped with the older Seagates have been rock solid so far. While most mean time between failure data is suspect (no standards), Seagate claims 60+ years on the model we're currently using. I'll be happy with 2 years










PVRS are drive killers. Changing your drive is a worthy experiment and will likely make you a believer.


----------



## JeepGeek

Just to add my own 2 cents...


A couple of months ago my 5080 started rebooting a lot as well. It got most annoying when I was trying to go through and remove channels from the guide, but it was rebooting a lot while recording shows as well. My first thought was a bad drive and I started getting ready to buy and image a replacement. But on a whim I thought it might be heat-related too (it's in some semi-enclosed shelving and gets quite dusty in the back). I pulled it out, vacuumed out the vents, and the problem seems to have stopped... or at least, it's not rebooting while recording anymore.


I did noticed that I accidentally dislodged the network cable while vacuuming it as well -- it was unplugged for about a week before I noticed that the guide hadn't been updated. So whether that had anything to do with fixing it, I don't know.


----------



## hdonzis




> Quote:
> Originally Posted by *JeepGeek* /forum/post/13159615
> 
> 
> Just to add my own 2 cents...
> 
> 
> A couple of months ago my 5080 started rebooting a lot as well. It got most annoying when I was trying to go through and remove channels from the guide, but it was rebooting a lot while recording shows as well. My first thought was a bad drive and I started getting ready to buy and image a replacement. But on a whim I thought it might be heat-related too (it's in some semi-enclosed shelving and gets quite dusty in the back). I pulled it out, vacuumed out the vents, and the problem seems to have stopped... or at least, it's not rebooting while recording anymore.
> 
> 
> I did noticed that I accidentally dislodged the network cable while vacuuming it as well -- it was unplugged for about a week before I noticed that the guide hadn't been updated. So whether that had anything to do with fixing it, I don't know.



That's a good idea. That Replay rebooted again yesterday night, even after I changed my router to have RDDNS proxy through WiRNS instead. Since it's the only one of my four Replays rebooting, and that it still did it after changing the RDDNS proxy, it's also the only one in an entertainment center, so I think I'll try cleaning things out...


Henry


----------



## g501

I am still having reboot problems, typically a few in a row. Like the other posters, it's only when my

network cable is connected and it only started a couple of months ago.


Looking via the ptvio serial shell, it happens after the Replay runs a process called

UpdateChannelIndeces [sic]. The shell hangs shortly afterwards, and then I think a watchdog

timer kicks in and reboots it.


----------



## g501

I am pretty much certain my reboots occur within a few seconds of a HTTP call to

64.124.73.123/rd/servlet/ul?q=(LONG ENCODED VERSION OF MY IP)

This was repeatable.

I blocked it in my router using

iptables -t nat -A prerouting_rule -d 64.124.73.123 -j DROP

iptables -A FORWARD -j DROP -d 64.124.73.123

and the problems stopped. This could be more elegant, but it gets the job done for me.


----------



## hdonzis

Just a little update. I noticed that Replay stopped recording and I found out that the Replay guide was out of show information. So, I cleared the channel guide and downloaded the guide and things seemed to get better. However, I noticed that my show-based recordings were still showing hearts since the 14th instead of going back to circles. So, today I went into the CFP and re-entered the hearts phrase and my show-based recordings went back to circles. This is the only Replay I have with Valentine hearts showing (because I showed my wife) and I showed her again this year on the 14th. I don't know if it is possible that Easter Egg caused some other kind of problem or if it is just a big coincidence. But, things seem to be back to normal now...


Henry


----------



## hdonzis




> Quote:
> Originally Posted by *g501* /forum/post/13204157
> 
> 
> I am pretty much certain my reboots occur within a few seconds of a HTTP call to
> 
> 64.124.73.123/rd/servlet/ul?q=(LONG ENCODED VERSION OF MY IP)
> 
> This was repeatable.
> 
> I blocked it in my router using
> 
> iptables -t nat -A prerouting_rule -d 64.124.73.123 -j DROP
> 
> iptables -A FORWARD -j DROP -d 64.124.73.123
> 
> and the problems stopped. This could be more elegant, but it gets the job done for me.



That's the RDDNS update, which was supposedly fixed awhile back. If you read back a couple of pages, you'll see that several people were blocking that request in different ways for their router. But, supposedly it isn't necessary any longer...


Henry


----------



## g501

Several people thought they were still having the reboot problem in Feb. I was saying I confirmed it was still happening, and that the RDDNS for definitely the problem, and that this was yet another way to fix it (which did not involve unplugging the network cable).


----------



## mschmitt

Like most everyone else, I had an immediate improvement when they fixed RDDNS at the backend in January.


But in the last couple of weeks, I've experienced a resurgence of spontaneous reboots.


So a week ago I changed my ReplayTV to use the backup RDDNS servers. Since then there has been zero problems.


----------



## adam1991

I second the resurgence of reboots.


----------



## yodathedog

Just found this site and this forum. I had a problem with one 5000 series machine which would not download the channel guide. It hadn't done this since mid Jan. I had tried rebooting several times, disconnecting the power, and manually dl'ing from the menu. I used the info from this forum (243ReplayZones) to manually download the channel guide and finally it worked. I haven't had any of the rebooting problems most of you have experienced on either of my RTV's. I was beginning to think the HD was about to crash. I could watch live and recorded shows and change channels, just no guide. Now everything seems to be back to normal (mentally crossing fingers). I am hooked to a home network and could not use the modem to connect as it was damaged by an electrical storm a couple years ago. I also got several messages after all this was done that the channels I had set to record were no longer available, so I've deleted and reset them. Time will tell if all is well.


I also was not aware of DirectTV's acquisition of the Replay service. Don't really know what this means except that I still can't use the Replays to connect to DirectTV service. I plan to upgrade my DirectTV service to HD service when they stop charging $200 for the HD DVRs and will only use the Replays as backups on cable.


Thanks for the info. I'm glad to be able to use both machines again and will continue to watch here for more info.


----------



## adone36

Replay 5Ks work fine with DirecTV and can control the box serially.


----------



## nobbie

Well, I've just noticed this issue crop up. And it happens when I'm on the channel guide trying to navigate up with either the arrow or channel up key. I had another 5000 series that had not been hooked up since last August and it exhibited reboots when I tried to delete a bunch of channels I don't receive.


It also froze when I had paused a show that I was watching, decided to record, and came back to. Had to do a hard reset.


If two units are exhibiting this, it's not the units, right? I'll dig through the thread, but if someone has a quick answer and solution, I'd be much obliged!


----------



## adone36

There has been an issue with a range of Direct channels having guide info that causes a Replay to crash, probably due to invalid characters (for the Replay) being used. There is a thread somewhere about how to find/remove these 1 or 2 channels from the guide.


----------



## johnnyray

My 5040 with lifetime has been working okay all these years but I have replaced the hard drive twice and then after the last time, this rebooting problem seems to have occurred. I usually don't see it, I only find out later when I see two or more attempts to record a show in the list due to the unit hanging up and rebooting during the recording. I say "hanging up" because I have also noticed that it will sometimes get into a skipping/repeating loop at some point in the show and will stay stuck like that until it resets itself or it is manually restarted. I know it could be the hard drive, but I can't believe a brand new 120GB drive that I JUST put in would already be bad and it doesn't do it often enough to take the whole thing out of my crowded AV unit and open it up again and do the who reimaging process on yet another drive. Yet.


----------



## emmarie

You don't say what brand or model of drive you put in. It sounds like an incompatible drive - probably not "another" bad drive.


-em



> Quote:
> Originally Posted by *johnnyray* /forum/post/15512077
> 
> 
> My 5040 with lifetime has been working okay all these years but I have replaced the hard drive twice and then after the last time, this rebooting problem seems to have occurred. I usually don't see it, I only find out later when I see two or more attempts to record a show in the list due to the unit hanging up and rebooting during the recording. I say "hanging up" because I have also noticed that it will sometimes get into a skipping/repeating loop at some point in the show and will stay stuck like that until it resets itself or it is manually restarted. I know it could be the hard drive, but I can't believe a brand new 120GB drive that I JUST put in would already be bad and it doesn't do it often enough to take the whole thing out of my crowded AV unit and open it up again and do the who reimaging process on yet another drive. Yet.


----------



## johnnyray

Ah, I see. Well the current one is a


Maxtor DiamondMax 21

200MB

8MB buffer

Ultra ATA/100

7200 RPM

KIT: L01V200


The previous drive was a

Maxtor DiamondMax Plus 9

160GB

ATA/133

YAR41BW0

(can't remember the buffer or rpm as I don't have the box any longer and I can't see that info on the drive itself)


Maybe Maxtor drives only work _sometimes_ in a ReplayTV?


----------



## Ruiner

There are models of HDD designed specifically for DVR use. Try one of those.


----------



## ericabbiss

I read the FAQs, really I did. But my two questions did not seem to be there. Hopefully, someone on this Forum can help.


Here are my questions:


1) I have two replays, a 5040 and a 5080, I modified both to 300GB capacity using RTVPatch. The 5080 unit, about 10% of the time when a show begins to record, only 3 to 7 minutes will record, then the machine will spontaneously reboot. After the machine reboots it will resume recording the rest of the show, all the way to completion. However, several minutes at the start of the show are lost and not recorded due to this reboot, and the recorded show appears as two segments. This is the only one of my two replay 50xx units do this.


2) Using DVArchive I transfer shows to my PC for eventual archiving to DVD. Although I have a Quad core PC with maximum readable 3.2GB Ram (using Win XP 32 bit) and fast 3TB SATA drive capacity, shows download in real time through my 10/100 wired network. Shouldn't the shows download quicker that 1:1?


Thanks in advance for any help you may provide!


Eric


----------



## hdonzis

Your problem description sounds like what happens when you network ReplayTVs and have more than a hundred shows stored on a remote Replay. Does the problem happen when you are recording a show and you view the remote Replay guide and then the local ReplayTV reboots? If so, you either need to be REALLY careful about viewing the remote guide while the local ReplayTV is recording or try to keep your Replays with a hundred shows or less stored on them...


DVArchive tries not to tax the Replay any more than another Replay would. However, you can adjust the download parameters at your own risk...


Henry


----------



## ericabbiss

hdonzis,


I don't think I have anywhere near 100 recorded shows total on both of my replays combined. The only real difference between the two machines is that one was born as a 5040 (the one with the reboot issue), and the other was born as a 5080. The other difference is that the default record mode for the 5040 is Medium quality, while the default for the 5080 is High Quality. I don't think we are accessing the guild at all when the spontaneous reboots occur.


On the issue of transfer speed, I found that I could right click on the individual replay from DVArchive and double the transfer speed, and run two transfers at a time. This seems to have solved my speed problem. There is one thing though, there seems to be a memory monitor on the bottom edge of DVArchive that seems to report very low at a max of 64. Is this a changeable parameter? Will that improve performance?


Thanks,


Eric


----------



## hdonzis

Well, since this discussion is going on in two threads now, I can only add to Ed's comment that I had a hard drive, a WD2500JB, which everyone claims is completely compatible with lots of people using it, which does the exact same thing in every Replay I have put it in. I even think I wrote a thread about on somewhere. At first I thought it was the Replay, but I tried it in at least three different Replays and they all did the same thing. Then I thought it was something going on the network at the same time, but I had it happen when I was absolutely sure there was no other network traffic. So, I just have say that it was something with that particular drive. You might try a different drive and see what happens...


Henry


*UPDATE* I just went back and read my old thread and see that the problem I was having was that the RTV would hang, not reboot. Now, that doesn't mean that in your case that it is still the drive causing the reboot. So, I would still recommend trying a different hard drive...


----------



## ericabbiss

Henry,


If the potential solution it to change the drive for a new one, I would of course increase the capacity. 1TB drives are very affordable now. Will the replay motherboard and I presume its RAM recognize such a large drive? Any recommendations?


Thanks for all your help,


Eric


----------



## hdonzis

The hardware doesn't have a limitation with the hard drive size. However, as I stated previously, being able to store lots of shows will cause problems, so a large hard drive isn't very worthwhile...


In addition, I don't think that you will find any compatible hard drives anywhere near that capacity. I noticed that you never answered Ed's question about what model hard drive you installed. You said that it was a Seagate 300GB 8MB cache, but you didn't post the model number. It's certainly possible that the drive you are currently using is a known problem, but we need the model number...


You can look at some of the compatibility threads that you can find in this forum. I think you will find that the largest compatible new drives you can currently find are 160GB. But, at this point, you are just trying to make sure it is the drive that is causing the problem...


Henry


----------



## Helvis

Like the others, I think it could be an incompatible hard drive or the memory issue with the networked replays. I'm pretty sure that having lots of shows set to record will also cause an issue and not just having them actually recorded. So if your list of recordings and shows to be recorded gets too long it will make networked replays reboot when viewing the guide on another system. We have 5 replays networked and we have always had that problem. They just weren't built with enough ram to handle all that info. Most of our replays were upgraded to 120 gb drives several years ago but I dread having to replace them because it is a pain to find drives that are compatible. Even when others say they worked for them.


----------



## adone36

I have 5 units with 300 gig drives networked. Never had any issues of any kind with hundreds of shows recorded and dozens of Replay channels set up. No reboots, guide update issues, or instability.


----------



## ericabbiss

It took me awhile to dig up the paperwork for the type of Seagate 300GB HDs I used when upgrading my two replays. It appears that I used 7200.8 drives. The unit experiencing the spontaneous reboot issue has an ST3300631A 300GB, 7200RPM, 16MB cache. But, according to my records the other machine, the formerly 5080 is also now running the same model ST3300631A drive. Although they were purchased from Fry's in 5/2006 and 4/2007, respectively, that second one purchased cost less than half that of the first!


Much further back in this long thread it was suggested that clogged vents might be the cause of this issue, so I just vacuumed away the slight blockage that was there. I guess I see how it does for the next little while.


Thanks,


Eric


----------



## hdonzis

You can use 4-1-1-Zones to display your hard drive model numbers in addition to a lot of other information. You should verify that both hard drive model numbers are 6xxA with 16MB cache. It looks like the 7200.8 drive is compatible with both 16MB cache and 8MB cache, but it would be interesting of the working drive was a different model.


In addition to clearing the vent holes, you should consider rerouting the IDE ribbon cable over the top of the mother board so that it doesn't block the vent holes...


Henry


----------



## ericabbiss

I pressed numerals 4 1 1 then the Zones button, but all I got was the Zones menu. Is there a special sequence or hack I am not aware of?


----------



## cwpl

Could swap the drives to see if problem moves with drive.


----------



## cwpl




> Quote:
> Originally Posted by *ericabbiss* /forum/post/16781004
> 
> 
> I pressed numerals 4 1 1 then the Zones button, but all I got was the Zones menu. Is there a special sequence or hack I am not aware of?



You must not have pressed the zone button fast enough.


----------



## ericabbiss

AH HA!


Looks like Fry's may have struck again! Using the 4 1 1 Zones query (which must be employed as if one were entering a direct channel access number), returned the drive ID as a ST3300620A, not the 631A listed on the receipt. I always check Fry's packages for "boomerangs" but it looks like maybe I got one anyway. Is the 620A known to have issues such as this?


Eric


----------



## hdonzis




> Quote:
> Originally Posted by *ericabbiss* /forum/post/16781045
> 
> 
> the drive ID as a ST3300620A, not the 631A listed on the receipt. I always check Fry's packages for "boomerangs" but it looks like maybe I got one anyway. Is the 620A known to have issues such as this?



Yep, that model number is a 7200.10 drive, which is known to have problems. In addition, "upgrading" 7200.8 drives to 7200.10 drives is also a known problem of the time...


Henry


----------



## ericabbiss

Thanks Henry!


I will seek out a suitable replacement drive. If I can find one. This may also explain the periodic freezes which can only be cleared by a warm reboot.


Thanks,


Eric


----------



## hdonzis

I just want to point out that this is probably not the fault of Fry's. This was a common problem of Seagate upgrading the model of the drive contained within the packaging. So, if you still had the package for the drive, it probably says ST3300631A on the label on the box whereas it says ST3300620A on the label on the drive. At the time, the only way to tell for sure was to ask the retailer to open the box and check the sticker on the drive itself...


Anyway, there is a whole thread on the topic archived in here somewhere...


Henry


----------



## johnnyray




> Quote:
> Originally Posted by *Ruiner* /forum/post/15519480
> 
> 
> There are models of HDD designed specifically for DVR use. Try one of those.



Is there a list of specific models to look for? I'm still having this same problem of the ReplayTV trying multiple times to record a show and finding just a minute or two recorded in multiple recordings because of the constant reboots during a recording.


----------

