-
Notifications
You must be signed in to change notification settings - Fork 112
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Recently uploaded videos do not play at 720p with mpeg-dash disabled #302
Comments
Same here. Kodi 19.4, Windows 10 |
So today I had the idea to replicate kodi's behavior on mpv, which, as you may all know, uses yt-dlp to resolve youtube's urls.
Notice the ids 22 and 18, which are respectively the 720p and 360p versions of the video, which in turn are the qualities used by the addon when mpeg-dash is disabled. So, playing id 22 with mpv resulted it this... mess and the video did not even start
Meanwhile, playing id 18 in the same way had zero issues
As expected, the video does not play at 720p in kodi too, while it plays with no issues at 360p. This, imho, means that youtube's api is seriously messing things up for recent videos at 720p. So, this is definitely not an issue of the addon but a bs of the api. Thus, I let the devs decide if the issue can be closed and if the addon must make mpeg-dash mandatory. p.s. Yt-dlp above is still on v2022.05.18. i.e. the previous version after today's latest v2022.06.22. |
New test because I got the upgrade to yt-dlp v2022.06.22.1 earlier this morning.
|
And I just came across a video that fails to play even on 360p! Kodi's log, where it does not say it is on 360p
and mpv's log for id 18
Well, at least it plays on 144p... which is a 3gp file at 6fps, yes SIX fps. Sony ericsson k750 memories :D In other news, a similar issue has been reported to yt-dlp, ~1 month before my issue here. |
Can anyone confirm that this issue still exists? Since then, I have set youtube to play at 720p with mpeg dash disabled and I have not seen the issue for at least 2 or 3 months (that is as far as I can recall). |
Closing it, as I can no longer verify it in either kodi or mpv. |
It just happened on a random vid that was uploaded recently. Here is the log's output
The video does not start even after MINUTES of waiting and the issue does not occur when selecting 360p or any mpeg-dash option. Likewise, on mpv
I tried many other videos that were uploaded recently but all of them worked fine. I will not reopen the issue until I find a second one that does the same. I am fed up with those idiots at youtube and their lastest changes in the api :( p.s. I noticed that a similar issue was opened, #426, was opened yesterday. However, since the contents of its log seem different than the one above, I am reporting my issue here. |
2+ (almost 3) weeks after that video was uploaded and it finally plays as it should! Last time I had checked it was during the weekend and it was still throttling, so something has changed on their end those last couple of days. Thank you youtube! /s |
No description provided. |
Context
Please provide any relevant information about your setup
Expected Behavior
Videos should play at 720p, which is the max resolution available when mpeg-dash is set to disabled.
Current Behavior
When a video is selected, the loading circle appears as usual but the video does not start and kodi instantly returns to the menu where all videos are listed. This happens only on recently uploaded videos, which play with no issue after 1-2 days.
Moreover, right clicking on a video, selecting "ask for resolution" and then "720p" has no effect. Selecting 360p (the second highest resolution with mpeg-dash disabled) makes the video play... but at 360p.
Steps to Reproduce
Log
The following is from 2 days ago, from a video of jerryrig, which was uploaded 4 days ago (counting today). Today, the video plays as usual
Additional Information
Obviously, enabling mpeg-dash solves the forementioned issue, but I think it is some api bs from youtube's end.
The issue is also confirmed with a friend running 19.4 on w10.
The text was updated successfully, but these errors were encountered: