Video Error - Ignored

[speechles 1917]

I get it now. It is a roku mistake. One that.. maybe I should inform roku.co forums exists.. but there is a way to work around it..

 

device = CreateObject("roDeviceInfo")
if FindMemberFunction(device, "CanDecodeVideo") <> invalid then
        supports4kcodec = (device.CanDecodeVideo({ Codec: "hevc" }).result = true or device.CanDecodeVideo({ Codec: "vp9"}).result = true)
else
        supports4kcodec = false
end if

 

Here is the present detection routine to add hevc and vp9 support. Notice it is just seeing if the GPU returns true for the codec, not throwing profiles and such at it. This method used to work for all roku models. Since 8.1.x firmware releases it seems any GPU with hevc/vp9 present but unused (because of poor core/thread count limitations on the GPU) will show hevc/vp9 as a codec and return true for the code above. 

 

Notice the 4k support line on your first screen shot. This is done by also giving the hevc and vp9 codecs a profile and such, not just their codec names. This proves to actually detect support correctly. So the fix, is to.. also add this to the initial detection, shown below.

 

device = CreateObject("roDeviceInfo")
if FindMemberFunction(device, "CanDecodeVideo") <> invalid then
        supports4kcodec = (device.CanDecodeVideo({ Codec: "hevc", Profile: "main", Level: "5.1" }).result = true or device.CanDecodeVideo({ Codec: "vp9", Profile: "profile 0"}).result = true)
else
        supports4kcodec = false
end if

@@ebr

 

You can use the above to fix the official app. But you can see how blue neon was resilient enough to work through all the errors and eventually fallback to forced transcoding and played. The official app should be like this. Also, the error dialogs should not require to be dismissed by the user. They should just popup, use a sleep(3000) or so, and dismiss them, and fallback. Once the maximum amount of fallback attempts to work through errors is exhausted, you throw the final  dialog that explains all fallback retries are used up, what the last error was, and wait for the user to dismiss that one single dialog.

 

What I am guessing is the official app fallsback to transcode too, but is copying the hevc stream, not converting it to h264. So its fallback transcode looks alot like its direct. At least on the roku side of things. If it had after the remux failed, tried to use h264 as the video codec instead of hevc it would have worked.
 

Won't discuss the audio here, because audio support will not cause a video to fail to play. Lack of audio support produces silence. So audio is NOT a reason to fallback and is not considered.

 

Technically, there are 4 ways to fallback video:

 

1) direct - direct stream video in original container (untouched)

2) direct stream - direct stream video in new container (remux/container swap)

3) h264 transcode - transcoded video to h264 (...or stream copy h264 video)

4) h264 transcode low bitrate - transcoded video to h264 with maximum bitrate of video-1 (do not copy video stream - change video bitrate to avoid sever copying video stream)

 

Now there is a case where 2 and 3 can be the same. In the case of h264 video stream. In that case, you can skip method 3 if method 2 was already in h264 and go right to method 4 if you want. This will save a fallback. Now let me describe the fallback theory...

 

Now if we start in play method 1, the fallbacks are 2/3/4. If you start at 3 because capability wise the video is unsupported and transcoded to h264, then the fallback is 4. Once you reach the 4th fallback and more errors occur, this will still retry, but isn't technically falling back. So you set "error retries" at 10. If the item direct plays, the first 3 retries will change the fallback play method. Then the next 6 errors will simply respawn the player with the 4th method used every time. The 10th error pops up the dialog the user must dismiss. That dialog explaining "This is the 10th retry we are at the limit!" and what the last error was. This is the way it should be. There needs to be a maximum fallback retry setting that directly co-relates to it. Only expose the maximum retries if the person puts the app in debug mode or similar. Food for thought. Maybe even on the 10th error dialog the user dismisses the dialog with a button called "Stop Trying" and next to it is a button called "Try Again" and this ups the maximum retry count by 1, and lets the user let an 11th error retry occur. As long as the user keeps pressing "Try Again" button it keeps going. But once they hit stop trying it is done. The maximum retries setting isn't raised by the "Try Again" button. The try again, is its own variable that is added to the maximum, which will allow it to go above maximum. I know you understand where I am going. In this way more of the flow is automatic, and less human interaction needs to occur. Less button presses. More watching, less interaction.

Edited August 20, 2018 by speechles

[syralk 12]

I get it now. It is a roku mistake. One that.. maybe I should inform roku.co forums exists.. but there is a way to work around it..

 

device = CreateObject("roDeviceInfo")
if FindMemberFunction(device, "CanDecodeVideo") <> invalid then
        supports4kcodec = (device.CanDecodeVideo({ Codec: "hevc" }).result = true or device.CanDecodeVideo({ Codec: "vp9"}).result = true)
else
        supports4kcodec = false
end if

 

Here is the present detection routine to add hevc and vp9 support. Notice it is just seeing if the GPU returns true for the codec, not throwing profiles and such at it. This method used to work for all roku models. Since 8.1.x firmware releases it seems any GPU with hevc/vp9 present but unused (because of poor core/thread count limitations on the GPU) will show hevc/vp9 as a codec and return true for the code above. 

 

Notice the 4k support line on your first screen shot. This is done by also giving the hevc and vp9 codecs a profile and such, not just their codec names. This proves to actually detect support correctly. So the fix, is to.. also add this to the initial detection, shown below.

 

device = CreateObject("roDeviceInfo")
if FindMemberFunction(device, "CanDecodeVideo") <> invalid then
        supports4kcodec = (device.CanDecodeVideo({ Codec: "hevc", Profile: "main", Level: "5.1" }).result = true or device.CanDecodeVideo({ Codec: "vp9", Profile: "profile 0"}).result = true)
else
        supports4kcodec = false
end if

@@ebr can use this to fix the official app. But you can see how blue neon was resilient enough to work through all the errors and eventually fallback to forced transcoding and played. The official app should be like this. Also, the error dialogs should not require to be dismissed by the user. They should just popup, use a sleep(3000) or so, and dismiss them, and fallback. Once the maximum amount of fallback attempts to work through errors is exhausted, you throw the final  dialog that explains all fallback retries are used up, what the last error was, and wait for the user to dismiss that one single dialog.

 

Do you think it will be possible to add a "Force transcode hevc" & "Force transcode vp9" in the setting, just a tough

Edited August 20, 2018 by syralk

[speechles 1917]

Do you think it will be possible to add a "Force transcode hevc" & "Force transcode vp9" in the setting, just a tough

 

To the "official app"? Don't hold your breath waiting. That was the entire reason for explain my fallback theory for playing through errors and making the app more resilient and smarter. If they do this and use what I described there is no need for forcing things. The app will keep working itself down the play method tree until it finds which will let the media play without creating errors. 

[syralk 12]

To the "official app"? Don't hold your breath waiting. That was the entire reason for explain my fallback theory for playing through errors and making the app more resilient and smarter. If they do this and use what I described there is no need for forcing things. The app will keep working itself down the play method tree until it finds which will let the media play without creating errors.

Thanks

I see they did an update on the beta that replay the video in case of error but you still see the popup error

 

 

Sent from my ONEPLUS A3000 using Tapatalk

Edited August 20, 2018 by syralk

[ebr 14912]

Please see if this is any different in the current beta.

 

Thanks.

[syralk 12]

Please see if this is any different in the current beta.

 

Thanks.

ok this what happen now with the beta 3.0.99 on roku express 3900

- click on Episode 1

- the loading pogress bar appear

- go back to the menu with the popup video ignore error message

- then I wait 

- then the loading progress bar appear again with trans coding on the server side

 

note: the popup error message is there until I press ok to remove it

sugestion: it will be nice to not show the error message on the fiest loading and just retry

[ebr 14912]

sugestion: it will be nice to not show the error message on the fiest loading and just retry

 

Yes, I think that's what we'll do.

 

Thanks.

[ebr 14912]

Wait... it already should only be showing the error if it has exhausted its retries.

 

Are you sure it was the same episode that played and not the next one?

[syralk 12]

Wait... it already should only be showing the error if it has exhausted its retries.

 

