I don’t have an example channel ready, but we are running into an issue with these two players using the 7.5 firmware. It seems the players will only wait 5 seconds to receive data. This is definitely too low in some cases. I’m trying to find a box running 7.2 or 6.2 firmware to confirm, but I’d like to get this thread started to hopefully get some traction on this. Basically if a media url takes more than 5 seconds to respond, the player will timeout and send an isRequestFailed message.
Roku: I’d expect even if this is a bug, it will take a while to get fixed in a firmware update, especially with the holiday season closing in. In the mean time, is there any way to control this short timeout and extend it video some hidden or undocumented method?
Yep, seeing the same issue. This affects emby liveTV streaming, in the 2nd thread I provide logs as the issue happens. It has never been addressed and is specific to the firmware 7.5 update.
Button command: play
GetContextForPlayback TvChannel
:::Configuration::: Video Player - Total 1 - Skipped 0 - Added 1
Not sure what to do with breadcrumbs on screen type: Invalid
Pushing screen 50 onto view controller stack - Video Player
MediaPlayer::playVideo: Displaying video: 13.2 KERADT2 (KERA-DT2)
Getting metadata for Id 2f995ae78bcd20dab59a3ef061e1d4e0
addPlaybackInfo item.Id: 2f995ae78bcd20dab59a3ef061e1d4e0
Supported Audio Containers: raw,mp4,mka,m4a,mp3,mp2,wma,asf,wav,flac
Supported MP4 Containers: mp4,mov,m4v
Supported MP4 V-Codecs: h264,mpeg4
Supported MP4 A-Codecs: lpcm,aac,mp3,mp2,wma,wmav2,wmapro,alac,ac3,eac3
Supported MKV Containers: mkv
Supported MKV V-Codecs: h264,mpeg4
Supported MKV A-Codecs: lpcm,aac,mp3,mp2,wma,wmav2,wmapro,flac,alac,ac3,eac3
Transcoding V-Codec: h264
Transcoding A-Codec: ac3
getDynamicPlaybackInfo itemId: 2f995ae78bcd20dab59a3ef061e1d4e0
getDynamicPlaybackInfo url: http://<IP REMOVED>:8096/emby/Items/2f995ae78bcd20dab59a3ef061e1d4e0/PlaybackInfo?UserId=36b3c926726648f191ca719a223a1992&starttimeticks=00000000&maxstreamingbitrate=30000000
Setting PlayStart to 0
Starting to play transcoded video
Playback url: http://<IP REMOVED>:8096/emby/videos/2f995ae78bcd20dab59a3ef061e1d4e0/master.m3u8?DeviceId=1GJ37M000975&MediaSourceId=8fd71f652099410fbf2ed09f8638e39d_heavy_2ca30331dcd09a80289be028e7fdfa4a&VideoCodec=h264&AudioCodec=ac3&AudioStreamIndex=1&VideoBitrate=29808000&AudioBitrate=192000&MaxAudioChannels=6&MaxFramerate=61&MaxWidth=1920&MaxHeight=1080&Level=51&MaxRefFrames=16&MaxVideoBitDepth=8&Profile=high&PlaySessionId=eca6453d5d8d458990d7228b6da9c166&api_key=f52e89e392a74bb68964144dca21f793&LiveStreamId=1a755974de5dc3461dc6ecae8ddec68b_6ac70aba3e6587e661d9adc842397899_8fd71f652099410fbf2ed09f8638e39d_heavy_2ca30331dcd09a80289be028e7fdfa4a&CopyTimestamps=false&EnableSubtitlesInManifest=false&EnableSplittingOnNonKeyFrames=false
::roVideoScreenEvent - Video Status: 0 0
::roVideoScreenEvent - Video Status: 66 0
::roVideoScreenEvent - Video Status: 132 0
::roVideoScreenEvent - isRequestFailed - message = The connection timed out.
::roVideoScreenEvent - isRequestFailed - data = 0
::roVideoScreenEvent - isRequestFailed - index = -2
::roVideoScreenEvent - isFullResult: position -> 0
::roVideoScreenEvent - Video Status: 0 0
::roVideoScreenEvent - isScreenClosed: position -> 0
::Warning:: Falling back to transcoding
MediaPlayer::playVideo: Displaying video: 13.2 KERADT2 (KERA-DT2)
Getting metadata for Id 2f995ae78bcd20dab59a3ef061e1d4e0
addPlaybackInfo item.Id: 2f995ae78bcd20dab59a3ef061e1d4e0
Forcing Transcode no capabilities required!
Transcoding V-Codec: h264
Transcoding A-Codec: ac3
getDynamicPlaybackInfo itemId: 2f995ae78bcd20dab59a3ef061e1d4e0
getDynamicPlaybackInfo url: http://<IP REMOVED>:8096/emby/Items/2f995ae78bcd20dab59a3ef061e1d4e0/PlaybackInfo?UserId=36b3c926726648f191ca719a223a1992&starttimeticks=00000000&maxstreamingbitrate=30000000
Setting PlayStart to 0
Starting to play transcoded video
Playback url: http://<IP REMOVED>:8096/emby/videos/2f995ae78bcd20dab59a3ef061e1d4e0/master.m3u8?DeviceId=1GJ37M000975&MediaSourceId=858a629866a54edca5b3c9a7eab9ffd0_heavy_2ca30331dcd09a80289be028e7fdfa4a&VideoCodec=h264&AudioCodec=ac3&AudioStreamIndex=1&VideoBitrate=29808000&AudioBitrate=192000&MaxAudioChannels=6&MaxWidth=1920&MaxHeight=1080&Level=51&MaxRefFrames=16&MaxVideoBitDepth=8&Profile=high&PlaySessionId=71c1428ce3cf4007b5cf2d5c6d0878ee&api_key=f52e89e392a74bb68964144dca21f793&LiveStreamId=1a755974de5dc3461dc6ecae8ddec68b_6ac70aba3e6587e661d9adc842397899_858a629866a54edca5b3c9a7eab9ffd0_heavy_2ca30331dcd09a80289be028e7fdfa4a&CopyTimestamps=false&EnableSubtitlesInManifest=false&EnableSplittingOnNonKeyFrames=false
::roVideoScreenEvent - Video Status: 0 0
::roVideoScreenEvent - Video Status: 66 0
::roVideoScreenEvent - Video Status: 132 0
::roVideoScreenEvent - isRequestFailed - message = The connection timed out.
::roVideoScreenEvent - isRequestFailed - data = 0
::roVideoScreenEvent - isRequestFailed - index = -2
::roVideoScreenEvent - isFullResult: position -> 0
::roVideoScreenEvent - Video Status: 0 0
::roVideoScreenEvent - isScreenClosed: position -> 0
Not sure what to do with breadcrumbs on screen type: Invalid
Pushing screen 51 onto view controller stack - Dialog: Playback Error!
Creating new dialog
Button pressed: OK
Thanks for another confirmation of the issue speechles.
@ROKU Here is a sample channel that exhibits the issue. The source url simply waits 6 seconds before serving the source content, nothing crazy, just real world issues for some connection types. https://www.dropbox.com/s/jg3rv0gq1f26g … s.zip?dl=0
Here are the output from the failure running on 7.5 firmware. Note that it only wait 5 seconds before giving up. Earlier firmware version would wait for much longer. I haven’t confirmed how long, but I can if needed.
------ Running dev 'Video Playback Timeouts' runuserinterface ------
Starting Playback @2016-11-16T04:44:36Z
pkg:/images/progress_bar_1.png
pkg:/images/progress_bar_1.png
Raw progress: 0
Raw progress: 66
pkg:/images/progress_bar_1.png
Raw progress: 132
pkg:/images/progress_bar_1.png
http error @2016-11-16T04:44:41Z<Component: roAssociativeArray> =
{
Datetime: <Component: roDateTime>
HttpCode: -1
LogType: "http.error"
Method: "GET"
OrigUrl: "http://rarforge.com/git/files/stream.php"
Status: "connectiontimeout"
TargetIp: "54.200.183.145"
Url: "http://rarforge.com/git/files/stream.php"
}
Playback failed @2016-11-16T04:44:41Z
isRequestFailed - message = The connection timed out.
isRequestFailed - data = 0
isRequestFailed - index = -2
Looks like plenty of forensics here - but I can also confirm this behavior. I’m running exclusively transcoded content between Roku / Plex - and the issue described here affects all of my Roku devices which are on the 7.5 firmware. If transcoding commences fast enough, the play succeeds.
Could you please try calling ‘SetConnectionTimeout(30)’ on the video player object. With 30 being the socket timeout value in seconds.
After this call the player should wait 30 seconds before timing out.
“RokuWimM” wrote:
Could you please try calling ‘SetConnectionTimeout(30)’ on the video player object. With 30 being the socket timeout value in seconds.
After this call the player should wait 30 seconds before timing out.
Thanks for the quick response. That is exactly what we were hoping for, or a quick firmware fix, so we don’t have to wait for a channel review I’ll give this a test and report back.
“RokuWimM” wrote:
Could you please try calling ‘SetConnectionTimeout(30)’ on the video player object. With 30 being the socket timeout value in seconds.
After this call the player should wait 30 seconds before timing out.
Tested and it works perfectly in the lab! Looks like the roVideoPlayer and roVideoScreen both implement the method, as well as the roAudioPlayer. Do you have any idea what these timeouts were set to pre 7.5 for the different players, as well as the min and max values? Also curious if Roku is thinking about raising the defaults in a firmware update, otherwise existing channels will have to make this change and process through the channel store review process. Again, thank you for answer this so quickly. It was nice to see after all the time spent debugging and identifying the issue.
“ljunkie” wrote:
Tested and it works perfectly in the lab! Looks like the roVideoPlayer and roVideoScreen both implement the method, as well as the roAudioPlayer. Do you have any idea what these timeouts were set to pre 7.5 for the different players, as well as the min and max values? Also curious if Roku is thinking about raising the defaults in a firmware update, otherwise existing channels will have to make this change and process through the channel store review process. Again, thank you for answer this so quickly. It was nice to see after all the time spent debugging and identifying the issue.
Prior to 7.5 the default timeout was 30 seconds for all players (roVideoScreen/roAudioPlayer/roVideoPlayer). Regarding min and max values, currently the firmware does not limit the timeout value set by a channel. It’s up to the channel developer to use reasonable values. Since 30 seconds worked in the past I propose to use that value.
I immediately went there too when I noticed what implemented it, but after limited testing, that doesn’t seem to the case. The roTextutreManager and roTextureRequests look unaffected as well as the roUrlTransfer. The other listed we don’t use, so I can’t say. It seems though that Roku may have just set the “player” components with the default 5 second timeout, but I’ll defer to them as they are the only ones that can provide which components now have a 5 second timeout.
“RokuDale” wrote:
The timeout change has the limited scope of the component.
Sorry, that’s a bit unclear…
You mean that only the instances from roVideoScreen/roAudioPlayer/roVideoPlayer have their default timeout shrunk to 5 sec?
And on the flip side, all other ifHttpAgent implementors now too have SetConnectionTimeout() available but with a different default?
“RokuDale” wrote:
The change only affects the videoplayers use of http agent. All other users of httpagent are not affected.
It also affected the roAudioPlayer. I assume 7099 has the timeout fix? Haven’t tested yet since we’ve since added the workaround. Will have to verify later.
I’ll give this a test and report back.