Roku Developer Program

[TheEndless]

"EnTerr" wrote:
And let me raise an eyebrow at TheEndless: you did not equate a bug of player crash&burn to the behavior of "won't play a stream", did you? 😉

No I did not. I was commenting on the fact that the attribute is being used incorrectly, and if it were working correctly, it should fail to play the stream. Two completely different bugs.

[greubel]

In my testing on the local network, setting either / both values made absolutely no difference. The only change was the "dots" on the screen. For some reason Roku likes to stream as much as possible to fill up memory, irregardless of what you say. It is totally absurd that you can start up a stream and then after playing for awhile, you can kill the server and the Roku will continue to play for 18 minutes. Talk about over buffering ! These local m3u8s only have a single bitrate stream.

[EnTerr]

"TheEndless" wrote:
No I did not. I was commenting on the fact that the attribute is being used incorrectly,

Agreed.

and if it were working correctly, it should fail to play the stream.

Nope. You are doing "mind-reading" here. There is nothing that says what will happen if there is no stream satisfying MaxBandwidth. It seems logical to you it should not play. To me - today (and considering the moon phase) - it seems logical it should play something, even if it does not match. Currently that is undocumented behavior. What it shouldn't do though, is crash and burn.

Two completely different bugs.

1 bug and 1 unspecified behavior. They cannot be placed on the same plane - is my objection. By "equate" i meant bringing one to the level of the other. One cannot excuse the other... it's not a balance, not a wash.

[TheEndless]

"greubel" wrote:
In my testing on the local network, setting either / both values made absolutely no difference. The only change was the "dots" on the screen.

The dots are determined by the Bitrate value, not the Min or MaxBandwidth values. Those should have no effect whatsoever on the displayed dots.

"EnTerr" wrote:
it seems logical it should play something

Fair enough, but I still disagree. My expectation of how it should work is based on how MinBandwidth works. I'd expect MaxBandwidth to behave the same. If you're explicitly specifying a MaxBandwidth in your code, then you have a reason to do so. Playing a stream that requires more bandwidth than your code explicitly allows would be incorrect behavior, in my opinion.

"EnTerr" wrote:
By "equate" i meant bringing one to the level of the other.

I'm not sure where I did that, but it wasn't my intention. Obviously crashing the box should be considered a higher priority bug than playing the stream when you shouldn't.