search

anxdpanic / plugin.video.youtube

Watch your favorite YouTube content on Kodi
https://ytaddon.panicked.xyz/forum
672 stars 110 forks source link

Buffering Bug #163

Closed neo-neo1 closed 2 years ago

neo-neo1 commented 3 years ago

Several people have all recently reported this same issue at Kodi forums - YouTube Addon (last page). This is a reproducible problem. When playing videos from a playlist after 2-3 videos the next video that starts will buffer every several seconds.

I’m able to open a new video that won’t buffer but If I go back to the previous video which had buffering issues it will always have buffering issues unless I restart Kodi device or delete cache and database from YouTube addon settings.

This is not a network or device issue.

Edit: (Additional detail) It doesn’t only happen to videos in a playlist. Usually after watching several videos at random as well. After a Kodi restart I haven’t had the first video I opened buffer, usually after watching several.

In this YouTube Add-on settings I changed the cache size and video settings to every available option yielding the same result.

Been using this Addon since 1.0.

RNavega commented 2 years ago

Each base.js has a different n-transform function, and there are dozens of them. Emulating a single n-transform is not going to cut it - that's why you have to execute YT's JavaScript code on the fly if you want to solve this issue.

@gatecrasher777 what proof do you have that the n solver in ratebypass.py is generating a different value than the code in the watch page base.js?
From what I debugged, the input parameters change, but the unscrambling functions don't (at least for the time being).
There's a fixed set of functions from which only some are used on each base.js.

From my tests the n value that's calculated by ratebypass.py is the same as if you ran the JS code with the same inputs, so the solver is working, but as people have tested this isn't being enough, there should be something else (an obscure cookie?) we're missing to avoid the throttling punishment.

gatecrasher777 commented 2 years ago

I don't have proof that your n-solver and base.js n-solver are giving different results. However I can confirm that I am using the ytcog innertube library daily, and experience no throttled, sub 100KB/s downloads at all. Once the n parameter is transformed (running code extracted from the base.js player and with any signature deciphering if necessary) the streams download without throttling. Cookies are useful for getting the stream info (i.e. age restriction), but no cookies are needed (and are not used by ytcog) for downloading.

Obviously, you cannot just use any base.js code. It has to be the base.js associated with the youtube session from which you got the stream urls. If you don't provide a session context the base.js player to be used has to be extracted from each watch url response and can change from one video to the next. In ytcog I start a session and by providing the session context in each innertube info request the player never changes as long as the session is in progress. This may be why I am not seeing any throttling. However, before I added the n-transform I was experiencing throttling as described here and in most other youtube download/streaming projects. So the n-transform certainly is a large part, if not all, of the solution.

RNavega commented 2 years ago

I don't have proof that your n-solver and base.js n-solver are giving different results.

Just to be clear, I only ported the solver from pytube's cipher.py for it work inside plugin.video.youtube, including some minor changes.

It has to be the base.js associated with the youtube session from which you got the stream urls. If you don't provide a session context the base.js player to be used has to be extracted from each watch url response and can change from one video to the next.

I think this is what's done anyway, each time you play a video this plugin will ask for whatever base.js is given in the watch page: https://github.com/anxdpanic/plugin.video.youtube/blob/ed587646f5e4b0ff7cff0bfaefb74b6f0640d912/resources/lib/youtube_plugin/youtube/helper/video_info.py#L644

I tested it today and it was generating an incorrect n value because there's something new in the js transforming code. Paging @tfdahlin , the original author, as it may be relevant to them. The change is in here: https://github.com/anxdpanic/plugin.video.youtube/blob/74f6ccb603216076a1b4dcac7ad992c71ba6783f/resources/lib/youtube_plugin/youtube/helper/ratebypass/ratebypass.py#L60-L102

RNavega commented 2 years ago

@gatecrasher777 your ytcog project looks amazing, by the way.

DmnzH commented 2 years ago

Just tried using the latest revision of ratebypass.py and it seems to be working so far. No more throttling, thanks @RNavega

anxdpanic commented 2 years ago

alpha zips with @RNavega's (thanks again!) work is available, https://github.com/anxdpanic/plugin.video.youtube/releases/tag/6.x.x-dev

