OK, Google: Why does Chromecast clobber Wi-Fi connections?

Google employ coders? I thought they just sat around all day drinking poncy coffees like Q whilst rifling through your NHS Heath Data records.

The Google coding team responsible for their Cast product has become pretty bad. Worse is that they force-upgrade so you have no choice but swallow the buggy code.

It's typical "I've been taught to code, but I don't actually understand computers and the culture/environment in which they're used". People who have no idea of the limitations of where their code will be executed — i.e. why it's unreasonable to bang out N packets all at once, rather than feed them to a rate-moderated emitter, or in this case more than N (for small values of N) is unreasonable to stuff into your for(register x=0;x<N;x++) resend_MDNS_announcement(last_index_sent+x); /* spot the errors */ loop.

What is 2,000,000 packets blasted out on your typical 802.11g network in a typical crowded urban environment, anyway?

Why, indeed, is it unreasonable for any one subsystem to be able to allocate all of the available RAM for its own use and then busy-wait while it's waiting for those 2,000,000 packets to be stuffed out the radio?

The stupidity is in sending a packet for every announcement "missed" because it was asleep, all lumped together the second it wakes up. That's just dumb.

short n concise precis of what the fail actually IS - cheers

Sounds like one of the internal monitoring tools we used to have on our corporate laptops.

Sleep, or hibernate the machines, and on boot up, the HD was thrashed for a while, and how long seemed to be related to the length of the sleep. Could be thrashing for 30 mins or more after a weekend for example, and pretty much stopped all other usage of the device till it was done, due to badly set permissions (was low priority, but not low IO).

Was traced to some monitoring tool, that would periodically scan logs, and create a summary that was pushed to a central server. You guessed it, it didn't take into account sleep or hibernate, and so just ran all it's 'missed' jobs in one go, and in parallel!

Sounds like the behavior of Java's Timer.scheduleAtFixedRate() and/or ScheduledExecutorService.scheduleAtFixedRate(). It fails horribly in this exact manner any time the system clock jumps (due to the system going to sleep, the time being set, etc.). Been burned by that too many times to count.

Knowing that Google uses Java heavily, I'd wager this is the culprit.

The router manufacturers needed to do something: DoS protection for starters.

Re: Aknowledgement of the issue from Google.

This, in itself, is newsworthy. I can't think of any other time when Google has admitted to making a mistake.

Re: Roku F-u

I'm not so sure the issue is "fixable".

This would imply the Roku has _2_ radios, and not just the single radio I've been able to find so far.

The single radio it has is a dual-band (but not simultaneously both bands at the same time) 2.4 and 5GHz. You'd need an entirely separate radio to make your setting even possible in a wirelessly-connected Roku scenario.

Therefore, if you don't have the device plugged into a wired LAN, you are forcibly limited to being on the same channel that the Roku is already tuned to, to access your WLAN.

When plugged into wired Ethernet, you can rightfully expect it to honor your settings; when connected wirelessly it cannot.

If your Roku Streaming Stick for example doesn't have a Wired connection to begin with, you're SOL - or you could always leave it as an island, with no Internet connectivity, and expect it to perform admirably on your preset channel Wifi-Direct-only.

Re: when in tandem...

Or if you need a new device: vigor 130.

The only isp I know of with issues on getting usernames and passwords is sky.