0

Web Page Source Froze - Yet More Wirecast Issues

Adding to the list of Wirecast issues that plague my streams on a weekly basis here is ANOTHER one:

The "Web Page" source I use to display my YouTube chat, for some inexplicable reason did not refresh as new chats came in: https://youtu.be/xf_1rVWdwh0?t=273

Look at the chat on the YT page scrolling as new chats enter, yet look at my hard baked chat inside the stream itself not moving. Now, this was working flawlessly before starting the stream (as you can see there is content in there already) so what on earth made it stop DURING the stream???

This has worked flawlessly on other streams I have done, so what is going on now???

Seriously, what does Wirecast actually do right? How many issues is this I have now? For real!!!

20replies Oldest first
  • Oldest first
  • Newest first
  • Active threads
  • Popular
  • And here's where I finally caught onto the fact it hadn't refreshed... https://youtu.be/xf_1rVWdwh0?t=1387 Almost right at the end of the stream.

    Thanks Wirecast, you've ruined yet another weekly live stream of mine!

    Like
  • Benon Koebsch said:
    The "Web Page" source I use to display my YouTube chat, for some inexplicable reason did not refresh as new chats came in:

    Hi Benon.

    I'm going to give Wirecast a pass on this one. In recent times, there have been youtube issues with chat and other parts of the youtube platform as they make changes. I have seen instances of a regular web browser chat popout window stop for no apparent reason.

    Yes, it is possible there is an issue with the web rendering module in wirecast, but I have never seen that happen... But I have seen youtube chat issues like the one in your video that are unrelated to wirecast.

    Regards,
    Greg.

    Like
  •  Greg Kuhnert But the chat was literally scrolling live right there in the stream! That URL for the web page source is the once the chat uses.

    Like
  • Benon Koebsch - I believe you. I use the same popout URL for some of the stuff I do. And I've seen it fail like that before.

    If I thought it was a wirecast problem, I'd state my opinion very loudly. (Ever known me to hold back?). But, in my experience, I have never had this type of problem personally.

    BUT, I can tell you how to deal with it. If you're mid stream and this ever should happen, how do you press the "refresh" button on a web shot? When you define your shot, click the checkbox "Shutdown when not live". And, if this ever happens again - just clear the shot, and then send it live again. That will refresh the URL like pressing re-load on a web page in a browser.

    GK

    Like
  • Benon Koebsch  Anytime there's 3rd party programming involved whether CDNs or webpages, etc, you have to verify before assuming Wirecast is at issue.

    Like
  • Greg Kuhnert Thanks for that tip mate, will certainly make sure I do that from now on. 

    CraigS I'm not sure what you are saying, is the "Web Page" source a third party plugin and not part of Wirecast programming?

    Like
  • Benon Koebsch 

    Benon Koebsch said:
    CraigS I'm not sure what you are saying, is the "Web Page" source a third party plugin and not part of Wirecast programming?

     Nah. I think he's trying to say the web page can have flaws and defects, and the server connections could also fail. As per my previous comments, that's what I think happened.

    The online chat continued for users normally, but there was a failure of the web page callback's that get the updated chat content within the wirecast container. Thats why I was suggesting to tick the box and restart the shot if it happens again in the future. If it happens again and you follow that advice and it works, that is 100% proof that the issue was not wirecast.

    Actually, I tell a lie. Lets say 99.99% proof. Restarting the shot in this way COULD fix a wirecast bug, but it is unlikely to be a wirecast bug. Why? I have seen the exact same thing happen when using a web browser with poppout chat - and it just freezes. Known issue that happens occasionally.

    GK

    Like
  • Audio via the Web Page plugin has been problematic. 

    Like
  • CraigS said:
    Audio via the Web Page plugin has been problematic.

    Um... Could I restate that a different way. Audio via the Web Page plugin is not supported. Problematic infers that it might work with problems. The only way to get audio from a web page is to use screen capture and audio capture.

    There is a feature request in the community tracker to do audio for the Web Page plugin. But, there is no indication as far as I know that this is on the radar any time soon.

    GK

    Like
  • CraigS There's no audio in this web page source.

    Greg Kuhnert I see what you are saying, but if the call-back is working literally on the pop out chat next to WireCast and it's not working inside WireCast that only really concludes one thing: Wirecast is the culprit.

    Like
  • Benon Koebsch said:
    I see what you are saying, but if the call-back is working literally on the pop out chat next to WireCast and it's not working inside WireCast that only really concludes one thing: Wirecast is the culprit.

    Possible, but unlikely. Let me explain why. Using your logic, you're saying that two devices on the same popout chat must fail together if it is not a wirecast issue. I have seen instances of the YouTube chat popout failing on one browser window on one computer, and continuing on another computer at the same time. 

    Without going into too much detail, there may be session persistence across load balancers at the youtube end. Where hypothetically one session might have failed, while another one continues. That is one example that can cause your symptoms. And again, I have seen zero instances where wirecast has caused an issue similar to the one you are describing.

    But just to be clear, I would be yelling and screaming if I thought it was a wirecast issue. But based on my experience and overall IT systems understanding, I really think that it is unlikely to be a Wirecast issue in this instance.

    GK

    Like
  • Greg Kuhnert Either way, this is the first I've seen it happen.

    I will use your technique to ensure it doesn't happen again!

    Like
  • Greg Kuhnert said:
    Problematic infers that it might work with problems.

     At one time it worked (kinda) but you couldn't turn it off. If you cut away it was still there. So it doesn't do that anymore.

    Like
  • Greg Kuhnert I just tested your "shutdown when not live" technique and this is not a suitable workaround as there is a flickering which occurs when the shot goes live. It looks terrible when transitioning from a shot without the Web Page URL and one with. 

    So I'm just going to leave it live all the time as before and hope that WireCast doesn't spit the dummy randomly like last week.

    I guess I could check that box if it does mess up and at least it should bring it back live while in the stream. That's somewhat of a consolation.

    Like
  • Hi Benon Koebsch 

    Benon Koebsch said:
    It looks terrible when transitioning from a shot without the Web Page URL and one with.

    There are other benefits to shutdown when not live. Some web pages have high CPU for their callbacks. Shutdown when not live will maximize performance on your system by releasing those resources.

    I agree totally that it is not "pretty" however. I did report this issue previously, and perhaps that is another discussion for another day. But at least it is a workaround. Perhaps you can have the best of both worlds. Have two shots. One with shutdown, one without. Use the one without shutdown, and if it breaks - clear that layer and use the other shot. That way, it only looks "ugly" in an emergency :)

    GK

    Like
  • I tried something different and got around the issue by adding custom CSS to constantly scroll the page to the bottom regardless of whether new content has been added. This will have the effect of constant scrolling when new content is added (which happens anyway) but also a stationary page when no new content has been added :) And should Wirecast "freeze" the page like it did last time, the CSS will scroll it (ideally) :)

    Like
  • Nope the CSS hack didn't work: https://youtu.be/mXIcNZVdZpc?t=975 Another stream with a frozen Web Page source. Thanks Wirecast. Really great piece of software this!!

    Like
  • Benon Koebsch  Please test with something other than YouTube chat so we can have a common link to test. If the only time it occurs is with YouTube chat it may be related to that specific implementation.

    Like
  • CraigS What would be a good example to test it with?

    Like
  • Benon Koebsch said:
    What would be a good example to test it with?

    I'm not sure. If the issue is only with YouTube chat it may be something specific to it which makes it challenging to troubleshoot.

    Like
Like Follow
  • Status Answered
  • 3 yrs agoLast active
  • 20Replies
  • 180Views
  • 3 Following