Hacker News Reader

Comment by untog | Hacker News Reader

This is where Apple's closed nature is very annoying. Assuming the article is correct, it was bug introduced in 6.0, and fixed in 6.0.1. So Apple knew about it, investigated it and published a fix.

Yet they didn't tell anyone about it. Or the crippling effect this bug could have on their data allowances. Why not? Are they really that terrified of admitting to making a mistake?

View on HN

This same behavior has been happening to me since before iOS 6 came out. I can show the same "206 storm" happening as far back as August of last year with iOS 4.3.5.

I used to work at http://castfire.com/, and we've seen that similar issue from a LOT of iOS clients. Stats become increasingly difficult, because we saw one unique request bounce with upwards of 50+ 206s for similar / overlapping media... and then it bounced through a cell provider, to a WiFi network, and back, etc.

(we identified by redirecting all requests through a complex process of assigning an ID to them)

Hoping this is fixed. Podcast metrics are tricky, and this has been exacerbating the issue.

The playback stuff definitely makes use of many range requests, but what we found was that they were being used in a way that vaguely made sense in other versions (i.e. downloading a few hundred kb to continue buffering, pausing the download, and picking up again). With 6.0.0, we're seeing actual storms of these requests happening many times per second.

To play devil's advocate, why would it matter? Is there any fix app developers could implement, short of blocking requests from iOS 6 users?

It would at least communicate to users that the upgrade to 6.0.1 is very important if they use the Podcasts app. Many may have put off installing the update because they thought their phone was working fine. A bandwidth eating bug has to be along the least visible.. in the short term.

Reply on news.ycombinator.com