RNavega commented 2 years ago

@DmnzH thanks for testing.

This type of solution by reimplementing what the JavaScript code does is vulnerable to changes -- as soon as they update base.js it'll break.
So I've no idea for how long this'll work lol.

The ultimate solution would be to import something like js2py to execute the JS code of the n calculator directly, like @gatecrasher777 said.

DjDiabolik commented 2 years ago

I don't see this 6.18 alpha1 in the developer repo hosted on panicked.xyz..... it's normal ?

malversan commented 2 years ago

Testing plugin 6.18 alpha1 with @RNavega's work in Kodi 18.9.

The buffering pauses seem to have disappeared by now. Very good work.

Let's see if the solution shows to be robust and lasts enough to solve the problem permanently. In my case the throttling was affecting about 50% of videos loaded by any mean (Youtube list, search results, next video, Yatse sharing...), and often waiting or retrying did not help at all.

I use this plugin a lot. Thanks for the great work.

RNavega commented 2 years ago

It still seems to get throttled for me here and there, even though the n token is correct.

But anyway, at least we tried... hopefully someone drops by with some new insight.

191977 commented 2 years ago

The problems with buffering have disappeared for me completely with the alpha. Testing the second evening now. Was a pain in the ass before. Thank you guys.

DjDiabolik commented 2 years ago

I need to test this alpha18 also on my osmc setup........... download and need to installa manually...........

Feedback later or tomorrow........

Fludizz commented 2 years ago

The alpha18 build seems to have fixed it here as well. Previously we had to retry every video 3-4 times to get it to play. This evening, it has been playing everything perfectly fine. No more buffering issues! This is tested on LibreElec 9.2.8.

Thanks for all the great efforts!

DjDiabolik commented 2 years ago

Me feedback......installed right now the "plugin.video.youtube-unofficial-6.8.18.alpha1+matrix.1" on my Pi2 whit current osmc kodi19 build.

It's not fix the issue......... it even seems have obtain a worst result because first video i have tryed to reproduce whit this neweset 18alpha1 it's unplayable: Some time i obtain an errors says "Impossible to reproduce" other times it's be playable but it's all freeze and the buffers it's very slowly and it's never reach 100%.

I have tryed to many times to stop and retry to reproduce same video..... not resolve this issue.

I have to STOP and RESTART the reproduction of same video about 15 times to obtain this video watchable.........

EDIT At right now........ KODI crash whit SAD face at second video tryed to watch.

On kodi.old.log apparently there's no information about crash:

2021-10-05 21:27:22.805 T:735      INFO <general>: [plugin.video.youtube] Running: YouTube (6.8.18~alpha1+matrix.1) on Matrix (Kodi-19.1) with Python 3.7.3
                                                    Path: /
                                                    Params: {}
2021-10-05 21:27:23.376 T:735      INFO <general>: CPythonInvoker(6, /home/osmc/.kodi/addons/plugin.video.youtube/resources/lib/default.py): script successfully run
2021-10-05 21:27:26.174 T:735      INFO <general>: initializing python engine.
2021-10-05 21:27:26.181 T:735      INFO <general>: [plugin.video.youtube] Running: YouTube (6.8.18~alpha1+matrix.1) on Matrix (Kodi-19.1) with Python 3.7.3
                                                    Path: /special/new_uploaded_videos_tv_filtered/
                                                    Params: {}
2021-10-05 21:27:32.611 T:735      INFO <general>: CPythonInvoker(6, /home/osmc/.kodi/addons/plugin.video.youtube/resources/lib/default.py): script successfully run
2021-10-05 21:27:39.574 T:735      INFO <general>: initializing python engine.
2021-10-05 21:27:39.581 T:735      INFO <general>: [plugin.video.youtube] Running: YouTube (6.8.18~alpha1+matrix.1) on Matrix (Kodi-19.1) with Python 3.7.3
                                                    Path: /play/
                                                    Params: {'video_id': 'tHSNsHuPcOE'}
