Youtube live chat does populate without 30 sec delay on live streams #25694
Comments
|
Still happening on [Version 1.45.78 Chromium: 106.0.5249.65 (Official Build) beta (64-bit) |
|
I saw a brief delay then showed, then when I refresh the site it showed instantly (like caching the page). So works for me? This is a Clean Brave Beta profile. No extensions. |
|
It is like a 20 sec delay on all live streams here before the live chat populates. |
|
I have attached the output from Devtools when I initiated a reload of my test stream |
|
Is anyone from Brave Dev going to bother looking at the dump or should I just go back to MS Edge or Chrome the latter has no issues with chat populating properly? |
|
Further testing results https://community.brave.com/t/youtube-live-chat-30-sec-delay/432842/49?u=fedup if this was something on this computer outside of the browser then why is Chrome, Firefox and MS Edge Beta not experiencing this delay? |
|
This is a screen capture that I did in a new profile on Brave Beta. The issue is happening on a brand new WIndows10 computer here with Brave with a new profile. This new computer has no security software or antivirus other than the stock Windows10. To have the issue occur
This problem not occurring in Google Chrome, MS Edge or Firefox. I notice on occasion the browser is waiting for a gstatic or other google servers to respond. Version 1.46.99 Chromium: 107.0.5304.91 (Official Build) beta (64-bit) Brave.Live.Chat.Lag.mp4 |
|
Version 1.47.91 Chromium: 108.0.5359.48 (Official Build) nightly (64-bit)](https://brave.com/latest/) |
|
On a clean install of Version 1.48.5 Chromium: 108.0.5359.48 (Official Build) nightly (64-bit) with no extensions, if the Brave shields are down a non-skippable ad plays followed by a skippable ad plays. The chat does not populate until the skippable ad is skipped. With Brave shields up and the tab reloads the video plays but the live chat is delayed by about 20 secs. |
|
This issue is indeed a Brave one. I installed Vivaldi with the same extensions and settings as those in Brave and Vivaldi has no issue with the YT Tube live streams chat populating as soon as the video stream starts. |
|
Hi @snowbound - taking a look into this one as well. |
|
Just attempted to reproduce from Win10 on: 1.48.32 Chromium: 108.0.5359.94 (Official Build) nightly (64-bit) Chat loads within 2-3 seconds of page load for me. Testing from this page provided at top of issue: https://www.youtube.com/watch?v=jfKfPfyJRdk Going to update and attempt to repro from latest version of Nightly. |
|
I was able to reproduce in: 1.48.41 Chromium: 108.0.5359.99 (Official Build) nightly (64-bit)
Seemed like switching tabs triggered the live chat to display. Going to attempt to get a console print from refresh to see if there are any clues there, and will tag in some folks from the team to dig in deeper. |
|
Was able to get some more info on refresh - I think I may have some indication of what could be going on here. Going to summon some bigger brains than mine on this one to double check. I don't think it's an issue related to our filter lists for ad blocking. When I refreshed, here's what I saw, which aligns with what @snowbound reported.
I captured some interesting messages printed to the console. Disregard the red errors, as those appear to be the shields doing their thing. Here's the full print from refresh to when the chat began to work as expected Here's a close-up of the area that jumped out at me when reviewing the console Tagging in @bsclifton @rebron who may know who best to tag in to put some eyeballs to test this theory, but here's what appears may be happening. It looks like I'm seeing some timeouts with event handlers that may be taking place ahead of when GreaseLion loads. Could be a race condition or some other conflict that's causing the chat not to initially load, but then begin displaying as expected when switching back and forth (alt+tab on win or command+tab on macos) between tabs. Not 100% sure, but seems like it's a load order issue with how GreaseLion functions in this scenario - don't suspect it's filter list related, as if it were, I'd observe consistent behavior when toggling between tabs. Wouldn't expect the chat to begin displaying concurrently with video if this was a filter/shield issue. Hope this helps - but one to dig in on given it's YT and Windows. |
rebron
added
google
webcompat/not-shields-related
|
User left dev tools data dump info for review: |
|
Is there any more information Brave devs need from me for this 6+ month old issue? It is still happening on Version 1.49.91 Chromium: 110.0.5481.77 |
|
This issue may be YT running preroll ads on live streams. I fired up MS Edge Beta today and it had what seemed to be a 30-60 second ad on a live stream. During the first 20 seconds of the ad the live chat would not populate. Once the ad reached a certain point the live chat showed up. |
|
happens to me too on windows10 and brave [Version 1.49.120 Chromium: 111.0.5563.64 (Official Build) (64-bit)] it appears to be random: sometimes it happens, and sometimes it doesn't. |
|
@sbernecchia the random is could be due to 2 issues. The stream may not have any preroll non-skippable ads OR the stream has to be paused then the browser cache has to be cleared and the YT page for the stream has to be reloaded sometimes to see the effect. What I have discovered is that if one has UBlock installed in Brave using the standard block lists (with Brave shields down) you see the preroll ad that is causing the issue. If however, you have Brave shields enabled with ad blocking (aggressive or not) then the preroll ad is blocked HOWEVER the live chat populating is delayed until the 20-second mark of the non-skippable preroll ad gets to the 20-second mark. Even if Brave has no additional filter list items checked it is still blocking the preroll ad but can not fix the live chat populating until the 20-second mark. This issue has existed since early Sept 2022 in Brave all builds. Others are no doubt seeing this issue but do not realize the chat issue is caused by preroll non-skippable ads. Vivavaldi even with UBlock Origin installed using the same settings as UBlock in Brave does not have this chat issue. I see the chat populate right away |
|
Happens to me to. View this post for my brave/windows setup |
|
@ScrapBlox |
|
It is up to Brave Devs to figure this bug out. I had a YT stream where I disabled all ad blocking and saw no ads yet I saw the 20 second delay in loading the chat. I as an end user can only do so much. I have seen this happen on countless systems here some with a brand new clean install on a clean Win10 install with no extensions. I have had friends having the same issue with YT chat. I give up @lukemulks |
|
Yup I've already given up on brave browser as I need youtube live and chats. As a viewer and broadcaster I need it. I now use vivaldi |
|
@ScrapBlox especially when you have to moderate live chats 20 seconds seems like an eternity. |
|
@rebron You see this just before chat does load vTools failed to load source map: Could not load content for https://www.youtube.com/s/desktop/945ad0b2/jsbin/web-animations-next-lite.min.vflset/web-animations-next-lite.min.js.map: HTTP error: status code 404, net::ERR_HTTP_RESPONSE_CODE_FAILURE |
|
Sigh. This is even happening in Brave Version 1.53.5 Chromium: 113.0.5672.53 (Official Build) nightly (64-bit). If you go to https://www.youtube.com/watch?v=jfKfPfyJRdk and force a reload of the page the chat will take 20+ seconds to show up. Out of 10 forced reloads on the page 6 of the 10 reloads caused the chat to take 20+ seconds to populate!! If that is normal for Brave please will someone from Brave here tell me so and I will ditch Brave from all my systems and mobile. Imagine being a content creator on YouTube and having to wait 20+ seconds before you see the chat or before your moderators can start their moderation. Twenty seconds can feel like an eternity. |
|
This is from the stream I use for testing https://www.youtube.com/watch?v=jfKfPfyJRdk on Windows10
Where the arrow is about where the live chat finally decided to populate properly. This is from Brave This issue is across all 3 versions of Brave. If the issue does not occur the first time a stream in YT is played then repeated reloading of that live stream will cause the issue to occur. I have yet to see a live stream does not exhibit this issue. |
|
If a live stream has an issue loading the chat when one starts playing the stream, the symptom also occurs if you then hide the chat and then try to show the chat. You have to wait 20+ seconds for the chat to show up. If the stream has no such issue when initially playing it then hiding and show chat works as expected. |
|
When testing with @ryanbr, it seemed to show (for both of us) on average every 1/10 times. The other 9 times the chat loads fine. I did find a request which took a long time to process... this might be a good clue Basically, with the Dev Tools / Network tab open, I waited until the 1. The issue reproduced 2. The chat showed itself after 20-30 seconds. Then looked for the long running requests. I narrowed down to the outbound request I had for:
Had the following stats: You can see it took 20 seconds to resolve. I also noticed some weird service worker activity taking place right before this outbound call was made (these are requests in sequential order; first made ones towards top). So https://www.youtube.com/live_chat?continuation was hit- seems it failed. Then (the gear icon) the service worker is also red. Those both are marked as @pes10k could anything about our service workers (any deviations we have from Chromium) cause this? |
|
I can say that this is happening across all 3 of Brave builds, release, beta and nightly more than 1 out of 10 times for me during regular viewing of the live streams with chats. It is rare for me to have a chat load properly. Today from 4 different live chats 3 out of 4 failed. I have found that repeatedly force reloading the stream will cause the issue to occur. Also pausing the stream and then force reloading the stream can also duplicate the issue. I am not the only end-user seeing this issue. Something happened back in early Sept 2022 that caused this issue to occur. |
|
@snowbound repeatedly force reloading is consistent with what I'm seeing. Although, I get good results when opening dev tools (F12) and checking the box With that checked, I'm curious if you can reproduce the issue. You can try reloading the page and dev tools will stay open. Let me know |
|
@bsclifton I have over the past 8 months tried disabling the cache several times and that did not solve the issue. I can not remember if I had Dev tools open on each instance. I have Nightly installed and I can not find that option. Update |
|
@snowbound awesome - let us know if keeping dev tools open and then having This isn't the proper solution of course - but if that works 100% of the time, it does help narrow the problem down for us. With that enabled, I gave up after reloading the page about 50 times because it worked each time. |
|
@bsclifton After 2 days of getting notifications and rather than clicking on the notification, I went to my YT subscriptions page and did a F12 and only then clicked on a Livestream the chats all loaded promptly. Another end user on the Brave subreddit back in Nov or Dec 2022 mentioned disabling the cache but they said it did not always work. I tried it at that time but did not at the time realize that the Dev window had to be open for the disabled cache to be active |
|
@bsclifton |
|
@snowbound @bsclifton There is an issue for Brave to load the iframe content and the url will become The 30s is set by YouTube's engine. YouTube can detect if the content is not displayed then refresh the iframe. This is not implemented by Brave. |
|
@cyfung1031 Yes I am the original poster for that Brave Community thread and have been using that thread which you fixed earlier this week. There is also another issue with Brave in live YT chats blanking out the posting area in the chat |
Description
When one brings up a Live YouTube stream that also has a live chat. the live chat remains blank for 30 seconds
Steps to Reproduce
Actual result:
Expected result:
The live chat should display comments at the same time the live video starts playing
Reproduces how often:
Go to this stream for example
Brave version (brave://version info)
Version 1.45.75 Chromium: 106.0.5249.65
Version/Channel Information:
Other Additional Information:
Miscellaneous Information:
Outlined here in this [thread](https://community.brave.com/t/youtube-live-chat-30-sec-delay/432842/25
I have tried so many things over the past two weeks to narrow this issue down) at Brave Community
This issue is more noticeable when dealing with actual LIVE streams.
Yes, I have a new profile that has no extensions in it. I have tried the first 3 streams that Saoiray posted in that thread on the Brave community.
The first 2 streams are live streams and the chat takes 30 seconds to load. If I force a page to reload on these 2 streams it makes no difference. The 3rd stream, The Ramsey show is a recorded stream. That chat also takes 30 seconds to load HOWEVER once it gets into the cache then the chat loads fine when the page has a forced reload done on it. If you clear the browser's cache the issue comes back. I am on a 500Mbps symmetrical fibre connection.
I noticed this issue with LIVE streams in September. Before then the LIVE stream chats populated fine. This is not the first time however that this issue has happened in Brave.
[IAmDinkAMA in Brave's subreddit mentioned in a thread I started over there re this issue that he noticed that going to brave://net-internals/#dn and performing the clearing of host cache twice seemed to fix the issue when reloading of the page would cause the live chat to take 30 seconds to populate.
Alas that did not seem to fix the issue. I have tried this numerous times in an empty profile and whenever I cleared the browser cache in that profile the loading of the live chat takes 30 seconds or so. What I did notice was that during these 30 seconds Brave showed waiting for fonts.gstatic.com
P.S. I am using this live stream for my testing
The text was updated successfully, but these errors were encountered: