I can't even begin to discuss what's right and wrong in this thread thus far.
You can't just take an IP and assign it to another box on another network. The IP block that the address falls in must be re-routed to the new location. The Internet as we know it at a high level routes based on Antonymous System Number instead of IP address. Providers who are multi-homed run a protocol called BGP (Border Gateway Protocol) that basically announces to the entire Internet "This is my ASN, and these are the subnets I am aware of (either directly connected, statically routed, or learned via some type of igp such as ospf) within my ASN". Such announcements generally never have a prefix smaller than /24 (~252 addresses or less), and most providers will filter any announcements for prefixes smaller than /24. So, you won't see single IP addresses in the global routing table -- and if you do, they will almost unanimously be ignored.
Now, most major networks (and I'm sure that level 3 and E* both fall in this category) will be peered with two or more upstreams. This is transparent at the IP level, because those BGP announcements will tell "the rest of the world" about the paths available to get to the network.
Regardless of multiple paths being available, routers will insert only the best path into their routing tables. If this path becomes unavailable, the route will get replaced with the next best path. This is not completely instantaneous but it's pretty fast...
Now, this doesn't cover a number of scenarios. For example, what if the power goes out to the router that is announcing the networks, or the machine itself, or both. Now, of course, this is preventable by having multiple routers announcing the same ASN in different parts of the campus with different power feeds, running an IGP to handle changes/failures in the internal routing structure, having multiple segregated machines that can respond to the same IP, fault tolerant load balancers / traffic directors, etc etc...
But, being that you can pick up a 1/4 rack of co-location for dirt cheap nowadays, the cost/benefit ratio of building a massively redundant network versus putting boxes on two separate networks is fairly significant. It's generally easier and cheaper to have two boxes on two networks with two different providers on two different power grids with two different ip addresses, and have your STB's "call home" to two different IPs that exist in two completely different subnets.
They could do it through DNS by having a common hostname that they control with a short TTL, and change the IP within DNS. I've seen DNS records cached for hours or days even with a short TTL though, especially with large providers (i.e. the ones that lots of 722 owners would have at home, comcast, verizon, etc) ignoring short TTLs to save on outbound DNS traffic -- RAM is cheaper than bandwidth after all, so that's an easy enough option to rule out.
That's the short version. Redundancy of internet-facing services is a very, very complex subject. It's also a big part of my job and has been for most of my adult and part of my non-adult life.
The really short version -- most people usually do more than one thing to keep things redundant. No matter how much redundancy you have on your primary systems and within your network, the big guys almost always throw offsite boxes on a completely separate network.