2021-10-05 21:27:40.858 T:735     ERROR <general>: /home/osmc/.kodi/addons/script.module.urllib3/lib/urllib3/connectionpool.py:1020: InsecureRequestWarning: Unverified HTTPS request is being made to host 'www.youtube.com'. Adding certificate verification is strongly advised. See: https://urllib3.readthedocs.io/en/latest/advanced-usage.html#ssl-warnings
                                                     InsecureRequestWarning,

2021-10-05 21:27:41.508 T:735      INFO <general>: CPythonInvoker(6, /home/osmc/.kodi/addons/plugin.video.youtube/resources/lib/default.py): script successfully run
2021-10-05 21:27:41.573 T:683      INFO <general>: VideoPlayer::OpenFile: plugin://plugin.video.youtube/play/?video_id=tHSNsHuPcOE
2021-10-05 21:27:42.041 T:810      INFO <general>: Creating InputStream
2021-10-05 21:27:42.168 T:810      INFO <general>: Creating Demuxer
2021-10-05 21:27:47.089 T:812     ERROR <general>: CCurlFile::FillBuffer - Failed: Transferred a partial file(18)
2021-10-05 21:27:47.090 T:812   WARNING <general>: CCurlFile::FillBuffer - Reconnect, (re)try 1
2021-10-05 21:27:47.438 T:812     ERROR <general>: CCurlFile::FillBuffer - Failed: Transferred a partial file(18)
2021-10-05 21:27:47.438 T:812   WARNING <general>: CCurlFile::FillBuffer - Reconnect, (re)try 2
2021-10-05 21:27:47.660 T:812     ERROR <general>: CCurlFile::FillBuffer - Failed: Transferred a partial file(18)
2021-10-05 21:27:47.660 T:812     ERROR <general>: CFileCache::Process - <https://r3---sn-uxaxpu5ap5-5vpe.googlevideo.com/videoplayback?expire=1633483659&ei=K6dcYd6GNf2C6dsP7_a8uAE&ip=95.250.10.110&id=o-ACySJcO9FKiWyPQYgmOGp4nkZuhiKvfTkAW7XxRA3mD_&itag=22&source=youtube&requiressl=yes&mh=nu&mm=31%2C29&mn=sn-uxaxpu5ap5-5vpe%2Csn-hpa7kn7e&ms=au%2Crdu&mv=m&mvi=3&pl=24&initcwndbps=1196250&vprv=1&mime=video%2Fmp4&ns=gcIfcYj_yfm1Lfbns6vh2lsG&cnr=14&ratebypass=yes&dur=586.977&lmt=1633458924359487&mt=1633460726&fvip=5&fexp=24001373%2C24007246&c=WEB&txp=5432434&n=ixn7CewL7oYWc7W1&sparams=expire%2Cei%2Cip%2Cid%2Citag%2Csource%2Crequiressl%2Cvprv%2Cmime%2Cns%2Ccnr%2Cratebypass%2Cdur%2Clmt&sig=AOq0QJ8wRQIgFJzL3DZ3DFGVRM0XLkbUDCU4av5bC6a-BolIxAtHVdUCIQCC5iGncDncQ6xwm6gG_kEkF45g_gdTv0lQs6jpq9lkdw%3D%3D&lsparams=mh%2Cmm%2Cmn%2Cms%2Cmv%2Cmvi%2Cpl%2Cinitcwndbps&lsig=AG3C_xAwRQIhAP-j8HV2mVgC0K8h067_1gr3yuCCmcFnK95150k4k4_tAiB-TzNswjx9SpcbafOu82RIaG9OinpWEhqraTuGQ1_lDw%3D%3D|Cookie=CONSENT%3DYES%2Bcb.20210615-14-p0.en%2BFX%2B294%3BVISITOR_INFO1_LIVE%3DFszAeA-2X8Y%3BYSC%3DLgAUdmo-9EE%3B> source read didn't return any data before eof!
2021-10-05 21:27:47.836 T:810      INFO <general>: Opening stream: 0 source: 256
2021-10-05 21:27:47.837 T:810      INFO <general>: Creating video codec with codec id: 27
2021-10-05 21:27:47.837 T:810      INFO <general>: CDVDVideoCodecDRMPRIME::Open - using decoder V4L2 mem2mem H.264 decoder wrapper
2021-10-05 21:27:47.874 T:810      INFO <general>: Creating video thread
2021-10-05 21:27:47.875 T:814      INFO <general>: running thread: video_thread
2021-10-05 21:27:47.879 T:810      INFO <general>: Opening stream: 1 source: 256
2021-10-05 21:27:47.879 T:810      INFO <general>: Finding audio codec for: 86018
2021-10-05 21:27:47.882 T:810      INFO <general>: CDVDAudioCodecFFmpeg::Open() Successful opened audio decoder aac
2021-10-05 21:27:47.882 T:810      INFO <general>: Creating audio thread
2021-10-05 21:27:47.883 T:815      INFO <general>: running thread: CVideoPlayerAudio::Process()
2021-10-05 21:27:47.885 T:810      INFO <general>: CVideoPlayer::OnExit()
2021-10-05 21:27:47.885 T:810      INFO <general>: VideoPlayer: eof, waiting for queues to empty
2021-10-05 21:27:47.885 T:810      INFO <general>: Closing stream player 1
2021-10-05 21:27:47.885 T:810      INFO <general>: Waiting for audio thread to exit
2021-10-05 21:27:47.893 T:815      INFO <general>: thread end: CVideoPlayerAudio::OnExit()
2021-10-05 21:27:47.894 T:810      INFO <general>: Closing audio device
2021-10-05 21:27:47.894 T:810      INFO <general>: Deleting audio codec
2021-10-05 21:27:47.894 T:810      INFO <general>: Closing stream player 2

