DASH unprotected content stuck on the first frame on Samsung Tizen 5.5

[darktasevski]

@joeyparrish I have a potentially similar issue, both to #3046 and to #2620. Basically in a few of several attempts, the DASH stream fails to start properly, it's just stuck on the first frame, but can be initiated if the user seeks forward.

From the logs, I can see that the Shaka player has detected a stall, and tries to unstall by pause/play, but with no success.

Only reproducible on Tizen 5.5 (2020). I've been testing on model: UE43TU7072UXXH, but it's reproducible on other 5.5 models as well.

Shaka player version: 3.1.2

The stream where this can be reproduced (not consistently): https://trailers.redbox.com/assets/211568/dash/211568.mpd

And it's not specific to this DASH stream, can be reproduced with others as well, I think that it's happening a bit more often with it.

Logs:

Details

Shaka player config:

{
	streaming: {
		ignoreTextStreamFailures: true,
		// https://shaka-player-demo.appspot.com/docs/api/tutorial-network-and-buffering-config.html
		bufferingGoal: 60,
		// how much to buffer while the video is playing, to have enough content in case of network hiccups
		rebufferingGoal: 3,
		// how much to buffer before resuming playing, aka on video start and after seeking video
		bufferBehind: 30,
		jumpLargeGaps: true,
		stallSkip: 0.1,
		retryParameters: {
			maxAttempts: 10,
			baseDelay: 1000,
			backoffFactor: 1.75,
			fuzzFactor: 0.5,
			timeout: 10000,
		},
	},
	manifest: {
		dash: {
			ignoreMinBufferTime: true,
		},
		retryParameters: {
			maxAttempts: 5,
			baseDelay: 1000,
			backoffFactor: 2,
			fuzzFactor: 0.5,
			timeout: 25000,
		},
	},
	drm: {
		servers: getDrmLicenseServers(),
		advanced: {
			'com.widevine.alpha': {
				videoRobustness: 'SW_SECURE_CRYPTO',
				audioRobustness: 'SW_SECURE_CRYPTO',
			},
			'com.microsoft.playready': withAltTVODDrmConfig
				? {
						distinctiveIdentifierRequired: true,
						sessionType: 'persistent-license',
				  }
				: {},
		},
		retryParameters: {
			maxAttempts: 5,
			baseDelay: 1000,
			backoffFactor: 2,
			fuzzFactor: 0.5,
			timeout: 10000,
		},
	},
	restrictions: {
		minHeight: 360,
	},
	preferredAudioChannelCount: 6,
}

I've also tried playing with the default configuration instead of the one above, and the issue persists. The content sometimes starts playing after some time, but I could not reproduce this consistently. Also, looks like there is a lot of calls to switch after the shaka player loads the content:

13:01:41.638 mathRound.install
13:01:41.642 MediaSource.install
13:01:41.645 Using native MSE as-is.
13:01:41.649 VideoPlayPromise.install
13:01:41.652 Using native VTTCue.
13:01:41.656 MediaCapabilities: install
13:01:41.659 MediaCapabilities: Native mediaCapabilities support found.
13:01:42.060 mathRound.install
13:01:42.073 MediaSource.install
13:01:42.076 Using native MSE as-is.
13:01:42.079 VideoPlayPromise.install
13:01:42.081 Using native VTTCue.
13:01:42.084 MediaCapabilities: install
13:01:42.087 MediaCapabilities: Native mediaCapabilities support found.
13:01:43.912 Starting attach...
13:01:45.306 Starting load of https://trailers.redbox.com/assets/212464/dash/212464.mpd...
13:01:45.433 Found variant with audio and video content, so filtering out audio-only content.
13:01:45.482 codecs avc1-mp4a avg bandwidth 8596000
13:01:45.543 init: completed initial Stream setup
13:01:45.567 After load:  https://trailers.redbox.com/assets/212464/dash/212464.mpd
13:01:52.201 Calling switch_(), bandwidth=1048 kbps
13:01:52.210 switch_
13:01:52.218 switch: switching to Stream (video:6)
13:01:52.233 switch: Stream (audio:8) already active
13:02:00.656 Calling switch_(), bandwidth=826 kbps
13:02:00.667 switch_
13:02:09.045 Calling switch_(), bandwidth=987 kbps
13:02:09.057 switch_
13:02:17.317 Calling switch_(), bandwidth=951 kbps
13:02:17.329 switch_
13:02:25.496 Calling switch_(), bandwidth=934 kbps
13:02:25.507 switch_
13:02:34.148 Calling switch_(), bandwidth=891 kbps
13:02:34.158 switch_
13:02:42.549 Calling switch_(), bandwidth=898 kbps
13:02:42.560 switch_
13:02:51.073 Calling switch_(), bandwidth=891 kbps
13:02:51.086 switch_
13:02:59.432 Calling switch_(), bandwidth=856 kbps
13:02:59.443 switch_
13:03:07.906 Calling switch_(), bandwidth=844 kbps
13:03:07.917 switch_
13:03:16.035 Calling switch_(), bandwidth=819 kbps
13:03:16.047 switch_
13:03:24.335 Calling switch_(), bandwidth=850 kbps
13:03:24.348 switch_
13:03:33.144 Calling switch_(), bandwidth=822 kbps
13:03:33.157 switch_
13:03:41.333 Calling switch_(), bandwidth=807 kbps
13:03:41.348 switch_
13:03:49.476 Calling switch_(), bandwidth=808 kbps
13:03:49.489 switch_
13:03:57.587 Calling switch_(), bandwidth=808 kbps
13:03:57.599 switch_
13:04:05.866 Calling switch_(), bandwidth=796 kbps
13:04:05.876 switch_
13:04:14.165 Calling switch_(), bandwidth=747 kbps
13:04:14.176 switch_
13:04:22.345 Calling switch_(), bandwidth=731 kbps
13:04:22.357 switch_
13:04:30.521 Calling switch_(), bandwidth=732 kbps
13:04:30.531 switch_
13:04:39.179 Calling switch_(), bandwidth=706 kbps
13:04:39.196 switch_
13:04:47.848 Calling switch_(), bandwidth=659 kbps
13:04:47.863 switch_
13:04:56.334 Calling switch_(), bandwidth=699 kbps
13:04:56.344 switch_
13:05:04.836 Calling switch_(), bandwidth=700 kbps
13:05:04.846 switch_
13:05:13.258 Calling switch_(), bandwidth=715 kbps
13:05:13.267 switch_
13:05:21.740 Calling switch_(), bandwidth=662 kbps
13:05:21.750 switch_
13:05:30.741 Calling switch_(), bandwidth=704 kbps
13:05:30.749 switch_
13:05:39.415 Calling switch_(), bandwidth=694 kbps
13:05:39.424 switch_
13:05:47.876 Calling switch_(), bandwidth=655 kbps
13:05:47.885 switch_
13:05:56.757 Calling switch_(), bandwidth=631 kbps
13:05:56.768 switch_
13:06:05.725 Calling switch_(), bandwidth=656 kbps
13:06:05.734 switch_
13:06:14.687 Calling switch_(), bandwidth=664 kbps
13:06:14.697 switch_
13:06:23.384 Calling switch_(), bandwidth=645 kbps
13:06:23.394 switch_
13:06:31.451 Calling switch_(), bandwidth=620 kbps
13:06:31.459 switch_
13:06:40.143 Calling switch_(), bandwidth=625 kbps
13:06:40.152 switch_
13:06:48.708 Calling switch_(), bandwidth=638 kbps
13:06:48.719 switch_
13:06:57.602 Calling switch_(), bandwidth=625 kbps
13:06:57.613 switch_
13:07:05.908 Calling switch_(), bandwidth=600 kbps
13:07:05.918 switch_
13:07:14.040 Calling switch_(), bandwidth=623 kbps
13:07:14.053 switch_
13:07:22.273 Calling switch_(), bandwidth=622 kbps
13:07:22.282 switch_
13:07:30.844 Calling switch_(), bandwidth=547 kbps
13:07:30.855 switch_
13:07:39.932 Calling switch_(), bandwidth=550 kbps
13:07:39.944 switch_
13:07:48.012 Calling switch_(), bandwidth=543 kbps
13:07:48.024 switch_
13:07:56.416 Calling switch_(), bandwidth=584 kbps
13:07:56.428 switch_
13:08:05.005 Calling switch_(), bandwidth=595 kbps
13:08:05.017 switch_
13:08:13.812 Calling switch_(), bandwidth=534 kbps
13:08:13.829 switch_
13:08:20.219 Jumping forward 0.033 seconds because of gap before start time of 0.033
13:08:21.137 (all): seeked: buffered seek: presentationTime=0.033
13:08:25.570 Jumping forward 0.033 seconds because of gap before start time of 0.033
13:08:25.596 (all): seeked: buffered seek: presentationTime=0.033
13:08:27.965 Calling switch_(), bandwidth=534 kbps
13:08:27.972 switch_

In the log above, the playback started after 6 minutes... Because of this, I would say that this is also related to #3076.

Any suggestion on how to debug/fix this would be much appreciated.

Originally posted by @Puritanic in https://github.com/google/shaka-player/issues/3046#issuecomment-901113523

[joeyparrish]

We don't have a Tizen 5.5 device to debug this ourselves.

I suspect our entire stall-detection/gap-jumping system needs to be rethought: the requirements, the platform behaviors we observer, how the system gets triggered, and how it tries to cope with stalls & gaps. (See #3673)

In the meantime, though, you can experiment with changes to the source to see if there is a platform-specific workaround we could merge. See this code:

https://github.com/google/shaka-player/blob/7c81b0b3f779bcec90b58afce332935d2f2670cf/lib/media/playhead.js#L500-L511

This is configured by streaming.stallSkip. You may also want to play with this parameter, which defaults to 0 on TV platforms. Try small values like 0.1 and see if this helps. Also try setting streaming.jumpLargeGaps to true.

[avelad]

Can you test with v4.3.4? Thanks!

[github-actions[bot]]

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