(sorry for long post)
1) well the good news is getting the right ip ... if the ip's hadn't been the same then there would be a double nat issue, and at that you'd be at TWC's mercy.
2) could this be router issue? ... I looked up the specs at DD-WRT.com with their "Router Database" .. it says the WNR1000 v3 has 4 megs of flash, and 16 megs Ram... thats the minimum I would recommend for any average user ... with it, if you're supporting 3 or 4 inhouse devices (laptops, computers) you may find the internet slows down after longer periods of use, and if you could look at the memory usage (or at least with DD-WRT on it you could) you'd find under 800k memory free .... reboot, everthing gets faster and you have 1.4 megs free .... at least that was my general experience ..
Then I switched to routers that have 32 megs of ram, and haven't seen a slowdown issue, though I have seen other things come up (different versions of DD-WRT's replacment firmware can sometimes feel like a crapshoot)... but in general having 32 megs of ram is better for power users or larger house networks (10 to 15 active devices -- 5 computers/laptops, 4 multimedia <722k's - wii - bluray - AV receiver> , 2 iphones & an android)
BUT ... I'd wait on the router ... give the hard wire network a chance.. especially if the WNR1000 *has* been working with UPnP ... since that's often the real hangnail .. you've been getting a connection, the speed of the WNR is about average in todays home (dual band routers with 32 or 64 megs of ram would more likely be faster but marginal in a light duty environment) so no need to toss it just yet.
3) As to packet loss ... if you're seeing losses like that.. you're loosing network connectivity to the receiver ... all things being equal.. no rouge friend over downloading WOW or pulling down gigs of data, while running pings.. the only doubt becomes your pc connection to the wireless, like standing next to the microwave and flicking it on while testing ... *but* given what you've been experiencing up to this point .. the disconnects on streaming... it seems very likely the culprit is the Powerline adapter getting to the receiver.
Once you get the switch in place ... repeat the pings ... if you don't see packet loss.. then you're one step closer.
here's an example of mine (ran multiple tests at the same time for nearly 20 minutes of pings, still 0% loss)
Code:
Reply from 192.168.1.246: bytes=32 time=1ms TTL=64
Ping statistics for 192.168.1.246:
Packets: Sent = 1145, Received = 1145, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 1ms, Maximum = 19ms, Average = 1ms
Control-Break
Reply from 192.168.1.246: bytes=32 time=1ms TTL=64
In my case I opened a command prompt (Start -> Run -> CMD <enter>) then I put: ping -t 192.168.1.246 <enter>
the -t is for con
Tinuous .... press & hold CTRL then press the "Pause / Break" key and let both go... that will give you a read at that moment in time, of ping statistics.. (what I pasted above) Pressing CTRL C will stop the command.
a random high ping or two would be minor (since going across wireless and the Powerline bridge, could be wireless retransmit, could be noise in the AC line, etc..
though a single packet loss shouldn't cause communications to break down .. you never know with some apps (client - WebSlingPlayer or server-SlingAdapter/DishReceiver) they may have low tolerance for packet failure and its possible the packet failure could get worse if you put it under load...
with the command prompt PING command you can set a size of packet to use..
Code:
ping -t -l 1024 192.168.1.246 <enter>
this would send continuous pings of 1024 byte packets (-l is -L for "packet Length") to one of my dish receivers ...
a little more than 5 minutes of ping packets at 1024 bytes:
Code:
Reply from 192.168.1.246: bytes=1024 time=2ms TTL=64
Ping statistics for 192.168.1.246:
Packets: Sent = 343, Received = 343, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 2ms, Maximum = 12ms, Average = 3ms
Control-Break
Reply from 192.168.1.246: bytes=1024 time=3ms TTL=64
So I actually had two sets of pings running at the same time, neither lost a packet ... even with a simulated load.. (its a ping every second so 1145 pings = 1145 seconds or just shy of 20 minutes with zero loss while typing up this massive thread response)