[Bug]: Network download and buffering is significantly slower compared to browser #3457
Comments
|
Definition to clarify: "1080p" means in my case 1080p60, 1080p30, 1080p23. Buffer underruns occur in all these 3 cases (even tho the contents bitrate varies). |
|
Have you configured a proxy in FreeTube? #3405 says that having a proxy configured in FreeTube slows stuff down a lot. |
|
I can confirm this behavior of the nightly builds, at least beginning with 2844, when i first tried out working with them 3 weeks ago because of an issue with the main 0.18.0 beta version because of a change Youtube did then. I think You have to ask me specific questions for getting the right informations, hope i can help... |
|
The same issue happens to me on the latest build (not nightly). The way I fixed it was using a socks5 proxy which made the bandwidth on par with browsers. To test this issue what I did was use 2 browser (chrome and firefox) and freetube + im using the same vpn ip for the tests. While checking the nerd stats of the same video on chrome and firefox I get 200k kpbs on th bandwidth. On freetube with the same ip and video I get 8k kbps which is drastically slower. The only fix I found was to use a socks5 proxy (which has the same ip as the vpn I'm using) and somehow it fixes it by going 200k kpbs on the bandwidth. On the nightly build sadly I cannot use this fix because the new method to use a proxy makes it worst than not having a proxy (100-200 kpbs) 50 times slower. @RevAngel7 are you using a vpn if so which one, could help find the issue |
|
Hello, and thank you all for your contributions. To answer the questions: Thank you again for you trying to help! |
|
I though i was going crazy when some youtube videos would load perfectly fine in 1080p but others not. |
|
Do you have any specific videos that this happens with? Every video I've tried so far has worked fine on my end in the nightly builds. |
|
I tested it yesterday to comment, it didn't work: exremely slow buffering with the nightlies, but 0.18.0 beta worked. Today, it just works with every version, thus also nightlies. I don't konw... |
|
Default Video Format and Allow AV1? |
Nearly every video, but some work, some work for initial buffering and underrun some time in. On the non-nightly versions it worked sometimes to press CTRL-R to refresh the video page, sometimes this had to be repeated. I guessed at that time that servers were chosen at each loading of the video, and probably one was faster - but that was just my guess.
DASH video formats (default). As per default settings AV1 was not checked (on). But since I have the necessary codecs (libaom3, libdav1d5) installed I will test it again with AV1 checked (on) and report the results later. By the way, I had these issues with the non-nighty versions too - maybe not as significant as on the nighy version I am using now. But I had to change the version since the non-nighty stopped working for me entirely. |
|
Turning AV1 on did not improve the issue. |
|
Hmm, today , again, it's not working with the nightlies, but v0.18.0 Beta is working. |
|
Changing to #2878 (freetube_0.18.0-nightly-2878_amd64.deb) and testing if that improves the issue. |
|
Pre-Buffering seems to work a bit better, but after that buffer-underruns occur as frequent as with the previous versions. |
|
Going back and forth between old stuff and new stuff won't make a difference, it's clearly a YouTube change but as we haven't been able to reproduce the issue on our end, we can't investigate and try to solve it. |
|
Okay, I get that. Strangely this issue now seems sporadic and unpredictable as well. I watched 10 videos now from various world news channels, and 5 of them went fine, 5 of them underrun. Should we keep this issue open to have an eye on user experiences? And would that help wit the investigation of the issue? |
|
Or: Maybe I can stay updated with the nighties and write a test update from time to time. And if some users find the same issue, they maybe can contribute information about it until the puzzle turns into a readable picture? |
|
Would be very useful if someone found a way to consistently reproduce this e.g. specific videos or that it happens more frequently on specific channels. Definitely keeping it open, because it's clearly an issue that multiple people are having so it's not just an issue with someone's setup, we just can't do anything about it until we have a way to reproduce the problem. |
Okay, lets work with that. Reproducing an issue that is as sporadic as this one is a pain, especially if it works fine on the dev's side (I worked on communications equipment and software in a lab, testing and fixing issues that were sporadic as well, with multiple carrier changes included to complicate puzzles). Let's gather more information from users to this issues until we maybe can get a clearer picture of the causes. Thank you for your effort and clear response, @absidue |
|
I find that this channel seems to have buffering underruns on most of the videos, is this the same for anyone else? |
|
At higher playback speeds (e.g. 3x), it can be consistently reproduced |
|
@Growebis @shaicoleman Are you both using the nightly builds? Tried both playing at 3x speed and videos from that channel on the nightlies, but unfortunately I still can't replicate it. |
|
@absidue , seems fixed on the nightly build (v0.18.0-nightly-2885 Beta) |
|
It got better, but is still underrunning buffering on 50% of 10 videos I tested. One video in particular went really bad. Buffer underruns nearly every (visual) cache segmentation (the red/gray bar under the video ;-) on 1x speed, 1080p from start to end of the video. Tested multiple times with a restart of the video from pos. 0:00 to 1:01. At least 6 countable underruns each try, 5 times video [audio still working, video stopped until buffer catches up] and one complete underrun [both audio and video stopped, buffer circle showing]. DASH format, AV1 activated). Watching this video on browser, the whole video was buffered in aprox. 1.5 seconds, no buffer underruns therefore. https://youtu.be/dm8wcJROo4c (Reuters - One dead, 23 wounded in Russian missile strike - 2023-04-27 - video length 1:01 minutes, 1080p file size: webm 19.1 MB, VP9 29.97 fps, opus 48KHz /// MP4 H.264, 22.9 MB, 29.97 fps, 2909 kbps, MPEG-4 AAC stereo, 44.1KHz, 127 kbps) This was tested with freetube_0.18.0-nightly-2885_amd64.deb |
|
I'm intermittently reproducing the reported behaviour on nightly #2844 and #2885. The videos in this playlist https://youtube.com/playlist?list=PL37EkmqQJzsjVlYSpzqLVAhATrDdGxmsZ mostly. Other channels / playlists don't reproduce it. It was so bad in https://www.youtube.com/watch?v=i3DwBAa1boY that I checked the issues and updated to #2885 which doesn't seem any better. Edit: repros on freetube-0.18.0-nightly-2885-setup-x64.exe |
|
I can confirm the issue from @scampsi on my setup with the video https://www.youtube.com/watch?v=i3DwBAa1boY . All 4 seconds only audio with a still picture from the video, until 7 seconds the audio buffer runs out, circling loading animation, next segment, after 4 seconds only audio, after 7 seconds full underrun. And so on and on. This was tested with freetube_0.18.0-nightly-2885_amd64.deb Compared to youtube in a firefox browser, the video buffers nearly 90 seconds instantly, no underruns occur there. |
|
Now using freetube-0.18.0-nightly-3064-setup-x64.exe. Is there any way to see any debug info as I try to play videos? The buffering on local dash format has got even worse the last few days. Most videos can't maintain playback in dash format 480p or above. Legacy format 720p and Firefox have no issues. I've seen this consistently over several days with nightly 3027 and 3064. >50 videos from various channels. VPN disabled or enabled and connected to various servers in 2 cities. AV1 enabled and disabled. Restarting FreeTube frequently. Win 10 64 bit fully updated. No heavy CPU, disk IO or network and lots of available RAM. One thing I've noticed is that if I restart FreeTube after each unsuccesful video playback attempt, there's maybe a 10%-20% chance that the video I wanted to watch will buffer normally. I can then switch from auto to 1080p with no issues. |
I've also been noticing that too. it feels like every video i watch is just stuck on buffering and i have to wait like a couple minutes for the video to be watchable only for it to buffer again. I can try throwing random youtube channels that i find buffer the most. Here are some: https://www.youtube.com/channel/UCbdbgaxLYyqYiSyGT3uDlFg |
|
I have this with every single video now. I only use "Open in YouTube" now. I wish there was an option to make this the default action when clicking on a thumbnail so I don't have to do one right-click, aim at "Open in YouTube" and then a left click. |
|
thanks for all of your recent reports, we are aware that youtube has made changes. there is already a pull request open with another temporary workaround (nothing is permanent with youtube frequently breaking things for us). |
|
Hi, Just wanted to chip in: After using several nightly builds, nothing worked fine. Even with invidious setup, with the latest nightly, the videos just didnt load. So I went back to the last official release from the freetube website, and everything works fine, with no invidious proxying required. 1080p loads instantly. |
|
Hi all, We've just made some changes that makes buffering much faster. Please test for yourself in the latest nightly build. |
|
Thanks for the update. Nice! |
|
freetube-0.18.0-nightly-3068-setup-x64.exe seems to have fixed my issues including 1080p 60fps playback |
Seems to work perfectly for now! Just curious, what was changed to fix it? |
|
@kurqshd941 a new throttling bypass |
|
I confirmed the issue was still happening before upgrading, installed the freetube-Setup-0.18.0-nightly-3076 and I can confirm the problem for me is fixed. Excellent work guys. |
Was it the user-agent being changed? |
|
@kurqshd941 no the user agent doesn't make a difference. we switched to using the android formats with a new magic params value when available (we still use everything else from the web response so that we aren't missing any information). Unfortunately when youtube breaks android stuff, they make it return errors (you get no useful information, not even the video description), for the web stuff it just loads really really slowly when they break it, so we've had to add a bunch of checks to fall back to the web ones, when youtube inevitably breaks that android bypass again. At least when DASH is throttled with the web one you can still use audio only just fine and the legacy formats work sometimes too. Basically another temporary workaround until YouTube inevitably breaks stuff again because they don't like third party clients. |
Thanks for the explanation. But why then is it, that v18.0 still works fine? Geertings, and thanks again for the effort. |
|
Thank you all for your valuable contributions! I was away a couple of days and installed freetube_0.18.0-nightly-3086_amd64.deb and will test it as soon as I got time. |
|
Tests 20/20 videos dash 1080p av1 on without buffering issues. At least as of today, 2023-07-05, with the 3086 version you created. |
|
Can confirm, after long regression proper bufering is back. |
|
As of today (one week later), 2023-07-13, 20/20 videos without buffering issues, also tested today. Seems like google is a bit slower this time (crossing fingers) with countermeasures. Thank you again to everyone involved in the fix for this issue! |
|
I can confirm this issue as well. Just as I thought, G00gle are being a***oles and rate limiting anyone that does not use their site directly without an ad blocker. Well, it seems time to move to Odysee, Rumble, PeerTube and other platforms. I sure hope you guys have plans to enable support for these platforms, as I had enough of these lowlifes. |
|
That's unfortunate. Well, as I move away from YT I guess I won't be using FreeTube anymore if that's not changed. |
|
Hmm, since July 5th and freetube_0.18.0-nightly-3086_amd64.deb, continuing v0.19.0 Beta I had longer prebuffering / longer (coincidently 6-to-9 seconds) load times of new video windows, but no issue like described when I opened this issue. Are you sure @6-AND-9 that this issue has returned for you? Mine still runs fine. If the answer is "yes", can you please elaborate with the details, which version of freetube you run, on what OS, with the settings in freetube you watch the videos, like "1080p, 60fps, local API, no proxy, DASH AV1 enabled"? That would be helpful - thank you! |
Guidelines
Describe the bug
Watching videos on FreeTube on 1080p often runs into buffer-underruns. Watching the same videos on browser there is no such problem.
This can confirmed with any video that buffer-underruns on FreeTube - youtube on browser is not running into the same issue.
Tested on local API. Ubuntu .deb version v0.18.0-nightly-2844 Beta on ubuntu 22.04, kernel 6.2.12 mainline, mesa 23.1, all common codecs present. 100+mbit/s download speed. 12/16GB free RAM, fast SSD with enough free space.
Expected Behavior
A "as fast as" download speed as viewing a video on my browser on youtube - with the local API of FreeTube. No buffer-underruns on 1080p (or higher).
Issue Labels
content not loading, usability issue
FreeTube Version
v0.18.0-nightly-2844 Beta
Operating System Version
ubuntu 22.04 (LTS)
Installation Method
.deb
Primary API used
Local API
Last Known Working FreeTube Version (If Any)
None, issue was with previous versions as well.
Additional Information
As I understood, the local API and FreeTube itself uses no special API key to access content from youtube. So why is it considerably slower than viewing content from youtube itself to a point where it buffer-underruns on 1080p on most videos in an environment where 100mbit/s and other hard- and software issues should not throttle in any way?
Nightly Build
The text was updated successfully, but these errors were encountered: