webOS 4032 error in compiled version but not debug version about shaka-player HOT 22 CLOSED

We have the same issue: 4032 with compiled version on webOS, but ok on Tizen and with debug version on webOS.

from shaka-player.

Ah, I see. JSON.parse returns the correct thing in every mode, but the compiler sees the type as something it can minify. So the compiled version would be something like:

const a = JSON.parse(window.PalmSystem.deviceInfo);
const b = a.b;
const c = a.c;

The solution is to move the parsed type to the externs or to use ['screenWidth'] to access instead of .screenWidth.

from shaka-player.

Once the PR is merged it, I'll release 4.8.3 asap.

from shaka-player.

Sorry, I don't think it's correct in the case of WebOS, looking at the specifications all versions since WebOS 3.0 support a minimum of 1080p: https://webostv.developer.lge.com/develop/specifications/video-audio-30

from shaka-player.

I can't say anything about the Hisense case, because I can't test it right now and I don't have access to its documentation, but I think it's the same case with WebOS. This is normally due (at least in Europe), because even if the TV is 720, the broadcast broadcasts can be at 1080 and have to support them.

from shaka-player.

We do not have a WebOS device to test, if you identify the PR that includes the regression, we can try to find the problem. Thank you!

from shaka-player.

Noted @avelad it is a bit tricky due to the nature of the issue.
Issue is only present in compiled version it affects all stream types.
Is there any guidance on what might have caused a regression in 4.8 that would cause webOS to fail only In compiled version?
Both debug and uncompiled perform as expected.
I was hoping the issue affecting us would be fixed in 4.7 as well which is the HLS AES over requesting as this affects all platforms including Samsung and web which would mean we are not reliant on upgrading to 4.8

from shaka-player.

Since it happens to many people, anyone who wants to contribute to fixing it, please do, we don't have WebOS in the lab to test. Thank you very much to all!

from shaka-player.

This issue is a bit of a needle in a haystack.
It also puts a pretty large stop to any support for webOS altogether as it affects all webOS regardless of stream type.
The fact that the issue is gone in any debug or uncompiled version makes logging anything quite difficult.
@avelad is there any PR you can think of that would cause such a dramatic effect for webOS?
🙏

from shaka-player.

Since it only happens in WebOS I don't know what to say...

from shaka-player.

Since almost all bufixes are ported to other branches, the ideal would be to start with features: https://github.com/shaka-project/shaka-player/releases/tag/v4.8.0

from shaka-player.

Seems to be occurring around the preload area maybe related to
#6271

from shaka-player.

preloadManager.start() is failing but only when compiled and not debug 🤔

from shaka-player.

Looking more into: feat: Add preload system to player #5897

from shaka-player.

Hopefully create a PR tomorrow.
For some reason in compiled version manifest filter is checking variants
allowedByApplication is false for all variants.
When using uncompiled or debug allowedByApplication is true.

from shaka-player.

@stuartflanagan can you review if #6180 introduce any error? Thanks!

from shaka-player.

Hi @avelad.
I have found the source of the issue and it is part of PR #6180
For some reason a compiled version accessing
JSON.parse returns undefined when accessing the properties.
But the Debug and Uncompiled version has access to the Parsed properties.

  const parsedDeviceInfo =
    /** @type {{screenWidth: number,screenHeight: number}} */
    (JSON.parse(deviceInfo));
  const screenWidth = parsedDeviceInfo.screenWidth;  // Is undefined in compiled Version
  const screenHeight = parsedDeviceInfo.screenHeight;  // Is undefined in compiled Version

I do not think this is a webOS issue but is potentially a compiler issue with JSON.parse?
Logging the parsed object shows all the properties and values seem good.
Accessing the property returns undefined, but only in non debug mode. 🤔

from shaka-player.

Thanks @joeyparrish that seems a lot easier than the REGEX I have just created to parse the deviceInfo 🤣
Any issue with using array notation over dot notation in this scenario? I am not sure how to access the externs.

from shaka-player.

Any chance this fix could go into an earlier release than 4.9?

from shaka-player.

@avelad & @joeyparrish I just had a question regarding this issue.
I saw Chromecast defaults to 720 in a new PR.
webOS does have devices with resolution of 720 out there as well. Should we drop default from 1080 to 720 for webOS as well?
I actually have a webOS 720 device here and playback is working as expected just not 100% sure 1080 minimum is safe.

from shaka-player.

Sorry to comment on this closed issue. Should I create
Maybe suggest for next PR something more in line with Tizen?

// WebOS has always been able to do 1080p.  Assume a 1080p limit.
      // Set reasonable defaults in case an issue occurs
      maxResolution.width = 1920;
      maxResolution.height = 1080;
      try {
        const deviceInfo =
        /** @type {{screenWidth: number, screenHeight: number}} */(
            JSON.parse(window.PalmSystem.deviceInfo));
        // WebOS has always been able to do 1080p.  Assume a 1080p limit.
        const screenWidth = deviceInfo['screenWidth'];
        const screenHeight = deviceInfo['screenHeight'];

        if(!isNaN(screenWidth) && !isNaN(screenHeight)){
          maxResolution.width =  screenWidth;
          maxResolution.height = screenHeight;
        }
      } catch (e) {
        shaka.log.alwaysWarn('WebOS: Error detecting screen size, default ' +
            'screen size 1920x1080.');
      }

Hisense also has 720 devices too.

from shaka-player.

Thank you for all your help with this @avelad!

from shaka-player.