Roku Developer Program

Join our online forum to talk to Roku developers and fellow channel creators. Ask questions, share tips with the community, and find helpful resources.
cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
TheEndless
Channel Surfer

Re: Another way to crash Roku2 XS

"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.
My Channels: http://roku.permanence.com - Twitter: @TheEndlessDev
Instant Watch Browser (NetflixIWB), Aquarium Screensaver (AQUARIUM), Clever Clocks Screensaver (CLEVERCLOCKS), iTunes Podcasts (ITPC), My Channels (MYCHANNELS)
0 Kudos
greubel
Visitor

Re: Another way to crash Roku2 XS

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.
0 Kudos
EnTerr
Roku Guru

Re: Another way to crash Roku2 XS

"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.
0 Kudos
TheEndless
Channel Surfer

Re: Another way to crash Roku2 XS

"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.
My Channels: http://roku.permanence.com - Twitter: @TheEndlessDev
Instant Watch Browser (NetflixIWB), Aquarium Screensaver (AQUARIUM), Clever Clocks Screensaver (CLEVERCLOCKS), iTunes Podcasts (ITPC), My Channels (MYCHANNELS)
0 Kudos
Need Assistance?
Welcome to the Roku Community! Feel free to search our Community for answers or post your question to get help.

Become a Roku Streaming Expert!

Share your expertise, help fellow streamers, and unlock exclusive rewards as part of the Roku Community. Learn more.