AVS Forum Archive 2 - Whats Going On???

ragu

11-23-04, 05:07 PM

Ok... I parchased a 5504 on 11/6, got it the following week, and it was Dead with 5 hours of use!!! I wrote about this else where here on this forum. I was told that I would get a replacement. That was 2 weeks ago, I still haven't been given an RMA, and when I call ReplayTV, I'm told that their busy shipping units for the holidays. Thats fine.... not really!!!
I purchased a second 5504 from their web site, got it last Friday, set it up, and just about all the features work. Just 1 little problem. I can't change channels!!!! I have a DTV box, Hughs, B2. If I try to set up a show to record, like AMC, 254, and set it. when I go back, the 5504 is on channel 2. There is nothing there.... on that channel. I am using the IR blaster that came with the 5504, I even switched it out with the one from my dead unit, that doesn't work. If I try to do a manual record, same thing, even if the channel is the same that I am watching. It just switches to 2.
I have gone thru setup, and used code, 0749 and 0749B. No change. I even went thru fine tuning..... NO GO.
I called ReplayTV tech support and was on the phone with them this past Friday nite for over 1 hour. They have no clue!!!! But I was told that, "it should work". They told me that they would get back to me.... Yea... the check is in the mail!!!!!
I have reset the unit, I have reset to factory default, one thing I noticed, if I go in and try to change the code, it is always back to 0749. No matter what code it put in for the Sat box.
What the hey can I do here???? 2 5504's, and I can't get 1 to work!!!!
By the way, I have done nothing to the units, right out of the box as is .... no software added to PC!!!! :-)
I just want to get up and running. Maybe I should go back to my home made PVR running SageTV.... At least I got my recordings!!!
Any idea's.... any way to get Replay to deal with these issues????
Do I need to go to the BBB and my bank and have the charges dropped and just go to the other product..... T@@@?????
Thanks for your thoughts on this one, and any help you might have.

ragu

11-23-04, 05:11 PM

One more thing.... when I first turn on the unit, or use my Sat Box remote to change channels, I see, "No video signal detected" message,
then the video come on!!!!

ClearToLand

11-23-04, 05:19 PM

[list=1] Calm down, take some deep breaths, and wait for one (or more) of the ReplayTV/Satellite gurus to reply. Once you get the proper code & wiring setup between the ReplayTVs and the Satellite Boxes, you'll be a happy camper.

Consider having ReplayTV replace 5504 #1 with a 5040 and connect that to your MAIN TV. You'll love CA, and shows recorded on 5504 #2 will have CA when played on the 5040.

Please expand on your description of DEAD regarding 5504 #1.

If you were making minimum wage, didn't have US citizenship, and your boss kept asking "How many new units did you sell today?", how much time would you spend troubleshooting someone's "already-paid-for" unit when you yourself were never taught how they operate?[/list=1]

Everything will eventually sort itself out - just be patient...

jackshakes

11-23-04, 05:25 PM

hey now ... no one says the T-word in this forum.

your issue with not changing channels is going to be a configuration issue with the IR blaster. I think you need to go into the setup menu, press 243 zones, and change the timing a bit. do some searching in this forum or wait for someone who knows to comment ... but i've heard people with the same problem here and it's always a timing issue.

And how do you have this wire up? I'm assuming coax from the wall to your digital box, then to the replay, and from the replay to the tv? provide some insight here.

can you change channels when watching "live" tv through the replay?

ragu

11-23-04, 06:05 PM

OK... the name is Glen. I'm a Network Administrator for a LARGE North American company.....
I have done the 243 zones change!!!! As I stated, I have done everything I have read about here, and been asked to do!!!! I changed the timing, till the cows come home!!!! Nothing.
Coax to DTV box, coax to replay, S-Video to Onkio 501,Onkio monitor out to TV and have put it to TV, right out of the Replay.
No... I can not change channels when watching "live tv", it just jumps to 1 or 2, channel that is.
Hell, I got my home made PVR working.... I thought this would be better!!!

dvasco

11-23-04, 06:26 PM

Glen, I am sorry to hear of your problem. Unfortunately I am not one of the experts. However, I am assuming you can't connect serially to the sat box. Maybe a sat box change with a serial connection will help. Once you do get the channel changing working you will like it a lot.

On a side note -
I am happy to hear ReplayTV is having good sales. I hope they get a lot of new and satisfied customers. This is supposed to be a good Christmas for retailers.

