ytdl-js / react-native-ytdl

A YouTube downloader for React Native

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Error: Could not find player config

deepak-jha-kgp opened this issue · comments

Getting the following error on a large number of devices. The issue is not device/network/video-specific, happens on any device randomly.
Error: Could not find player config
Please let me know if you need any help from me in solving this. The number of the affected devices is increasing each minute, almost 40% (around 30k) of my users seem to be affected by this.

I haven't encountered this error but I did not test on a lot of videos. Could you check to see if this issue is still there on the latest version?

I've tested on a few devices and rolled it out to production. Will keep you updated. Thanks.
Also, I've noticed that 404 on some videos problem is back again since version 3.4.1

I am facing the same issue
Error: Could not find player config

This error never occurred in past, it started to pop up for the last 4-5 days.
Is it related to youtube-dl DMCA takedown?
If yes, what is the workaround for it?

@AbelTesfaye : This issue still occur with latest version: 3.4.2

const urls = await ytdl(youtubeURL, { quality: 'highestaudio' });
=> always throw error: Could not find player config

please help us fix this issue. thank you!!!

The issue is not video-specific. Some videos work well on some devices while throws this issue on some.
Uninstalling and reinstalling the app solves the issue for some people, for some it doesn't. Couldn't identify any pattern yet on the basis of device/video/android version/region.
Could this be because of any asynchronous calls anywhere(just thinking out loud)?

I saw some issues mentioning this error on the previous version of node-ytdl-core. I'm not sure but rebasing to their latest version might fix it.

There were a bunch of new changes/moved files, so it might take a while. I'll probably review and import the new changes over the weekend.

@AbelTesfaye If you have the task plan ready and some help on what to achieve.

We can try to fix it.

I've previously written some sort of a "mini-guide" before, you can find it here.

During development, if you encounter any issues or have any doubts/questions feel free to send them in this thread.

Updated :)

Thanks for this @AbelTesfaye

In the latest update, I notice some of the itags are returning non-dowloadable urls(even for non-DASH and non-HLS streams).
These formats are returning a new param type": "FORMAT_STREAM_TYPE_OTF", on getInfo . I'm not sure how can we access resources in those URLs. To reproduce please try the following link
https://youtu.be/4kF6sTSgkDk itags : 160, 133
Any ideas on what is happening here?

Ah yes, videos with FORMAT_STREAM_TYPE_OTF don't usually work. Most YouTube stream extractor libraries just ignore formats that have this parameter. You should filter them out as well. Maybe you should open an issue at node-ytdl-core to let them know this edge case isn't handled.

Ohh okay. In that case, the latest update reduced the number of available streams. We get OTF for 144p, 240p and 480p now.

YouTube recently made some changes in their website, I guess you might need to wait a while till the node library can extract the smaller video formats, after that I can port it to react-native

I don't think it is because of changes on the youtube website. The previous version of the library is still returning usable URLs.

Oh, I guess the shorter formats array is probably caused by the HLS and DASH streams. They are now grouped by url and not by itag as before (before v4.0.0)

No, the problem is with non DASH and non-HLS streams

Some formats might not be getting detected properly. I'll take check it out, hopefully it can be fixed soon

The last version which had all the formats was 3.4.2 right?

Hey @AbelTesfaye. Were you able to reproduce the issue? Any ideas what is happening here?

@deepak-jha-kgp I found a bug that prevented DASH streams from being available. But you seem to be missing non-DASH streams so I don't think this bug affects you.

I tested several videos with both v3.4.2 and v4.0.4 and both return the same formats (v3.4.2 didn't have the FORMAT_STREAM_TYPE_OTF parameter). Could you send videos where the two versions return different formats?

This is fixed in the latest update. Thanks