Infinite loop on live content with discontinuities on Tizen

[jakubvojacek]

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

If the problem is related to FairPlay, have you read the tutorial?
its not related

What version of Shaka Player are you using?
latest, 4.10.9

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

Can you reproduce the issue with the latest code from main?
did not try

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

If custom app, can you reproduce the issue using our demo app?
its a tizen application

What browser and OS are you using?
Tizen/WebOS

For embedded devices (smart TVs, etc.), what model and firmware version are you using?
Tizen 5.5 (year 2020) and WebOS 2021 but we experience this issue on newer Tizens too.

What are the manifest and license server URIs?
its a live content which changes periodically (we autorestart the live packaging every 20 minutes orso because we autodetect too many gaps in the MPD). In order to get the working MPD url, please use following cURL

curl 'https://mw.motv.eu/public/channel/getStreamUrlV3' \
  -H 'sec-ch-ua: "Not)A;Brand";v="99", "Google Chrome";v="127", "Chromium";v="127"' \
  -H 'language: Y3M=' \
  -H 'sec-ch-ua-platform: "macOS"' \
  -H 'sec-ch-ua-mobile: ?0' \
  -H 'Authorization: Bearer glf40bnmzmmwiw85glre6gqy8qjjvnhy99g90ul8' \
  -H 'User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/127.0.0.0 Safari/537.36' \
  -H 'Content-Type: text/plain;charset=UTF-8' \
  -H 'Referer;' \
  -H 'devicesType: d2ViIHBsYXllcg==' \
  -H 'profilesId: Mjc0NDgz' \
  --data-raw '{"data": {"channelsId":383,"devicesIdentification":"Mac OS 10.15.7 Chrome 127","devicesHash":"1689914173"}}'

and use response.url.

What configuration are you using? What is the output of player.getConfiguration()?

we used default configuration, just initialize shaka and played the MPD, no DRM or additional changes were done.

What did you do?

We sometimes get reports from our customers about infinite looping on live tv channels only on Samsung. We managed to track these issues to MPD gaps in the MPD manifest. Those gaps can be caused for example by bad weather (we receive some of the inputs via satellite) or whatever. I understand that its a source problem and without the gaps, the player would play perfectly fine. But the thing is that its only Tizen that loops, we use other platforms, such as shaka-player in web, shaka-player on LG (webOS), exoplayer on android, av player on ios - and all these survives the gaps very nicely.

Since both web player and LG survives the gaps and do not loop and they share the same codebase and shaka player version and everything, it must be related somehow to how Samsung plays the content. I could share URLs to the real MPDs but the problem ocurrs few times a week only and therefore its very hard to debug on real channels. To simulate it better, I took sintel trailer, used python to simulate 0.001% packet loss and now I am playing the TS file in a loop with ffmpeg and I am using shaka-packager to package it to live dash. I manage to reproduce the issue on tizen this way within seconds of testing.

What did you expect to happen?

I would like for the playback to not loop. If you test the content I provided above, on tizen, it should start looping immediatelly. On LG it usually plays quite fine (but sometimes it gets stuck too, but majority of times it plays quite well). The damage to the stream is extreme compared to the actual live channels but this way its testeable quite quickly without having to wait for hours/days.

What actually happened?

The content loops on Tizen, does not loop in web/LG. If you could please guide me what I could test in order to make the playback on tizen more robust so that it would behave the same as on LG/web.

Are you planning send a PR to fix it?

I unfortunately have no idea what to change.

[jakubvojacek]

I now got an idea of making a static VOD from the damaged sintel demo. It might be easier for you guys to test with static content instead of live. The MPD is available here https://edge1.motv.eu/s1/vods/28/sintel-gaps-7107/66ab7059f1383-2632-mp4-clear.mpd

I just tested on both Tizen and WebOS and it does not start playing Tizen at all and plays normally on WebOS.

Thank you

[avelad]

Log that appears in the browser:
Jumping forward 0.001057 seconds because of gap before start time of 0.001057

[avelad]

I now got an idea of making a static VOD from the damaged sintel demo. It might be easier for you guys to test with static content instead of live. The MPD is available here https://edge1.motv.eu/s1/vods/28/sintel-gaps-7107/66ab7059f1383-2632-mp4-clear.mpd

I just tested on both Tizen and WebOS and it does not start playing Tizen at all and plays normally on WebOS.

Thank you

The bug could be somewhere in this function: https://github.com/shaka-project/shaka-player/blob/main/lib/media/gap_jumping_controller.js#L165, for example, can you investigate if the time is set correctly?

[jakubvojacek]

Hello @avelad

thank you for pointing me in some direction. I attempted to test it (it was tricky, first time compiling shaka player etc) and not very familiar with javascript actually.

I got some results, hopefully, you can point me further by looking at them. I added some logging

diff --git a/lib/media/gap_jumping_controller.js b/lib/media/gap_jumping_controller.js
index c2267f74a..8d47a37e3 100644
--- a/lib/media/gap_jumping_controller.js
+++ b/lib/media/gap_jumping_controller.js
@@ -202,6 +202,12 @@ shaka.media.GapJumpingController = class {
     const buffered = this.video_.buffered;
     const gapDetectionThreshold = this.config_.gapDetectionThreshold;
 
+    if (currentTime < 2) {
+      console.error(["myoutput",
+      currentTime, buffered, gapDetectionThreshold
+      ])
+    }
+
   

This is how it looked on LG (webos)

and this is Samsung (tizen)

(sorry for the pictures instead of plain text, TVs are a mess to debug, i just redirected console to div element to make debugging easier)

the main difference i see that on LG, there was some stall detected. That is a message that never appeared on tizen. In the source code, I read that stall detector could be disabled for some platforms, could be the case?

As you can see the tizen playback fails completely with 3016 error (media error = 3). I read on github that this could be related to negative DTS but the time is 0 and then 0.001, never negative.