jackshakes

11-23-04, 06:26 PM

well howdya like that ... i too am a netadmin for a large gloabal company ... does your company have some pointy haired dimwit getting paid $200k a year to make bad decisions that you have to deal with also? or is that every company?

do you have svideo out on your cable box? you could try that to make sure it's not a coax issue.

just to verify if you change the channel with the sat box remote you will eventually see the picture correct? it just takes it a second to show up?

i'm assuming there's no serial control on the sat box?

I've never had to use IRBlaster so I'm afraid I can only be so helpful ... someone will chime in soon ...

elorimer

11-23-04, 06:33 PM

This probably won't be of much help since I don't have satellite. But I had a similar issue with channel changing when I didn't have the blaster correctly positioned over the eye on my cable box.

The blue screen with the no video signal message, then the picture appearing, is a normal thing for me while the cable box is changing channels.

ClearToLand

11-23-04, 06:53 PM

Originally posted by ragu: ...The name is Glen.

Hi Glen. :)

Originally posted by ragu: ...I'm a Network Administrator for a LARGE North American company...

Not a requirement for getting your ReplayTV to work. ;)

Originally posted by ragu: ...I have done the 243 zones change!!!! As I stated, I have done everything I have read about here, and been asked to do!!!! I changed the timing, till the cows come home!!!!

Too many exclamation points - you're not taking the recommended deep breaths. :rolleyes:

The SEARCH Function (although not the best implementation) does work.

Try: Hughes AND (0749 OR 0749)
Search entire posts
Show results as thread
Originally posted by ragu: ... I thought this would be better!!!

It *IS* better!!! You just haven't set it up correctly yet... ;) :p :o

P.S. Something I recall reading recently - move the IR Blaster a few inches away from the Satellite Receiver (Does the Hughes B2 have a "Low Speed Serial Data Port"?)

P.P.S. You still haven't explained DEAD regarding 5504 #1 :eek: [If it worked for 5 hours, it must be something YOU did!!! :D ]

ragu

11-23-04, 07:11 PM

well howdya like that ... i too am a netadmin for a large gloabal company ... does your company have some pointy haired dimwit getting paid $200k a year to make bad decisions that you have to deal with also? or is that every company?

Nope... we were told just 45 days ago that IBM was looking at taking over our support in all of North America. Happy Holidays!!! The company would save 26% by out sourcing.
No I don't have a serial port on my sat box. I have moved my IR every wich way but loose.
Unit #1, never boots! Turn it on and all I get is "please wait". never even gets to setup.
Back to the IR, I have it right over the eye of the sat. box. Where else can I move it?

adone36

11-23-04, 07:35 PM

RE: Unit 1

If you set up networking on a 5k and screw it up, it can take 20 min to boot. Unhook all cables (except the tv output.) Restart it and wait.

Replay 5K run best on a network with a DHCP server where the Replay is set to static and the DHCP server is set to RESERVE the static address to the Replay's mac address. The OS and Hdw can get different addresses at diff times otherwise. (didn't you post this problem in the newsgroup??)

Don't bother calling Replay. When DNNA took over, anyone who knew anything Replay was put against a wall and shot.

Search the archives for your Hughes Rcvr or start a thread for Blaster settings and maybe somebody can give you the code and delay settings.

I doubt either unit is bad.

jackshakes

11-23-04, 07:45 PM

um ... i think what you meant to say was set up a dhcp reservation for the replay and set the replay to dhcp ...

setting the replay to static and then the server to reserve is redundant ... the whole point of reserved IPs is so you get the benefits of a static without having to set the workstation up as static.

adone36

11-23-04, 07:53 PM

Uhhh, no I meant to say what I did. And also explained the reason why.

ragu

11-23-04, 07:59 PM

I have done both DHCP and static on unit #1, meaning, set my router to both use DHCP and not..... no go!!! just please wait.
network is wired, to Bay 28115 16 port switch, to D-link 707P revC, to a Motorola Surfboard cable modem.

Ace987

11-23-04, 08:03 PM

Well, I'm not sure how much help I can be, but what happens when you do this:

1) Set the input to whatever you have setup for the Satellite receiver (ie, Input 1, 2 or Coax). Go into setup then choose the input.

2) Manually enter a valid channel through the Satellite receiver.

3) Make sure the picture comes in.

4) Manually enter a valid channel via the Replay.

5) Tell me what you see. For example, do you actually see the numbers coming up?