EDIT 2 Reinstalled back the previous 6.8.17 from Kodi repo............... NO WORS. Today ever video it's pratically unwatchable......... buffering after buffering. What's append to youtube at right now ?

EDIT 3

And it's not a networks speed issue......... look this speedtest result:
osmc@osmc:~$ speedtest
Retrieving speedtest.net configuration...
Testing from Telecom Italia (95.250.10.110)...
Retrieving speedtest.net server list...
Selecting best server based on ping...
Hosted by Teleimpianti srl (Priverno) [204.60 km]: 40.999 ms
Testing download speed................................................................................
Download: 91.29 Mbit/s
Testing upload speed......................................................................................................
Upload: 20.05 Mbit/s
osmc@osmc:~$

My Pi2 it's connected to a FTTC whit a LAN cable.... about 100Mbps reach........

Simply youtube it's not works....... buffering after buffering.

EDIT 4 I see another strange things...... from the INFO CODEC of kodi when i obtain the buffering after buffering i can see the SKIP number reach 20 or 30 and the video start to buffering and never reach 100% and it's very slowly. Pratically all video it's unplayable............ i don't have idea how i can fix this issue right now.

pbo10 commented 2 years ago

plugin.video.youtube-6.8.18.alpha1+matrix.1 has fixed the issues for me, as per others recent comments I was having to restart every video 3-4 times before it would run without buffering and since I've upgraded all videos are running great. This is on Kodi 19.1 on Nvidia Shield.

Thanks for all the efforts to all involved.

DjDiabolik commented 2 years ago

plugin.video.youtube-6.8.18.alpha1+matrix.1 has fixed the issues for me, as per others recent comments I was having to restart every video 3-4 times before it would run without buffering and since I've upgraded all videos are running great. This is on Kodi 19.1 on Nvidia Shield.

Thanks for all the efforts to all involved.

so you confirm me that the youtube site it's working ok at right now ? If yes i can confirm the youtube addons it's not works on my osmc installation...... i don't have idea how i can to do to fix my issue.

pbo10 commented 2 years ago

Yea it's absolutely fine right now. Maybe try a VPN in case you got blacklisted by Youtube or something?

cooljimy84 commented 2 years ago

Just downloaded the alpha and have been fine again (an hours worth of my normal videos) Been watching in my normal way without slow downloads.

powerfrontier commented 2 years ago

Hello, I downloaded the last alpha yesterday and it worked great, but today it throttle two time on the same video.

El 5 de octubre de 2021 22:50:37 CEST, James Crook @.***> escribió:

Just downloaded the alpha and have been fine again. Been watching in my normal way without slow downloads.

-- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/anxdpanic/plugin.video.youtube/issues/163#issuecomment-934812890

-- Enviado desde /e/ Mail.

DjDiabolik commented 2 years ago

Yea it's absolutely fine right now. Maybe try a VPN in case you got blacklisted by Youtube or something?

Blacklisted ? Strange....... more than blacklist it seems as if the download speed is limited for me. But i have tryed to watch the same video from pc (using firefox) and it's works whitout any issue.

Could it be an API problem ? I can try to remove some cache or somethings similar for example from advance feature of the addons ?

pbo10 commented 2 years ago

Could it be an API problem ?

I'm not sure, looks like the fix works for most/a lot of people but not everyone unfortunately.

DjDiabolik commented 2 years ago

Could it be an API problem ?

I'm not sure, looks like the fix works for most/a lot of people but not everyone unfortunately.

it is likely that the operating system that kodi runs on itself makes a difference... also problably the architecture of the hardware (in my case arm) and maybe even the hardware itself. Anyway in this my specific case it's present somethings strange because i have also tryed to step backward and reinstall my previous version of addons and apparently the situation does not change.

mine seems like a generic problem whit youtube addons only.... very strange. it could also be the youtube italia site to have bandwidth problems....... lol.

jonisb commented 2 years ago

After updating to 6.8.18-alpha I've had two videos start to buffer but all others (100+ videos) have worked perfect, great job. Kodi crashed after the two videos started to buffer and I stopped them, so might be unrelated to this problem.

I did have a problem starting a live steam as Kodi crashed right away after I updated the plugin, but again it might not be related to the new update I'll post a new issue if I get a debug log.

Julian-nicolas commented 2 years ago

Hello. I want to install this alpha but it complains about xbmc.python 3.0.0 dependency problem. I tried to Google it but I only find pages recommending going back to kodi 18 because in the v19 the python version changes, I don't want to go back, but I can't find the way to install xbmc.python 3.0.0. Can I ask for some help?

I'm running kodi 19 on Debian bullseye on amd64

gc248 commented 2 years ago

6.8.18.alpha1 is working much better for me than the previous release, which had become worse over time. Still seeing a few videos buffering, but less frequently than before.

I've also noticed that videos seem to start playing much quicker than they have for a long time, regardless of if they go on to have buffering issues or not. This is a significant improvement.

Thanks again to everyone working on this.

(I'm running Kodi 18.9.0 on LibreELEC 9.2.6 on an Intel Compute Stick)

DmnzH commented 2 years ago

Hello. I want to install this alpha but it complains about xbmc.python 3.0.0 dependency problem.

Make sure you install the matrix build for Kodi v19.

Julian-nicolas commented 2 years ago

Hello. I want to install this alpha but it complains about xbmc.python 3.0.0 dependency problem.

Make sure you install the matrix build for Kodi v19.

Thanks for your reply, but I am indeed trying to install the matrix build, with no success.

DjDiabolik commented 2 years ago

For me it's also made kodi completely unstable.........

Today i have reboot everythings.... reboot my router and reboot my Pi2. Wait osmc completely boot......... Open youtube addons first video it's unwatchable and goes in buffering immediatelly after video shows up. For watch this video i have need to stop and re-open this same video about 5 or 10 times and only at certain times i have successfully watched this video.

Choosing a second video from "Things to See" and when try to watch this seconds video BAAM KODI goes in crash whit SAD FACE. After SAD FACE i have wait them back KODI it's brings up again......... retry about 5 time to reproduce same video and every time i tryed KODI goes in crash whitout any sense.

Some video it's pratically unwatchable for me.... the video made this crash it's this: https://www.youtube.com/watch?v=VTnrTp1XR4M

After the latest KODI Crash i have retry to reinstall a previous build......... but there's a lot of issue: -plugin.video.youtube-unofficial-6.8.17+matrix.1.zip previously it's ever works better.... right now it's not fix the issue just described. -The "latest" 6.8.16 from panicked repo it's not works at all.... when tryed to open a video i obtain errors and say to me to check kodi.log

At the end for me youtube it's become pratically unwatchable from my pi2 :(

If someone have some suggestion how i can check on my kodi setup every information it's accepted.

If also need i can try to activate the "Debug" level on "kodi.log" and try to reproduce this crash for know if some important things it's appears on it.......

DmnzH commented 2 years ago

Some video it's pratically unwatchable for me.... the video made this crash it's this: https://www.youtube.com/watch?v=VTnrTp1XR4M

Tested this on my machine with the alpha build and it plays fine without any issue. It could be you got a conflicting plugins or bad kodi installation. Maybe try to do a clean Kodi installation, or try it on another pc/device and see if it works.

DjDiabolik commented 2 years ago

Some video it's pratically unwatchable for me.... the video made this crash it's this: https://www.youtube.com/watch?v=VTnrTp1XR4M

Tested this on my machine with the alpha build and it plays fine without any issue. It could be you got a conflicting plugins or bad kodi installation. Maybe try to do a clean Kodi installation, or try it on another pc/device and see if it works.

I use a Raspberry Pi2 whit latest build of OSMC.... not a pc :) Bad installation of kodi ? Strange because all issue it's appear from one moment to the next without having touched anything and also other addons work without major problems.

When i speak about other addons for example i can cited DAZN also found here on github and developed by @Maven85 here: https://github.com/Maven85/plugin.video.dazn

Anyway i have posted this video only as example and apparently only because whit this i can reproduce the crash whit sad face apparently and i thinks it's related to buffering issue discussed here (kodi infact crash when i choose to reproduce a video when in theory the initial cashing procedure should start right ?).

Otherwise on this latest about 2 hours i have made a lot of check on my osmc setup and apparently i have made an important things........ i have add this: https://kodi.wiki/view/Advancedsettings.xml#network

I have add a advancedsettings.xml to my osmc setup..... whit a configuration like this: https://kodi.wiki/view/HOW-TO:Modify_the_video_cache#Example_4

I have reboot my Pi2 completely and testing some video....... apparently it's little better situation and i have tested the same video of "Riccardo Dose" and this time it's WORKS.... this time kodi it's not crashing and and I saw the video completely without major problems. After this i have tryed another lot of video and yes... buffering issue it's still present but whit this advancedsettings.xml apparently the situation it's slighty better. In some case i have also need to STOP and restart same video but but the situation has generally improved markedly.

Need so much test................

jmbreuer commented 2 years ago

I'm also experiencing buffering issues.

Using current 6.8.17+matrix.1 on Kodi Matrix 19.1.0, LibreELEC 10.0.0 Generic.x86_64.

There are videos that stop/buffer reproducibly for me - even at the exact same spots every time:

This one https://youtu.be/ifwtWF485HU hangs at timestamp 00:53 for 10-15 seconds, then again at 01:45 for a shorter amount, a few more times after that.

Here's the log:

https://paste.kodi.tv/uxedigayil.kodi

The first it stalls at line 519, and continues around line 538. Second stall is at lines 640 / 678.

For this video, the exact same thing happens when I use "Play (Ask for Quality)" and choose the 480p mpd.

At this point, it's unclear to me whether the problem would be located more within the add-on/Kodion, in the MPEG-DASH implementation (InputStreamAdaptive if I understand correctly), or Kodi core. I'm happy to dig deeper and welcome any pointers on where to maybe start looking.

There appears to be NO pre-buffering to speak of, despite my Kodi being configured to use 1.5 GB RAM for buffering and a read factor much larger than the default 4.0 - where the default already should pre-buffer this video much more aggressively. It seems that at least the read factor is not applied to this type of playback at all.

youtube-dl downloads the full stream within 30 seconds on my (not particularly fast) connection, producing a 31 MB output file. Obviously, it also plays without issues in a browser on this network.

I'd REALLY expect this small amount of video data to be fully and aggressively pre-buffered.

I see that Kodi passes one additional URL argument for the segment downloads as compared to youtube-dl: beids=9466585. With a quick google, I cannot find what that might mean. All the other segment URLs and their parameters look much identical, with slightly different encoding (youtube-dl encodes , in lists to %2C) and different signatures, obviously.

I am wondering whether there might be some relation to the ratebypass thing short-circuited this August since it'd stopped working, see issue #185.

pbo10 commented 2 years ago

@jmbreuer You need to update to the latest alpha 6.8.18.alpha1+matrix.1 which contains the latest fix for the buffering issue and seems to solve the issue for most.

jmbreuer commented 2 years ago

@jmbreuer You need to update to the latest alpha 6.8.18.alpha1+matrix.1 which contains the latest fix for the buffering issue and seems to solve the issue for most.

Thank you. I can confirm that 6.8.18.alpha1+matrix.1 fixes the above-mentioned video for me.

Still, the time bar shows it's pre-buffering only on the order of 1-2 seconds, FWIW.

jmbreuer commented 2 years ago

Still having buffering issues with 6.8.18.alpha1+matrix.1 and other videos, eg:

https://youtu.be/mszLi15FTJE

This one's higher bitrate, but my connection still has roughly 2-3 times the required bandwidth available. Log shows InputStreamAdaptive downloading with low avg speed, compared to youtube-dl. When playback resumes after a stall, the video seems to 'catch up' and play accelerated for a few seconds - like playback of a live stream that would be optimized for latency. Since this is not a live stream, this behavior is counterproductive.

Again, there's no pre-buffering to speak of; IMO allowing a larger read-ahead buffer to fill would immediately alleviate my issues. Is there any setting (or code location) I can tweak to influence the read-ahead buffer size / duration?

Also, no buffer filling appears to happen while playback is paused...

anxdpanic commented 2 years ago

iirc, inputstream.adaptive uses the internal buffer of roughly 7 seconds, don't believe there is any way to adjust this currently

DjDiabolik commented 2 years ago

I can add other info about my experieces whit the 6.8.18.alpha1+matrix.1 on my Pi2 osmc setup :)