Are you sure it was the same episode that played and not the next one?

I disabled the AUTO PLAY NEXT EPISODE

 

So if I Disable  "AUTO PLAY NEXT EPISODE

------------------------------------------------------------

- click on Episode 1

- the loading pogress bar appear

- go back to the menu with the popup video ignore error message

- then I wait 

- then the loading progress bar appear again 

- the Episode 1 play

------------------------------------------------------------

 

So if I Enabled  "AUTO PLAY NEXT EPISODE

------------------------------------------------------------

- click on Episode 1

- the loading pogress bar appear

- go back to the menu with the popup video ignore error message

- then I wait 

- then the loading progress bar appear again

- then the Episode 2 play

------------------------------------------------------------

[ebr 14912]

Where, exactly, are you playing from?  Because "click on Episode 1" would not play it...

[syralk 12]

I think what it can do it

whe we play

Press on PLAY

disable play next episode automatic

try play Episode 1

if fail : force tanscode Episode 1

When video play : enable play next episode automatic if it was enable

[syralk 12]

Where, exactly, are you playing from?  Because "click on Episode 1" would not play it...

I'm play it from Roku Express 3900 express

on my local network

[syralk 12]

Where, exactly, are you playing from?  Because "click on Episode 1" would not play it...

i sent you some screen shot to help you

[syralk 12]

Wait... it already should only be showing the error if it has exhausted its retries.

 

Are you sure it was the same episode that played and not the next one?

On the beta 3.0.100

With auto play on its still skip to the episode 2.

But with the auto play off its good. I see the error message but it go away by itself.

 

 

Sent from my ONEPLUS A3000 using Tapatalk

[ebr 14912]

On the beta 3.0.100

With auto play on its still skip to the episode 2.

But with the auto play off its good. I see the error message but it go away by itself.

 

 

Sent from my ONEPLUS A3000 using Tapatalk

 

The only explanation I have there is that maybe the player is re-trying on its own...

[syralk 12]

The only explanation I have there is that maybe the player is re-trying on its own...

Yes

With auto play next episode, when the episode is done usually it will play the next one.

But I can just disable this feature and it's all good.

It could be a good idea to disable it by default.

 

Sent from my ONEPLUS A3000 using Tapatalk

[bardmaster 17]

Hi - I do not know if you are discussing a different issue but I am constantly getting the Video Error: Ignored message during Live TV playback and this looked like the place to post it.

 

Roku Ultra

Emby Version 3.6.0.2 beta (I had this on the stable releases too)

I just sent a log file for user Matrix.

 

It should be noted that this beta release appears to be more stable (i.e. fewer instances during playback) as the current stable release.

ffmpeglog.txt

embyserver.txt

Edited August 30, 2018 by bardmaster

[ebr 14912]

I found a bug in the app that would affect error recovery on subsequent item playback. It won't address this specifically, but could have an impact so please re-test with beta 3.0.102.

[syralk 12]

I had the same issue and the update fix the issue

Thanks

 

Sent from my ONEPLUS A3000 using Tapatalk

[syralk 12]

Nop did not fix it for the live TV but its not happening every time and when it work the stream get transcode

 

Sent from my ONEPLUS A3000 using Tapatalk

[bardmaster 17]

I still got the error today, but was watching a ballgame with friends so wanted to restart right away without sending logs etc.

[timnop 1]

I am also getting Video Error Ignored frequently when watching Live TV. How can I get the latest beta for Roku?

[Luke 37062]

@@timnop let's look at an example. Please attach the information requested in how to report a problem:

https://emby.media/community/index.php?/topic/739-how-to-report-a-problem/

Thanks.

[bardmaster 17]

Hi, I am currently running Emby Server Version 3.6.0.49 beta along with the Emby beta Roku channel, and have not experienced the "Video error: ignored" problem for about two weeks now.  Will keep everybody posted, but we've watched a few 3-hour sports events in that time with no problem.

[ebr 14912]

Yes, Speechles worked hard to improve the app's playback failure routines such that this should basically never happen again.  It will try every way possible to recover from errors and just give up if none of them work.