tedkunich

11-23-04, 08:25 PM

Originally posted by ragu

Coax to DTV box, coax to replay, S-Video to Onkio 501,Onkio monitor out to TV and have put it to TV, right out of the Replay.
No... I can not change channels when watching "live tv", it just jumps to 1 or 2, channel that is.
Hell, I got my home made PVR working.... I thought this would be better!!!

Uh.... you cannot connect the replay to a sat box via the RF coax and expect the RF tuner to change channels! The replay will not send commands to ANY external box, be it cable or sat, if the selected video input is the internal tuner, ie COAX input.

You need to connect the video out (preferably the SVid) of your Sat box to a vid input (input #2 for Svid) on the replay, then need to configure that input to Sat box you are using, or one that shares similar codes.

T

Scallica

11-23-04, 10:31 PM

Originally posted by ragu
one thing I noticed, if I go in and try to change the code, it is always back to 0749. No matter what code it put in for the Sat box.
What the hey can I do here????

After changing the code, did you select "Keep all Changes"?

~Scallica~

jbacke

11-23-04, 11:19 PM

Originally posted by ragu
I have done both DHCP and static on unit #1, meaning, set my router to both use DHCP and not..... no go!!! just please wait.
network is wired, to Bay 28115 16 port switch, to D-link 707P revC, to a Motorola Surfboard cable modem. I don't believe you are a network administrator, unless you work for AOL. Too many exclamation points.

bleah.

No one will take you seriously.

Jeff D

11-24-04, 02:00 AM

I think ted is on to something here, but I'm really curious why he can enter an IR code with coax too? The coax is for RF tuner, and when sat box uses RF out it is on channel 3 or 4 only.

So... ragu, why no s-video or *gasp* composite out from the d* box to the replay? This is really what you should be doing.

On the first box... if it's always stuck at "Please Wait" how did you change the box to/from static/DHCP? I don't get that... But yes try the no cables connected except for the video output and boot. What happens then?

ragu

11-24-04, 06:30 AM

Hey jbacke, !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

I have a number of other things tied up with S-video, would love to use that. I guess I could try moving one of them to see if it works. With the coax hooked up, on the first unit, it worked ok, be it for just a few hours before the thing crashed and burned. My first unit isn't the issue here, the issue with the first unit is that I can't get ReplayTV to send the replacement. they issued an RMA on it. My main thing now is just to be able to get unit #2 to be able to change channels.
Setup:
5504
DTV box from Hughs B2
coax out of sat box to 5504
s-vid out to onkio 5000 series
S-Vid out of Onkio to TV(have change and used direct to tv, no change)
code 0749 on 5504, (if I try to change the code and save it, it never changes)
have reset to factory and started fresh 2 times, still the same results.
thanks guys for batting this one around.
PS, I can record, I just have select the channel, then use sat remote to change it back to the channel I want to record, quickly. At this point I can't setup furture recordings, due to this.

jackshakes

11-24-04, 08:52 AM

Originally posted by adone36
Uhhh, no I meant to say what I did. And also explained the reason why.

but that makes no sense ... I know what problem you're talking about ... the double IP issue where having your replay set to static it will sometimes also obtain a dynamic address and you'll essentually loose network communication to the replay ...

however, my point is setting the replay to static *and* making a dhcp reservation at the server is redundant.

The whole point of a reservation is to assign a given IP to a given mac address ... you then can let the client continue to make dhcp requests, and the server will always give it the same address. This solves the double IP issue ...

If you have a reservation set up, you certainly *can* also set the replay to static with the same IP ... and everything will work fine ... it just makes no sense. DHCP Reservations were invented so you could effectivly assign static IPs to workstations without having to configure the workstation to be static (i.e. so a laptop user could have the same address every time he's in the office, but then not have to reconfigure his IP settings every time he leaves and goes elsewhere)

adone36

11-24-04, 09:14 AM

Originally posted by jackshakes
however, my point is setting the replay to static *and* making a dhcp reservation at the server is redundant.

No, because even when set to static, the Replay will look for a DHCP server and if the lease time is expired can receive a different ip than the software setting.

Why do you think they call it a bug???

Software and hardware can wind up with different addresses. The fix makes this impossible.

jackshakes

11-24-04, 09:21 AM

are you reading what I'm saying? I'm not arguing that the bug doesn't exist ... i'm simply saying that if you're going to use a DHCP reservation you don't need to set the replay to static ... it's redundant!

Also ... technicality but there is no lease time with a static IP ... DHCP servers are unaware of static IPs on the network.

I don't mean to sound rude but it sounds like you need a better understanding of IP.

l8er

11-24-04, 09:36 AM

The long standing DHCP bug with ReplayTVs has two things working to produce it: as the ReplayTV boots up, there is an underlying OS (VxWorks?) as well as the ReplayTV software. In some situations, VxWorks will request a DHCP IP and the ReplayTV software will, later in the boot up process, also request an IP and they may not always end up with the same IP. What Tony has suggested avoids that as a potential problem.

And technically, DHCP servers do need to be aware of static IPs on the network, so as to not assign an IP that is already in use.

ClearToLand

11-24-04, 09:41 AM

Originally posted by jackshakes: ...i'm simply saying that if you're going to use a DHCP reservation you don't need to set the replay to static ... it's redundant!

You might benefit from SEARCHING for and reading some of the "old" messages from either sfhub and/or gduprey, IIRC. There are TWO entities lurking inside a ReplayTV - the ReplayTV application and the OS. Independently of one another, each wants an IP. When you set the application to STATIC, the OS is still DYNAMIC. If the DHCP Server assigned a different IP to the OS, problems begin...

Originally posted by jackshakes: ...technicality but there is no lease time with a static IP ... DHCP servers are unaware of static IPs on the network.

Apples and oranges - depending on how much time someone expends typing sometimes determines how well the thought gets communicated. :D Tony's explaing the bug, while you're explaining the difference between STATIC and DYNAMIC IPs...

Originally posted by jackshakes: ...I don't mean to sound rude but it sounds like you need a better understanding of IP.

See what you come up with AFTER you read some of the "old" descriptions of the bug... ;)

jackshakes

11-24-04, 09:54 AM

wow this is frustrating ...

l8er ... dhcp servers need to be aware of the range of static IPs on the network, but the server is not aware of what PC has a given static IP on an individual basis. adone used referred to a lease when talking about a static IP so I was simply pointint out the technicallity that there is no lease for a static ip.

cleartoland ... i understand the bug ... that's not the issue here.

in order to remedy the bug, adone was saying you should set your replay to static *AND* set up a reservation. my only point from the very start of all this was that is redundant. yes, it will work ... but it's redundant.

all that needs to be done to save yourself from the bug is to set up a dhcp reservation and leave the replay set to obtain an IP from DHCP. That way even if the IP is requested twice, it will be requested from the same MAC and will be given the same IP.

You don't need to set the replay to static in this situation ... you certainly can, and it will work ... but it's redundant.

am I just doing a piss poor job of explaining myself here?

l8er

11-24-04, 10:38 AM

Originally posted by jackshakes
That way even if the IP is requested twice, it will be requested from the same MAC and will be given the same IP. Gee....the bug that exists is that they won't always end up with the same IP. Duh. Perhaps you're not reading what we're writing?
Originally posted by jackshakes
am I just doing a piss poor job of explaining myself here? Apparently someone is. In a world where devices respond to DHCP requests as expected, there would be no need to assign a ReplayTV a static IP if an IP has been reserved for the device in the DHCP server. As we have tried to explain, the bug that exists can lead to VxWorks and the ReplayTV software both requesting and receiving an IP address (possibly two unique IP addresses) from the DHCP server.

As for a DHCP server and static IPs on a network ... I beg to differ. For example: you have a DHCP server set up to assign IPs from 192.168.0.1 through 192.168.0.100. You can assign a static IP address to a device on the network that falls within that range, for example 192.168.0.10. The DHCP server must be aware of the IPs in use (reserved or static) to avoid handing out a duplicate IP address (in this example, 192.168.0.10).

jackshakes

11-24-04, 10:49 AM

Originally posted by l8er
Gee....the bug that exists is that they won't always end up with the same IP. Duh. Perhaps you're not reading what we're writing?

oh for the love of all that is holy ... did *you* read what I said? I said if you set up a DHCP reservation you will get the same IP even if your replay requests one twice ... ALWAYS ... that's what a DHCP reservation is! Your replay will always request an IP using the same MAC address ...even if it requests it twice ... if a reservation exists ... the DHCP server will ALWAYS give the same address back ...

Originally posted by l8er
As for a DHCP server and static IPs on a network ... I beg to differ. For example: you have a DHCP server set up to assign IPs from 192.168.0.1 through 192.168.0.100. You can assign a static IP address to a device on the network that falls within that range, for example 192.168.0.10. The DHCP server must be aware of the IPs in use (reserved or static) to avoid handing out a duplicate IP address (in this example, 192.168.0.10). [/B]

i agree ... you certainly can assign a machine a static ip that falls within the dynamic range for the subnet ... however the DHCP server will never know this and it will eventually hand that address out to someone else. Now some dhcp servers will get word of the conflict, reassign the client it just gave the conflicting ip out, and mark that IP as used ... but not all dhcp servers can do this.

the fact is ... when your machine is set for a static IP, it NEVER communicates with the dhcp server (this is under normal circumstances ... we're not talking about the replay bug here) ... the only time a PC will talk to the dhcp server is 1. when it needs an IP, it will do a dhcp broadcast request, then reply to the offer it receives ... 2. when it's half way through it's lease it will request a new address ... 3. when the lease is over.

You guys are arguing with me about a point I was never making. I understand the bug and all it's issues ... my only point (this is like the 10th time I've said this) is setting up a DHCP reservation ALONE will stop the bug from ever showing up.

I'm just curious ... how many dhcp servers in a corporate environment have you guys administered?

l8er

11-24-04, 11:14 AM

Originally posted by jackshakes
setting up a DHCP reservation ALONE will stop the bug from ever showing up. You're missing the point here....NO IT WON'T! This is not a corporate network and a ReplayTV is not a PC running Windows or Linux. You can forget the rules you've learned setting up corporate networks. It's a bug dammit. Good gawd.

GTDaveMac

11-24-04, 12:02 PM

Yes it will! If you have a router that can do "static" DHCP for a specific MAC address, then you don't need to do anything else.

I don't so I use static and turned off DHCP.

jackshakes

11-24-04, 12:36 PM

ok l8er ... explain this to me ... when this bug causes the replay to request two IPs from a DHCP server ... does it send out the same MAC address when asking for the request?

i'm pretty sure it sends out the request form the same mac considering it is the hardware address burned into the NIC at the factory.

now ... even if the bug causes two requests to go out ... and they are for the SAME MAC address ... and if you have a reservation on the server ... you will ALWAYS get back the same address. This is not debatable ... it's how reservations work by definition.

the only way I could be wrong here is if the bug causes requests to be sent out from two different mac addresses.

if you insist that I am still wrong ... please ... by all means explain in detail how i am wrong. explain to me how a dhcp server with a reservation for a given mac will provide a different address for two requests that come in for that mac for which the reservation is defined. You keep telling me I'm wrong but I've given a lot more technical data to support my theory ... all you've said is "it's a bug so you're wrong" ... that doesn't change anything.

and no I can't forget the rules i've learned setting up corporate networks ... dhcp is dhcp no matter how big the network ... it all works the same. the bug in the replay doesn't cause dhcp to behave any differently. dhcp requests are handled by the server which is unaffected by this bug ... so dhcp will continue to handle the requests per the dhcp rules.

GTDaveMac ... thanks for chiming in ... I was wondering where all the network guys were ... they must be at the grocery fighting for the last of the turkeys.

marors1

11-24-04, 12:59 PM

ragu,

try taking the RCA output jacks from the back of the Hughes sat box and hooking them to input 1 on the back of the replay.

after doing this, set up the inputs of the replay so that the input 1 is set to Directv, and whatever appropriate IR code that you feel should work.

You may leave the output of the Replay on the coax out, but just set the replay up so that it knows what it's inputs and outputs are hooked to.

I believe that I had a similar problem with mine not displaying video once when I had my inputs and outputs on the replay screwed up.

I really think that you just can't hook the RF out from the sat box to the RF in on the replay, I do not think that you will get anywhere with that setup.

D

l8er

11-24-04, 01:00 PM

Originally posted by jackshakes
ok l8er ... explain this to me ... when this bug causes the replay to request two IPs from a DHCP server ... does it send out the same MAC address when asking for the request? I didn't write the OS or the ReplayTV software so I don't know what MAC address is getting sent. I do know there's a bug between VxWorks and the ReplayTV software and they can end up with different IP addresses if left strictly to DHCP under certain conditions. This may only occur with some particular routers and their handling of DHCP, but it can and does happen.

jackshakes

11-24-04, 01:12 PM

It seems you understand the bug well enough ... but not DHCP and how it can be used to thwart the bug.

you're leaving out the one key point that i'm arguing ... yes under regular dhcp circumstances the bug can screw you ... even more likely is when your replay is set for static and then VxWorks also gets a dhcp address ...

But I'm not talking about just DHCP here ... I'm talking about DHCP with a RESERVED address. leaving the replay strictly to dhcp is differnet than leaving the replay strictly to dhcp with a reservation.

but what you refuse to recognize is a DHCP Reservation solves the bug all together. I think how you're looking at it is a reservation reserves one IP (which it does) to be handed out to one machine (which it does) for one request (which it doesn't) so if two requests come in from the same nic it will give out another address (which it won't).

remember, Dynamic IP, Static IP, and Reservations are three different things.

If you have a DHCP reservation set up ... and the Replay Software asks for an address, the reserved address will be given to it by the dhcp server... if VxWorks then goes behind replay's back and asks for an address again ... as far as the DHCP server is concerned, it's the same device asking for an address again (because of the mac address) and will just give it the reserved address again ... not a different on ... not under any circumstances. this goes for *EVERY* dhcp server that supports reservations.

the bottom line is, dhcp servers identify clients by the MAC address alone. A reservation ties that MAC to an IP ... it doesn't matter how many requests come in from that MAC, it doesn't matter if they come from different software on the requesting PC ... all the DHCP server knows is a device with a MAC address that has a reservation is requesting an address ... so it will hand out the reserved address.

i hate to keep dragging this out ... i'd like to put it to bed and let this guy have his thread back ... but i refuse to back down when i'm being called an idiot for something that i'm not wrong about.

l8er

11-24-04, 01:51 PM

I fully understand how DHCP works as well as static, dynamic and reserved IP addressing. The ReplayTV bug can and does occur under certain circumstances with reserved DHCP IP addressing, which is contrary to how DHCP reserved addressing should work. That's why Tony's original suggestion gets around the bug entirely.

You want to argue how DHCP works and that I/we don't understand it ... I understand how DHCP works. What you don't seem to get is that VxWorks and/or the ReplayTV software apparently aren't playing by normal DHCP rules, or the bug would never occur in the first place.

jackshakes

11-24-04, 02:09 PM

ok but what i need you to do is explain to me HOW this bug occurs when using reserved addresses. technically how ... different macs? if you can't explain this, and unless you'v'e seen this bug happen in a reserved address environment personally, you can't claim to be any more right than I am.

every occurance i've heard of this bug on this board has been either in a static/dynamic environment or in a purely dynamic environment ... i've never heard anyone say first hand they've had this issue in a reserved environment.

aeblank

11-24-04, 02:13 PM

To put this to bed:

Quoted from Gerry Duprey :

---------------------------------------------------------------------------
The only two stable ReplayTV configs are:

1) all static, no DHCP
All devices have a static IP address and there is NO DHCP server running anywhere that would temp the ReplayTV.

2) All DHCP, with fixed MAC->DHCP mappings for ReplayTV.
In this config, you tell the router that for the ReplayTVs MAC address, always hand out the same address. This way, even when the ReplayTV goes schizo, both identities have the same address. Note: Not all routers/DHCP servers have this ability.

Anything else is subject to periodic failures. Sometimes it never fails and sometimes it'll never work properly unless you do one of the above. It's likely that if you run something other config, you'll experience something odd at some point (though that experience rate may be on the order of once a year or once a day).

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

l8er

11-24-04, 02:34 PM

Originally posted by jackshakes
unless you'v'e seen this bug happen in a reserved address environment personally I have and others have, not necessarily in this forum, that's how I know it exists and can happen.

sfhub

11-24-04, 02:42 PM

In the current Replay software, the OS will always perform a DHCP request
no matter what you have the Application configured to. The DHCP request
from the OS will have a different DHCP transaction ID from the one made
by the Application. The MAC address for both requests will be the same.

Regardless of whether you have MAC->IP address mappings, many DHCP
servers will not just blindly hand out an address. They usually first send
an ARP request to make sure the address isn't in use prior to handing it
out.

Since it is not common to encounter the Replay schizophrenic behavior
where the same unit/NIC makes two separate DHCP requests with
different DHCP transaction IDs and threads of execution, the code
path in the DHCP servers for these conditions may not have had the
most robust testing and it is possible certain DHCP servers are not
performing as you would expect. It is possible that the Replay behavior
causes the DHCP server to mistakenly think the address is already
being used, when in fact it should really be consulting the MAC to IP
address mappings before even considering whether the IP address
is in use.

