Web Page Source Froze - Yet More Wirecast Issues

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.

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

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

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

Audio via the Web Page plugin has been problematic. 

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

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

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.

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

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.

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.