dfnt:

 

0 issues here 

None here either

Crowbar: Being Android TV, I would have thought they'd be the easiest to support.

They also have Chromecast built in.

Only the higher end ones are Android TV. The cheaper panels are proprietary.

old3eyes:

tdgeek:

 

Whats Peters going on about? he is summarising the Governments news, while the PM is away, and he goes on about a company who was airing a sports event? Its not a Govt department, none of his business.

 

Wasn't he the one at the last election promising that all NZ sport would be free?

Yes!

frednz:

 

vexxxboy:

 

good article

 

https://thespinoff.co.nz/business/23-09-2019/all-the-winners-and-losers-of-sparks-abject-disaster-of-a-weekend/

 

 

From the above:

 

A Spark source says company took this incredibly seriously, building a “situation room” with every combination of devices streaming simultaneously. For the first games, and the first 30 minutes of the All Blacks–Springboks game, it worked flawlessly. Then those watching started seeing “significant fluctuations in video frame rate quality”. 

 

The source maintains that the platform has worked flawlessly, and believe they have subsequently tracked the problem down. My Spark source refused to name the provider, but The Spinoff understands it is industry giant Akamai. The source maintains that an “internet gateway got overloaded”, due in part to the game’s timing – Saturday night is already a moment of heavy streaming for New Zealand – and that the streams will be split over multiple gateways in future. 

 

Several people on this thread have suggested that overloading is the problem, and now the above article says the same. Although Spark denies overloading was the cause, surely this is the most obvious reason for all the problems?

 

Incidentally, do you agree that wired high speed fibre internet should produce a better Spark Sport picture than that obtained using WiFi on a streaming device such as Apple TV?

 

Yes, makes no sense. The Stuff article suggested that only 1 of the 6 Akamai servers ran the AB's game. Spinoff suggests that didnt happen, it was too much, they will add more in the future

If the end device can manage 1080p/50, i.e. the wifi exceeds the bandwidth used, it wont matter.  A Morris Minor and a Bugatti can both travel at 50kph in a Friday night in town, higher speed doesnt matter

robbon44: I’m not anyway in the know as to how international data feeds are distributed but can anyone explain how the feed to duke was way better than the feed to sparks own isp?

I didnt notice any quality difference. Must be device dependent.

robbon44: I’m not anyway in the know as to how international data feeds are distributed but can anyone explain how the feed to duke was way better than the feed to sparks own isp?

From what I have seen/read the pictures are sent via the Satellite/fibre from Japan to NZ. Local content added and then it is sent to the US for encoding and sent back.

Duke would be getting the feed straight after local content added methinks in un-encoded, ye olde TV form.

EDIT: And the Wales/Georgia games was fine for me.

tdgeek:

 

frednz:

 

vexxxboy:

 

good article

 

https://thespinoff.co.nz/business/23-09-2019/all-the-winners-and-losers-of-sparks-abject-disaster-of-a-weekend/

 

 

From the above:

 

A Spark source says company took this incredibly seriously, building a “situation room” with every combination of devices streaming simultaneously. For the first games, and the first 30 minutes of the All Blacks–Springboks game, it worked flawlessly. Then those watching started seeing “significant fluctuations in video frame rate quality”. 

 

The source maintains that the platform has worked flawlessly, and believe they have subsequently tracked the problem down. My Spark source refused to name the provider, but The Spinoff understands it is industry giant Akamai. The source maintains that an “internet gateway got overloaded”, due in part to the game’s timing – Saturday night is already a moment of heavy streaming for New Zealand – and that the streams will be split over multiple gateways in future. 

 

Several people on this thread have suggested that overloading is the problem, and now the above article says the same. Although Spark denies overloading was the cause, surely this is the most obvious reason for all the problems?

 

Incidentally, do you agree that wired high speed fibre internet should produce a better Spark Sport picture than that obtained using WiFi on a streaming device such as Apple TV?

 

 

Yes, makes no sense. The Stuff article suggested that only 1 of the 6 Akamai servers ran the AB's game. Spinoff suggests that didnt happen, it was too much, they will add more in the future

 

If the end device can manage 1080p/50, i.e. the wifi exceeds the bandwidth used, it wont matter.  A Morris Minor and a Bugatti can both travel at 50kph in a Friday night in town, higher speed doesnt matter

 

What has been intersting to me has been everybody jumping on the "lets bash Akamai" bandwagon. With Spark not providing any high level technical explanation of the problem we can all only speculate. Those who understand the complex setup however would be just as quick to blame iStreamPlanet who could just as easily have been at fault (and depending on exactly what the fault was, there is a higher chance it was them rather than Akamai).

I bet a number of journalists who wrote articles blaming Akamai had no real source and were simply basiing their assumptions off what other people had written. The technical aspects of exactly how a stream gets to your home would be beyond the comprehension of 99% of people.

In many ways there would be no point Spark actually providing a high level explanation of the fault because it's safe to say it would not be understood by 99% of people and would simply be misconstrued.The fact social media has been full of people (some of whom are quite technical) blaming Spark's peering policy shows people don't understand how a CDN works and that Akamai have geographically distributed CDN network inside all the big RSPs.

sbiddle:

 

 

 

What has been intersting to me has been everybody jumping on the "lets bash Akamai" bandwagon. With Spark not providing any high level technical explanation of the problem we can all only speculate. Those who understand the complex setup however would be just as quick to blame iStreamPlanet who could just as easily have been at fault (and depending on exactly what the fault was, there is a higher chance it was them rather than Akamai).

 

I bet a number of journalists who wrote articles blaming Akamai had no real source and were simply basiing their assumptions off what other people had written. The technical aspects of exactly how a stream gets to your home would be beyond the comprehension of 99% of people.

 

In many ways there would be no point Spark actually providing a high level explanation of the fault because it's safe to say it would not be understood by 99% of people and would simply be misconstrued.The fact social media has been full of people (some of whom are quite technical) blaming Spark's peering policy shows people don't understand how a CDN works and that Akamai have geographically distributed CDN network inside all the big RSPs.

 

 

 

I dont think there is Akamai bashing here. One source stated one server of six, so that did appear to be specific and not assumed/guessed. I cant speak for anyone else, I'm keep to know the cause and that it was fixed, issues do happen. But yes, there are those that sharpen daggers and wait.

freitasm: And yet, for transparency, it would be good to see a post-mortem. Other companies do.

insane: E.g Akamai could have done everything they could, but another ISP, carrier or provider involved could have made some suboptimal routing or capacity planning decision preventing them from filling all their caches fast enough, or being used at all.

Considering they paid Akamai for all those augments and even issued work restrictions on Chorus and RSP networks. You can't get more end-to-end control than that. I would have expected someone to be invited to the Akamai NOC in Boston to monitor everything first hand TBH. It was clear they threw extra resource working with iStreamPlanet to compensate for their lack of experience in delivering streaming media down under.

"United States technology company Akamai has declined to say whether it accepts responsibility for the streaming problems that dogged Spark Sport's coverage of the RWC match between the All Blacks and South Africa on Saturday.

Akamai's US-based vice president of corporate communications, Christine Simeone, also declined to provide an account of what went wrong or an assurance that issues would not be repeated, instead deferring comment to Spark.

"Based on our conversations with Spark ... we agree that any questions about this situation are to be handled by Spark," she said."

https://www.stuff.co.nz/business/116036522/us-tech-giant-akamai-declines-to-say-whether-it-accepts-blame-for-rwc-failure