MEDIA_ERR_DECODE errors are being thrown by rxPlayer when starting the stream #1464
Comments
|
Hi @TomaszKowalik, Is this only happening on one type of STB device? Is it only happening at the start of the stream or also during playback and do you have a frame visible on the stream before? |
|
Yes, it's issue that occurs only on that one STB. The time doesn't matter. It seems to be happening only at the start of the stream, and there is no frame visible on the screen. Maybe that's also important: that STB has an Opera browser. |
|
The RxPlayer loads a lot of segment at the start of a stream - I can see 12 requests of both audio and video segments in your logs (not surprising but I'm searching for causes). Maybe is it linked to a memory usage peak and poor memory management on that STB? Or something else linked to the larger amount of data communicated at the start of the stream? We could test by setting a very low For the:
You had once, the error tell us that the real issue is the |
|
I changed it, but this didn’t result in any improvement :( I also disabled video tracks entirely with For comparison with other players, I was only able to test it with dash.js on that box, and I wasn’t able to reproduce the issue with it. Oh, and today, during tests, one time i've seen movie frame (VOD stream), and then error occured and it kicked me out from the stream |
|
OK :/ Maybe is it DRM-related instead? I see that the issue is triggered not long after the license is pushed ( We could play with the amount of time taken for the different requests (e.g. through the Because of the 1/5 reproducibility, it seems to be linked to some time-based conditions, |
|
Indeed, it looks like the first segments were being pushed before receiving the license. I delayed pushing segments for some custom amount of time to ensure that the license is acquired, and every time the stream started correctly. However, I did it in a somewhat messy way (as I wanted to check it quickly): we have a custom segment loader implemented only for one environment, and I simply delayed the entire logic there. In other environments, we are not using custom segment and manifest loaders... Do we have any influence on RxPlayer to make it wait for the license before pushing segments? |
|
🎉 OK we found it. That's very interesting, because we know of another, french-only device (a set-top box provided by a french ISP) with a similar logic. After exchanging verbally with them, we found out that they on purpose introduced a timeout between the time an encrypted segment is pushed on the buffer and the time at which the license is pushed. They did this on purpose, so a generic error can be displayed on the screen by the JS application (which would think that there's something wrong with the media being played) instead of potentially having a spinner displayed on the screen for a long time (in which case people would have higher probability to blame their ISP instead - which of course they do not want :P) Because their timeout was high (close to 10 seconds), we never actually reproduced the issue but still, we were against it and it's against our comprehension of the EME recommendations. So we made our case and as a result it may be fixed on their side (this subject is on-going, but on their side for now). For your issue, if you have some way to communicate with the people doing the browser integration (especially the DRM-related logic) on that device, it could be a good solution to exchange with them about the issue. If it's not something you can do, we may have to find another solution like only pushing encrypted segments only once the related license has been pushed. Doing so should be less efficient (longer loading times) than what we're doing now but most of all I fear that it might be hard to maintain. |
|
Thanks, I'll try to reach out to the STB devs, but it's still quite confusing to me because, as I mentioned before, we were using that box with rx for some time, and it was working fine. This is quite a new issue, and I don't think there was any firmware or browser update on that box that could have triggered it. 🤔Anyway I'll try to get some more info on that topic |
|
@peaBerberian I don't want to open another almost identical issue, so I'll add it to that one. |
If it was incompatibility of DRM systems, it would probably either be an There's here several things that are weird, we first begin at position Then a license is pushed and that's the point at which it fails on a We also have some experimental development where we would only push segment we know to be decipherable (#1488) we could test here, like for the initial issue. |
|
As far as I know, the entire data should be decipherable here. I'm waiting for the device vendor's response on DRM support, as I'm not 100% clear on that matter. The weird part is that it happens quite randomly, and I’ve never seen it on the first attempt to play the asset, but that might just be because I was lucky... |
OK, maybe they have a bug when reusing If it doesn't fix it, we have other work-arounds a little more drastic, as we've often seen some device-specific DRM bugs linked to the device poorly handling decryption setup staying on for multiple contents. |
|
Ah we are using that option already :( Maybe lets try some other workaround? |
|
Do you know how to update the RxPlayer dependency locally? It will be faster to iterate that way. Though it can be simple in many use cases (just updating the built files) sometimes bundlers add things like caches which mess up with this, but we can add console log calls to check if updates have been taken into account. So if you can, we may want to just restart negotiation of all decryption mechanisms on each zap, by updating
Those are the built files, so you should then just have to build and test your application. You can also add a |
|
If that update doesn't change anything, we may do the same thing with |
|
@peaBerberian Actually, we are not using imports, but our player abstraction for Rx relies on an |
|
Nice! Can you test again just with You're seeing this on Philips TVs? Only specific models? We could target the specific platforms to provide a safer default for those TVs, and provide an option for the rest. |
|
It also seem to be working. This particular device is Philips with TitanOS, its 2023 NT690 4K, but they have different models, and there is a great chance its the issue for all of them... We are detecting that tv group via userAgent, by searching for "WhaleTV" |
Based on #1510, the idea behind this proposal is to add to our config properties allowing to force toggles we for now only enable for specific devices. The goal is to simplify the debugging of issues seen on specific devices (which is the huge majority of them), by just having to update the config in the corresponding application (as proposed by #1510). So for example let's say that we encounter a new device where relying on the same `MediaKeys` instance for multiple contents may fail after a time (bug encountered on LG's WebOS, on some Panasonic TVs, and now, in issue #1464, on Philips's TitanOS), we could just initially tell application people to try setting that experimental flag. If it fixes the issue, we will add a supplementary device check inside the corresponding compat function. This seems faster and less bothersome to me than having to create special builds of the RxPlayer, and there our role could just be to redirect the developer seeing the issue to the right config option (as opposed to having to build a player, then link that player to the application, making sure that their CI like us etc.).
|
From what I've just seen, "WhaleTV" may also refer to Whale TV OS, which seems to be a different OS? Maybe it's a new case of putting every previous mention in the user-agent to work-around user agent detection... If it's TitanOS-specific, I would be more comfortable checking against a |
Fixes #1464 There's a new device (after LG and Panasonic TVs) which seems to have issues when relying on the same `MediaKeys` instance on multiple contents, which are Philips's TitanOS it has on its 2024 models. So I disable the possibility for them here. I still have to check if it works because I took as user-agent something I found a little randomly on the web. Note that disabling re-usage of the `MediaKeys` instance will mean no in-memory `MediaKeySession` caching, which is a trick we use to both speed up loading a previous content and preventing to much requests on the license server also when doing that. But we know most other players don't seem to do such tricks and the speed up is not that much noticeable, so that shouldn't be a big issue.
|
Right, hmm not 100% sure on that topic but I think its rather |
Fixes #1464 There's a new device (after LG and Panasonic TVs) which seems to have issues when relying on the same `MediaKeys` instance on multiple contents, which are Philips's TitanOS it has on its 2024 models. So I disable the possibility for them here. I still have to check if it works because I took as user-agent something I found a little randomly on the web. Note that disabling re-usage of the `MediaKeys` instance will mean no in-memory `MediaKeySession` caching, which is a trick we use to both speed up loading a previous content and preventing to much requests on the license server also when doing that. But we know most other players don't seem to do such tricks and the speed up is not that much noticeable, so that shouldn't be a big issue.
|
From what I can read, I don't see any link between whaleOS and TitanOS :/ So maybe they just rely on the same browser integration, which has the same bug, that they ported on both? From what I found, "Philips NetTV" seems to be their application running a web browser on the device, and it seems to be in the user-agent in both, so they may rely on that software when embedding applications with a browser. I could try checking for that one, maybe also checking for |
Based on #1510, the idea behind this proposal is to add to our config properties allowing to force toggles we for now only enable for specific devices. The goal is to simplify the debugging of issues seen on specific devices (which is the huge majority of them), by just having to update the config in the corresponding application (as proposed by #1510). So for example let's say that we encounter a new device where relying on the same `MediaKeys` instance for multiple contents may fail after a time (bug encountered on LG's WebOS, on some Panasonic TVs, and now, in issue #1464, on Philips's TitanOS), we could just initially tell application people to try setting that experimental flag. If it fixes the issue, we will add a supplementary device check inside the corresponding compat function. This seems faster and less bothersome to me than having to create special builds of the RxPlayer, and there our role could just be to redirect the developer seeing the issue to the right config option (as opposed to having to build a player, then link that player to the application, making sure that their CI like us etc.).
|
Ah, perhaps that's the case! I went through some old docs, and there was a proposal for the |
|
OK thanks! That documentation comes from Philips? (Which may explain why the |
|
As I can see it comes from TP Vision, so basically from Philips |
Fixes #1464 There's a new device (after LG and Panasonic TVs) which seems to have issues when relying on the same `MediaKeys` instance on multiple contents, which seems to be Philips's NETTV (both 2023 and 2024 devices seem to have the issue as far as we know, and they advertise completely different operating systems, so instead we identified the culprit as "NETTV", which seems to be the web browser application Philips developed for their TVs and which is present on web applications' user agent on those devices). So I disable the possibility for them here. I still have to check if it works because I took as user-agent something I found a little randomly on the web. Note that disabling re-usage of the `MediaKeys` instance will mean no in-memory `MediaKeySession` caching, which is a trick we use to both speed up loading a previous content and preventing to much requests on the license server also when doing that. But we know most other players don't seem to do such tricks and the speed up is not that much noticeable, so that shouldn't be a big issue.
Fixes #1464 There's a new device (after LG and Panasonic TVs) which seems to have issues when relying on the same `MediaKeys` instance on multiple contents, which seems to be Philips's NETTV (both 2023 and 2024 devices seem to have the issue as far as we know, and they advertise completely different operating systems, so instead we identified the culprit as "NETTV", which seems to be the web browser application Philips developed for their TVs and which is present on web applications' user agent on those devices). So I disable the possibility for them here. I still have to check if it works because I took as user-agent something I found a little randomly on the web. Note that disabling re-usage of the `MediaKeys` instance will mean no in-memory `MediaKeySession` caching, which is a trick we use to both speed up loading a previous content and preventing to much requests on the license server also when doing that. But we know most other players don't seem to do such tricks and the speed up is not that much noticeable, so that shouldn't be a big issue.
Fixes #1464 There's a new device (after LG and Panasonic TVs) which seems to have issues when relying on the same `MediaKeys` instance on multiple contents, which seems to be Philips's NETTV (both 2023 and 2024 devices seem to have the issue as far as we know, and they advertise completely different operating systems, so instead we identified the culprit as "NETTV", which seems to be the web browser application Philips developed for their TVs and which is present on web applications' user agent on those devices). So I disable the possibility for them here. I still have to check if it works because I took as user-agent something I found a little randomly on the web. Note that disabling re-usage of the `MediaKeys` instance will mean no in-memory `MediaKeySession` caching, which is a trick we use to both speed up loading a previous content and preventing to much requests on the license server also when doing that. But we know most other players don't seem to do such tricks and the speed up is not that much noticeable, so that shouldn't be a big issue.
Fixes #1464 There's a new device (after LG and Panasonic TVs) which seems to have issues when relying on the same `MediaKeys` instance on multiple contents, which seems to be Philips's NETTV (both 2023 and 2024 devices seem to have the issue as far as we know, and they advertise completely different operating systems, so instead we identified the culprit as "NETTV", which seems to be the web browser application Philips developed for their TVs and which is present on web applications' user agent on those devices). So I disable the possibility for them here. I still have to check if it works because I took as user-agent something I found a little randomly on the web. Note that disabling re-usage of the `MediaKeys` instance will mean no in-memory `MediaKeySession` caching, which is a trick we use to both speed up loading a previous content and preventing to much requests on the license server also when doing that. But we know most other players don't seem to do such tricks and the speed up is not that much noticeable, so that shouldn't be a big issue.
|
Thanks, I opened #1515 to try fixing it, it should be easy to backport to our v3. |
|
Great, thanks! We are currently using |
|
We're more likely going to make another pre-release, with the same kind of syntax, once this is merged. I'll communicate here the version. |
|
Thanks! |
Fixes #1464 There's a new device (after LG and Panasonic TVs) which seems to have issues when relying on the same `MediaKeys` instance on multiple contents, which seems to be Philips's NETTV (both 2023 and 2024 devices seem to have the issue as far as we know, and they advertise completely different operating systems, so instead we identified the culprit as "NETTV", which seems to be the web browser application Philips developed for their TVs and which is present on web applications' user agent on those devices). So I disable the possibility for them here. I still have to check if it works because I took as user-agent something I found a little randomly on the web. Note that disabling re-usage of the `MediaKeys` instance will mean no in-memory `MediaKeySession` caching, which is a trick we use to both speed up loading a previous content and preventing to much requests on the license server also when doing that. But we know most other players don't seem to do such tricks and the speed up is not that much noticeable, so that shouldn't be a big issue.
Based on #1510, the idea behind this proposal is to add to our config properties allowing to force toggles we for now only enable for specific devices. The goal is to simplify the debugging of issues seen on specific devices (which is the huge majority of them), by just having to update the config in the corresponding application (as proposed by #1510). So for example let's say that we encounter a new device where relying on the same `MediaKeys` instance for multiple contents may fail after a time (bug encountered on LG's WebOS, on some Panasonic TVs, and now, in issue #1464, on Philips's TitanOS), we could just initially tell application people to try setting that experimental flag. If it fixes the issue, we will add a supplementary device check inside the corresponding compat function. This seems faster and less bothersome to me than having to create special builds of the RxPlayer, and there our role could just be to redirect the developer seeing the issue to the right config option (as opposed to having to build a player, then link that player to the application, making sure that their CI like us etc.).
Based on #1510, the idea behind this proposal is to add to our config properties allowing to force toggles we for now only enable for specific devices. The goal is to simplify the debugging of issues seen on specific devices (which is the huge majority of them), by just having to update the config in the corresponding application (as proposed by #1510). So for example let's say that we encounter a new device where relying on the same `MediaKeys` instance for multiple contents may fail after a time (bug encountered on LG's WebOS, on some Panasonic TVs, and now, in issue #1464, on Philips's TitanOS), we could just initially tell application people to try setting that experimental flag. If it fixes the issue, we will add a supplementary device check inside the corresponding compat function. This seems faster and less bothersome to me than having to create special builds of the RxPlayer, and there our role could just be to redirect the developer seeing the issue to the right config option (as opposed to having to build a player, then link that player to the application, making sure that their CI like us etc.).
Based on #1510, the idea behind this proposal is to add to our config properties allowing to force toggles we for now only enable for specific devices. The goal is to simplify the debugging of issues seen on specific devices (which is the huge majority of them), by just having to update the config in the corresponding application (as proposed by #1510). So for example let's say that we encounter a new device where relying on the same `MediaKeys` instance for multiple contents may fail after a time (bug encountered on LG's WebOS, on some Panasonic TVs, and now, in issue #1464, on Philips's TitanOS), we could just initially tell application people to try setting that experimental flag. If it fixes the issue, we will add a supplementary device check inside the corresponding compat function. This seems faster and less bothersome to me than having to create special builds of the RxPlayer, and there our role could just be to redirect the developer seeing the issue to the right config option (as opposed to having to build a player, then link that player to the application, making sure that their CI like us etc.).
Based on #1510, the idea behind this proposal is to add to our config properties allowing to force toggles we for now only enable for specific devices. The goal is to simplify the debugging of issues seen on specific devices (which is the huge majority of them), by just having to update the config in the corresponding application (as proposed by #1510). So for example let's say that we encounter a new device where relying on the same `MediaKeys` instance for multiple contents may fail after a time (bug encountered on LG's WebOS, on some Panasonic TVs, and now, in issue #1464, on Philips's TitanOS), we could just initially tell application people to try setting that experimental flag. If it fixes the issue, we will add a supplementary device check inside the corresponding compat function. This seems faster and less bothersome to me than having to create special builds of the RxPlayer, and there our role could just be to redirect the developer seeing the issue to the right config option (as opposed to having to build a player, then link that player to the application, making sure that their CI like us etc.).
Fixes #1464 There's a new device (after LG and Panasonic TVs) which seems to have issues when relying on the same `MediaKeys` instance on multiple contents, which seems to be Philips's NETTV (both 2023 and 2024 devices seem to have the issue as far as we know, and they advertise completely different operating systems, so instead we identified the culprit as "NETTV", which seems to be the web browser application Philips developed for their TVs and which is present on web applications' user agent on those devices). So I disable the possibility for them here. I still have to check if it works because I took as user-agent something I found a little randomly on the web. Note that disabling re-usage of the `MediaKeys` instance will mean no in-memory `MediaKeySession` caching, which is a trick we use to both speed up loading a previous content and preventing to much requests on the license server also when doing that. But we know most other players don't seem to do such tricks and the speed up is not that much noticeable, so that shouldn't be a big issue.
Based on #1510, the idea behind this proposal is to add to our config properties allowing to force toggles we for now only enable for specific devices. The goal is to simplify the debugging of issues seen on specific devices (which is the huge majority of them), by just having to update the config in the corresponding application (as proposed by #1510). So for example let's say that we encounter a new device where relying on the same `MediaKeys` instance for multiple contents may fail after a time (bug encountered on LG's WebOS, on some Panasonic TVs, and now, in issue #1464, on Philips's TitanOS), we could just initially tell application people to try setting that experimental flag. If it fixes the issue, we will add a supplementary device check inside the corresponding compat function. This seems faster and less bothersome to me than having to create special builds of the RxPlayer, and there our role could just be to redirect the developer seeing the issue to the right config option (as opposed to having to build a player, then link that player to the application, making sure that their CI like us etc.).
Fixes canalplus#1464 There's a new device (after LG and Panasonic TVs) which seems to have issues when relying on the same `MediaKeys` instance on multiple contents, which seems to be Philips's NETTV (both 2023 and 2024 devices seem to have the issue as far as we know, and they advertise completely different operating systems, so instead we identified the culprit as "NETTV", which seems to be the web browser application Philips developed for their TVs and which is present on web applications' user agent on those devices). So I disable the possibility for them here. I still have to check if it works because I took as user-agent something I found a little randomly on the web. Note that disabling re-usage of the `MediaKeys` instance will mean no in-memory `MediaKeySession` caching, which is a trick we use to both speed up loading a previous content and preventing to much requests on the license server also when doing that. But we know most other players don't seem to do such tricks and the speed up is not that much noticeable, so that shouldn't be a big issue.
|
@peaBerberian |
Based on #1510, the idea behind this proposal is to add to our config properties allowing to force toggles we for now only enable for specific devices. The goal is to simplify the debugging of issues seen on specific devices (which is the huge majority of them), by just having to update the config in the corresponding application (as proposed by #1510). So for example let's say that we encounter a new device where relying on the same `MediaKeys` instance for multiple contents may fail after a time (bug encountered on LG's WebOS, on some Panasonic TVs, and now, in issue #1464, on Philips's TitanOS), we could just initially tell application people to try setting that experimental flag. If it fixes the issue, we will add a supplementary device check inside the corresponding compat function. This seems faster and less bothersome to me than having to create special builds of the RxPlayer, and there our role could just be to redirect the developer seeing the issue to the right config option (as opposed to having to build a player, then link that player to the application, making sure that their CI like us etc.).
Based on #1510, the idea behind this proposal is to add to our config properties allowing to force toggles we for now only enable for specific devices. The goal is to simplify the debugging of issues seen on specific devices (which is the huge majority of them), by just having to update the config in the corresponding application (as proposed by #1510). So for example let's say that we encounter a new device where relying on the same `MediaKeys` instance for multiple contents may fail after a time (bug encountered on LG's WebOS, on some Panasonic TVs, and now, in issue #1464, on Philips's TitanOS), we could just initially tell application people to try setting that experimental flag. If it fixes the issue, we will add a supplementary device check inside the corresponding compat function. This seems faster and less bothersome to me than having to create special builds of the RxPlayer, and there our role could just be to redirect the developer seeing the issue to the right config option (as opposed to having to build a player, then link that player to the application, making sure that their CI like us etc.).
Based on #1510, the idea behind this proposal is to add to our config properties allowing to force toggles we for now only enable for specific devices. The goal is to simplify the debugging of issues seen on specific devices (which is the huge majority of them), by just having to update the config in the corresponding application (as proposed by #1510). So for example let's say that we encounter a new device where relying on the same `MediaKeys` instance for multiple contents may fail after a time (bug encountered on LG's WebOS, on some Panasonic TVs, and now, in issue #1464, on Philips's TitanOS), we could just initially tell application people to try setting that experimental flag. If it fixes the issue, we will add a supplementary device check inside the corresponding compat function. This seems faster and less bothersome to me than having to create special builds of the RxPlayer, and there our role could just be to redirect the developer seeing the issue to the right config option (as opposed to having to build a player, then link that player to the application, making sure that their CI like us etc.).
Based on #1510, the idea behind this proposal is to add to our config properties allowing to force toggles we for now only enable for specific devices. The goal is to simplify the debugging of issues seen on specific devices (which is the huge majority of them), by just having to update the config in the corresponding application (as proposed by #1510). So for example let's say that we encounter a new device where relying on the same `MediaKeys` instance for multiple contents may fail after a time (bug encountered on LG's WebOS, on some Panasonic TVs, and now, in issue #1464, on Philips's TitanOS), we could just initially tell application people to try setting that experimental flag. If it fixes the issue, we will add a supplementary device check inside the corresponding compat function. This seems faster and less bothersome to me than having to create special builds of the RxPlayer, and there our role could just be to redirect the developer seeing the issue to the right config option (as opposed to having to build a player, then link that player to the application, making sure that their CI like us etc.).
Hi
We have one STB device on which rxPlayer throws errors when starting the stream. But not always. During my tests, I was getting that error about once per 5 tries. It was happening for both VOD and live content. For live content, sometimes the player catches up and starts playing stream after the error, but not always. I tried DASH + WV and DASH + PR, and I was receiving that error for both combinations. I was getting it for 3.31 and 3.29 rx versions
I was also able to gather some logs:
What might be the reason for these errors? In the manifest I can see that for audio codecs are
codecs="mp4a.40.2"and for video, depending of representation:I tried to set
player.setMaxVideoBitrate(0)but it didnt solved the issue...Btw, once I got :
Stream: audio Stream crashed. Stopping playback. t: MediaError (BUFFER_APPEND_ERROR) InvalidStateError: Failed to execute 'appendBuffer' on 'SourceBuffer': The HTMLMediaElement.error attribute is not null.error
The text was updated successfully, but these errors were encountered: