Handling Recovering After Stalls on Tizen

[skipness]

Have you read the FAQ and checked for duplicate open issues? Yes

What version of Shaka Player are you using? 2.4.7

Can you reproduce the issue with our latest release version? Yes

Can you reproduce the issue with the latest code from master? Yes

Are you using the demo app or your own custom app? Custom app

If custom app, can you reproduce the issue using our demo app? Yes

What browser and OS are you using? Tizen 3 & Tizen 4

For embedded devices (smart TVs, etc.), what model and firmware version are you using? UA40MU6310 (Tizen 3 / Software Version: T-KTMDCNC - 1262.0)
UA43NU7100 (Tizen 4 / Software Version: T-KTM2LDCNC - 1202.6)

What are the manifest and license server URIs? I cannot provide, sorry.

What did you do?

1. Play stream on TV

2. Make some seek by changing currentTime

What did you expect to happen?
After seeking, stream can be play smoothly

What actually happened?
Sometimes stream will be stall after seeking, stream resume normal after trigger a play/pause or seek again.

I found that the fix suggested from #1704 can fix the above issue too by adding the following code in stall_detector.js:

if (shaka.util.Platform.isTizen()) { return false; }

[kevinscroggins-youi]

I have also seen video stalls on Tizen TVs with very specific firmware that the normal stall detection handling did not fix. We were able to recover playback by pausing and then trying to play the video again, and as such we ported the stall detection code app-side and changed the stall handling to pause and play the video instead. Sounds similar to what you are seeing, so perhaps it may be of interest to introduce separate handling for stall handling on Tizen versus any other platform that invokes a pause / play on the player, unless there is a better solution.

[kevinscroggins-youi]

Also, you may want to update your ticket as you have listed the TV models instead of the actual firmware information. You will want to go to Settings / Support / About this TV to retrieve this information. :)

[vaage]

Thank you @skipness for filing this issue. Thank you @kevinscroggins-youi for helping out.

I am putting together a change that will make the stall detector configurable via Player.configure. My hope is this will make these types of problems easier to work around and allow the community to experiment with different configurations, allowing us to find the ideal configuration for different platforms.

The three configurable attributes I am looking to expose are:

• Enabled : A flag for whether or not the player should initialize and use a stall detector.
• Threshold : The number of seconds that must pass without progress before firing the stall-event.
• Skip : The number of seconds to skip forward after a stall-event.

@skipness, what do you think of this solution? Since we don't have a good way to reproduce TV issues, once the change has been submitted, I will likely rely on you to verify that it allows you to work around the issue on Tizen.

[skipness]

@kevinscroggins-youi Thanks for reminding, I have updated the ticket.
@vaage This solution sounds good. Sure! Once the change is out, I will test it and update you.

[vaage]

@skipness, the change has been submitted, so the configuration should be available.

Here are the calls that you can use to change the various elements of it. Could you play with different values and left us know which combination worked best on TIZEN?

// Default settings
player.configure('streaming.stallEnabled', /* enabled= */ true);
player.configure('streaming.stallThreshold', /* seconds= */ 1.0);
player.configure('streaming.stallSkip', /* seconds= */ 0.1);

[shaka-bot]

Closing due to inactivity. If this is still an issue for you or if you have further questions, you can ask us to reopen or have the bot reopen it by including @shaka-bot reopen in a comment.

[kevinscroggins-youi]

@vaage Great! Thank you for this! Unfortunately based on my experience, the current method of recovering from stalls does not work on Tizen. The only thing that did work was pausing and after a 1tick delay, playing the video. I'm not sure if there is a better solution, but it would appear as though Tizen may require special handling for this situation. In our case, we only observed this behaviour specifically when backgrounding and restoring our application on a very specific 2018 Tizen TV. We have two other 2018 Tizen TVs that did not exhibit this behaviour. Hope this information is useful. I'm not entirely confident that this feature will fully resolve this issue.

[kevinscroggins-youi]

@shaka-bot reopen

[vaage]

@kevinscroggins-youi in your original post, you said that not using stall detection resolved the issue for you. Is that still a viable option for you? If so, the configuration exposed the option for you to disable it when running on Tizen. If not, what is missing from Shaka Player to handle your use case?

[skipness]

@vaage
Hey sorry for late response. I think the default setting is good enough for now, seeking seems working perfectly.

[kevinscroggins-youi]

@vaage I did not, that was @skipness who indicated that disabling the stall detector fixed the stall from occurring. In my case, having the stall detector with alternate behaviour for pausing and then quickly playing the video fixed the stall on my end. I was experiencing a stall when restoring the application from the background on DRM encoded VOD playback specifically. I only saw it on a single 2018 device, so I will try to track that device down and test with this fix early next week and get back to you. Thanks for the follow up!

[kevinscroggins-youi]

@vaage I tested our app using the latest version of Shaka on the affected 2018 TV and it appears that the video playback no longer stalls on startup in general, so perhaps some other change may have unintentionally fixed this. In any case, I think it's safe to say that this is definitely fixed. Thanks!