On my Roku, I have two different instances of the same exact channel installed (one private, one sideloaded). Both are built from identical code.
Just now, I was successfully playing an HLS live video stream on the sideloaded channel, and then I manually ended playback with my remote. When I attempt to restart playback, I get the following error:
The format is not supported or the media is corrupt. | type = 9
If I then switch to the other (private) version of the channel, using the same codebase and same HLS URL, it will play fine. I can manually stop playback, and resume just fine. Back on the sideloaded version, it’s still failing with the same error. I can’t seem to get the HLS URL to work again on the sideloaded channel, even though the same exact URL works on the other version of the same channel (with the same exact codebase).
Is there some sort of video/url caching going on, which might have been corrupted in some way? Why would the same URL work on one channel but not the other, when they both use the same code?
The problem is that an HLS URL plays on one channel, but the same link does not play on another version of the same channel.
This was kind of complicated to explain, but could this be related to the HLS sync weirdness that people have been reporting since the last firmware update?
This is very strange… if all the parameters are the same they should play the same. Unless you’re looking at the devid in server side authentication the side loaded channel should be equivalent to the private channel.
Are you sure they are the exact same params: stream urls, StreamFormat=“hls”, bitrates, qualities ??
The most frequent culprit of “The format is not supported or the media is corrupt” is that the StreamFormat setting does not match the content in the url.
–Kevin
[edit]nevermind.. missed the part about it working initially.[/edit]
“RokuKevin” wrote:
This is very strange… if all the parameters are the same they should play the same. Unless you’re looking at the devid in server side authentication the side loaded channel should be equivalent to the private channel.
Are you sure they are the exact same params: stream urls, StreamFormat=“hls”, bitrates, qualities ??
The most frequent culprit of “The format is not supported or the media is corrupt” is that the StreamFormat setting does not match the content in the url.
–Kevin
Same ContentMetaData parameters, same BrightScript code, same everything as far as I can tell.
Both instances of the channel work fine most of the time, but once this error occurs, that instance of the channel will be “broken” as described above until reboot. After reboot, it will work fine again.
I wish I could provide more information, but I haven’t found reliable steps to reproduce the issue. I’ve only seen it with HLS though, never with mp4s.
“TheEndless” wrote:
There is new behavior in the 1533 firmware that causes that error if the box is set to stereo audio, but the stream only contains AC3. I don’t know if AC3 is supported with HLS or not, but is it possible that’s the issue here? AC3 audio with one box set to 5.1 and the other set to Stereo?
This problem occurs with two separate-but-identical versions of the same channel, both installed on the same Roku box on the same TV. One version is a private channel, the other is side-loaded.
The streams that I’m playing are from JustinTV, which is funny now that I think of it, because I saw something similar from your channel last night. A stream I was watching unexpectedly cut out with a “Playback has ended, or the stream is in a non-compatible format” message. After that, ALL streams would fail with that same error, even after exiting/reentering the channel. A reboot fixed the problem.
Have you experienced or heard of anything similar, where all streams would abruptly stop working for no discernible reason?
I’m not sure how the problem could be on JustinTV’s end though, because the problem seems to be channel specific. I’m not sending any information that would distinguish the private version of my channel from the side-loaded version.
Very strange.