In this last about 50/60 minutes i have correctly watched about 6/7 video from my kodi setup........... After i have applyed the advancedsettings.xml files apparently (but i don't want to sing victory too soon :) ) resolved the issue whit kodi crash whit sad face. however, it has not completely disappeared my issue/trouble whit "buffering"........ a few times after playing a video the next video it's buffered whitout any issue. Other time no..... i can see the very first about 10 seconds then the reproduction stopped and i can see (from "PlayerDebug" of Kodi) the download it's like stop and the buffering it's very very slowly. At this point i need to stop and sometimes i need to restart the same video about 2 or 3 times for obtain a complete view without blockages.

Having said that I add that in my case i'm choosing to not use MPEG DASH...... i have disabled it directly from setting... it's this a problems ? the recent fix only works if you use mpeg-dash?

arcaine2 commented 2 years ago

I'm also still having issue. Some videos play no problem, some are played in slow-motion once started, like this one https://www.youtube.com/watch?v=NaXzv7TM5T8 that failed to load correctly 6 times in a row, to then play fine at 7th attempt a minute later. I have MPEG-DASH disabled.

probonopd commented 2 years ago

Same here. The issue seems to persist in 6.8.18.alpha1, at least with some videos. Are we getting throttled?

grahammccann commented 2 years ago

Same issues here, thought it was because i went from Kodi 18 -> 19.1, on Android box, it seems to happen to all videos now.

DjDiabolik commented 2 years ago

@anxdpanic and for all member....

I have another question about this trouble.............. today and yesterday i have watched, and switched to many times from two different livestream on youtube. Both Livestream it's from "FPI Official Channel".... for example today i have watched so many times this two livestream: https://www.youtube.com/watch?v=uYO7ocuWQQA and this: https://www.youtube.com/watch?v=V4U15lA3BXU

Whit this livestream yesterday and also today i don't have obtain any problems/issue/trouble whit this buffering issue.

At this point my question it's............ it's this problems it's only related to a VOD video and it's not affects the vision of livestream ??

It's totally normal ?

grahammccann commented 2 years ago

I noticed too that livestreams seem to work fine.

bsdf commented 2 years ago

rpi4, osmc, kodi/19.1, 6.8.18.alpha here. not a whole lot to add here, but it definitely seems like a throttling issue. running the alpha, i'm seeing < 100 KB/s for the majority of the time with > 1 MB/s occasionally. other video apps can get > 4 MB/s. this is with and without mpeg-dash.

probonopd commented 2 years ago

This may be the solution:

https://github.com/ytdl-org/youtube-dl/issues/29326#issuecomment-938337251

If you look under the hood of official YT clients you will discover two things:

  • they default to 2097152 max chunk size.
  • they dont use standard HTTP range headers, standards are for others to follow, not for Google!

There is no "Range: bytes=". YT client appends "&range=0-xxx&rn=y&rbuf=z" to requested content URLs instead. rn goes up by 1 with every request, rbuf is less obvious, at this moment you can safely omit both and it still works. (...)

The correct solution (after generating correct &n) is to start using custom URL &range= parameters instead of normal HTTP range headers and default to downloading in 2MB chunks.

bsdf commented 2 years ago

i asked in the yt-dlp discord how they workaround it and it looks like @RNavega's thoughts regarding the android player were correct:

basically the throttling is because of a missing signature param which is generated by some complex JS code

afaik the current workaround is just using android player client instead of web, which avoids the throttling for now the alternative would be running the JS code using phantomjs or similar

We have tried using phantomjs, but the code was never published since it slows down yt-dlp significantly. Ideally, we can implement the decryption algorithm natively (like what we do for sig). But for now, the android workaround is sufficient and isnt expected to break in the near future.

probonopd commented 2 years ago

https://invidious.snopyta.org/ seems not to suffer from throttling. Wondering why.

Looks like they are also using Android, and are using INNERTUBE_API_KEY:

https://github.com/iv-org/invidious/pull/2220/files#diff-f8ae2508caf8eb3d260e47273d8b0d3d5b6b860c096d4b9fc9b2db12a323834aR843-R850

https://github.com/TeamNewPipe/NewPipeExtractor/issues/562#issuecomment-885503224

Fludizz commented 2 years ago

It seems something has changed at youtube again. Up until about an hour or two ago everything was working fine with 18alpha1 but since then every single video is hitting the buffering problem again and need to restart video's 3-4 times to get them to play.

pbo10 commented 2 years ago

No change here, the latest alpha with the fix is still working great and I haven't seen any buffering since updating including over the last few hours so I don't think it's anything updated by YouTube.

Fludizz commented 2 years ago

No change here, the latest alpha with the fix is still working great and I haven't seen any buffering since updating including over the last few hours so I don't think it's anything updated by YouTube.

Hmmm interesting... Some further testing seems to point to this only happening here on video's uploaded in the last couple of hours. Video's uploaded a few days (or longer) ago indeed still play just fine.

This one consistently fails to play though: https://www.youtube.com/watch?v=avQXnRsIosQ

gatecrasher777 commented 2 years ago

Emulating YT's JavaScript will work randomly with some YT players but not with others. Everyone in this thread could be downloading streams for different YT players. And they can change at any time. There are scores (possibly hundreds) of different player versions. What works for one might not work for another.

You may just have to locate and run the YT JavaScript code directly to fix this.

To quote @RNavega

This type of solution by reimplementing what the JavaScript code does is vulnerable to changes -- as soon as they update base.js it'll break. So I've no idea for how long this'll work lol.

The ultimate solution would be to import something like js2py to execute the JS code of the n calculator directly, like @gatecrasher777 said.

anxdpanic commented 2 years ago

I haven't seen any indication that this is caused by the player javascript (buffering with the alpha). When I am finally able, I will have to compare some new debug logs with the buffering videos to see which player javascript files were used and test them against the @RNavega's work. And I'll also look into the range post, see if there is any impact.

There are scores (possibly hundreds) of different player versions. What works for one might not work for another.

This type of solution by reimplementing what the JavaScript code does is vulnerable to changes -- as soon as they update base.js it'll break. So I've no idea for how long this'll work lol.

The cipher for playing music videos, etc is the same way.

js2py is likely to slow things down quite a bit, iirc this was tested for the cipher a long time ago when it broke. Then I tried implementing youtube-dl's version which was faster than js2py, and it was received negatively due to the performance of video start up. So I fixed and went back to our current implementation.