*If* the DHCP server will truly only hand out the same IP address
regardless of how and what type of DHCP requests you throw at it
(as long as the MAC address matches what it has in its table) then
you can effectively get rid of the Replay DHCP problem by using
MAC->IP address mappings and configuring Replay for DHCP.

*However* if your DHCP server exhibits bugs or does not behave
well when encountering DHCP requests in the form Replay spits out,
you may need to manually avoid the 2nd set of DHCP transactions
by configuring your Replay for static IP. Examples of where things
could go wrong (all of which in my mind would be bugs in the DHCP
server) would be not handling the convoluted ARP replies which
Replay may give out regarding IP address usage or confusion over
2 DHCP transaction IDs from the same MAC address being interpreted
as 2 different units rather than one single unit.

DHCP server response to Replay's convoluted request pattern is
not a well tested area so it is hard to speak for every DHCP server
and whether they will handle it as we would expect and always hand
out the same IP address to the same MAC address under all conditions.

Now, to be clear, the problem arises *not* because the unit gets two
different addresses at boot time. The unit actually works fine in that
case as the application will override the address assigned by the OS
and you'll never hear about the OS IP address again.

The problem arises if a subsequent OS DHCP renewal picks up a *different*
IP address than was picked up at boot time, causing an IP reconfiguration
event, which doesn't inform the application of the IP address change. If
the OS DHCP renewal picks up the *same IP address it got at boot time*,
it will perform no such IP reconfiguration event and the Application's IP
address override stays in place.

The most common reason for periodic (vs persistent IP) address confusion
is if you reboot your Home Networking router. In this case, the DHCP
tables in the DHCP server are cleared and it greatly increases the chance
a subsequent OS DHCP renewal request. Many times, simply configuring
the MAC->IP address mapping will completely get rid of this case.

A 2nd situation I have seen in packets dumps for certain DHCP servers is
get into a race condition w/r/t the Replay ARP replies and sending out
hundreds of DHCP Offers as if it never received the DHCP ACK. This
commonly results in the DHCP server assigning a different IP address
as a failsafe.

So in my opinion probably in 99% of the cases, DHCP server with
MAC->IP address mappings and Replay configured for DHCP will
effectively work around the DHCP issue in Replay.

However, to be extra safe, you can eliminate the 2nd DHCP transaction
ID completely and avoid any confusion, by configuring Replay Application
for static IP, in addition to adding the MAC->IP address mappings in the
DHCP server.

BaysideBas

11-24-04, 02:50 PM

Yeah, and there are variations that appear to be stable, but which will occasionally burp, as happened to me a few days ago.

My 4 5Ks and DVA pc are on an internal LAN with no connectivity to the outside world and no DHCP server. I was happy to assign a static IP address to the pc and let the Replays sort out their respective addresses. Would amusingly note that the Replays would randomly select addresses and never considered that danger lurked ahead.

Last weekend I booted up the PC and got a message that a conflicting network was detected and that the local interface was therefore disabled. Attempting to start DVA in this condition resulted in DVA consuming over 90% of CPU cycles and just hanging there. Since now the pc was disconnected from the LAN, there was no quick way to check the status of the other devices on the LAN, all Replays. Grumbling to myself, I changed the static IP address of the pc and lo, I was able to start DVA normally. Checking the addresses of the Replays revealed that BedRoom had assumed the address I had been using for the pc!

The chances of this happening are very low, less than .5% for each replay per pc shutdown cycle and further lessened by whatever factor the shutdown duty cycle and Replay adress change cycle introduce. But it happened once, and surely will happen again, and it just shouldn't. Why can't the Replays stick with a working address once one is acquired?

ReplayLyndon

11-24-04, 03:22 PM

ragu,

Maybe, someone's mentioned it already, but I didn't see.

When you edit an IR code, it creates a code called custom at the top of the code list for that box. If you want to go back in and make further modifications to the IR settings, you have to then select CUSTOM and press zones. Otherwise, you get the original settings for the IR code you're trying to modify.

I don't see any special settings for the HIRD-B2.

Lyndon

ragu

11-24-04, 03:57 PM

ReplayLyndon thanks!!! I went that route also last week. I think I am going to try to unhook the coax out of the picture and try S-vid, just to see if it works. I might have to piggyback it thru 2 units, my Onkio and the replay, or should I say, Sat box to Replay, to Onkio, to TV.

pg525b

11-24-04, 05:07 PM

Originally posted by GTDaveMac
Yes it will! If you have a router that can do "static" DHCP for a specific MAC address, then you don't need to do anything else.

I don't so I use static and turned off DHCP.

Agreed. I used to have problems all the time due to the static / dhcp bug when I had my Replays set to static IP addresses, and there was a DHCP server running on the network.

Now I use the DHCP server in one of my Buffalo wireless routers (which supports reserving specific IP addresses to specific MAC addresses) and have not had a problem since. Both Replays are set to DHCP and always receive the same IP addresses.

vxWorks and/or the Replay software can request an IP address a hundred times if it wants to. All the requests come from the MAC address of the network card, and the server will ALWAYS reply to the box with the same offer if you are using reservations. IP address will ALWAYS be the same for that MAC address.
___

As regarding this...

Originally posted by l8er
As for a DHCP server and static IPs on a network ... I beg to differ. For example: you have a DHCP server set up to assign IPs from 192.168.0.1 through 192.168.0.100. You can assign a static IP address to a device on the network that falls within that range, for example 192.168.0.10. The DHCP server must be aware of the IPs in use (reserved or static) to avoid handing out a duplicate IP address (in this example, 192.168.0.10).

I know some DHCP servers will ARP or ping an address to see if it's in use before assigning it to a new requestor. I'm not sure if all servers do that though (esp home DSL routers, etc).

Jeff

*edit* guess I should have noticed there was a 2nd page to this thread before posting!

zaphod357

11-24-04, 06:10 PM

Ugh...I have never seen Onkyo misspelled so many times in one thread. Looks like everyone else has covered your issue.

Good thing, I wouldn't have done a d@mned thing for you with your attitude. Remember, this is a forum for ReplayTV users, not affiliated with ReplayTV. If you talked to support the way you spoke in this forum, I can understand why you have had support issues.

If you truly are some big muckity-muck, I would think you could pen up a better note (formatting, spelling, punctuation.) Maybe that's why they are outsourcing to IBM. Your posts, as they are, are virtually unreadable.

ragu

11-25-04, 07:17 AM

Well I can say after the last responce that this place has it's winners and Ying Yangs also.... to those that have tried to help, much thanks.
As far as attitude, when you spend money on something and don't get what you paid for, 2 times, it is a bit much. I guess I was just stupid in thinking there was something easy that was over looked. Once again I'm sorrry to have bothered those of you that that were so kind to try to help.
One last note, I got an emial today that was sent yesterday from ReplayTV, 2 RMS's for both my units, so I can return them for replacment.
English class is over..... :-)

ClearToLand

11-25-04, 08:17 AM

Originally posted by ragu: ...English class is over...

;););););)[FONT="Comic Sans MS"][SIZE=4][COLOR=red]ZZZZzzzz[/color][/size][SIZE=3][COLOR=red]ZZZZzzzz[/SIZE][/COLOR][SIZE=2][COLOR=red]ZZZZzzzz[/size][/COLOR][SIZE=1][COLOR=red]ZZZZzzzz[/SIZE][/COLOR][/FONT] ;););););)

adone36

11-25-04, 12:31 PM

Something tells me he's going to get 2 more "defectives".

spydermonkey311

05-14-05, 09:37 PM

keep losing my connection to my RTV. I never did have a problem with my old Netgear wired router, but this new one (wireless) is giving me lots of trouble. I am wired going to my RTV, not using the wireless function. I always had the Network setting on the RTV as "Automatic" and it worked fine. I have my port forwarding set for a specific IP that i gave to my RTV. After setting this up, I see that my RTV is connected to the network, and everything seems fine.

The next day I check the "Attached Devices" in the webinterface, and the RTV isnt shown. I then checked my RTV, and it had a different IP address then the day before. I setup my Router to have a "Address Reservation" for my RTV, then set my RTV to "Manual" setting with the reserved IP address. Everything seemed to be working fine until the next day. I still have the reserved IP address on my RTV, but the router isnt showing it as a Attached Device.

I then changed the setting back to "Automatic", and when the DHCP server renews the IP address, it gave my RTV a different IP than the one I reserved.

Anyone have any ideas what im doing wrong? I read over the FAQ and also this thread, but it seems like I shouldnt have this problem