Atem mini pro cache full

We have been experiencing this same cache full issue at our church for the last few months.

SOLUTION
We now seem to have resolved it by changing from rtmp to rtmps in the Output | Server URL. We changed both occurrences, that is from rtmp://rtmp.youtube.com/live2 to rtmps://rtmps.youtube.com/live2

BACKGROUND
Now for some background information:
We have the ATEM Mini Extreme
We are currently using 9.6.3 software
We have always had far and away enough bandwidth on a speed test, from 80-800Mbps down and 60-600Mpbs up.
We were on "Streaming High" in the old software, now "HyperDeck High" after updating, but it's still 6-8Mbps.

Our symptom was that around 40-60% of the time we run streaming, after 1-5min the display would report caching. It would then creep up until it reached 100%. It might dip if we showed static slides for a while (which only takes 2-3Mbps) but when back to 6Mbps cache would climb. In YouTube Studio we would then see yellow messages about insufficient data, two different possible messages. And we's see pauses and skips in the preview, and viewers at home would get awful buffering.

INTERMITTENT FAILURES
It works around half the time with RTMP. Therefore it's very hard to fix because when you change something it can easily work three or four times before failing again, but that doesn't mean it's actually fixed. Even now I've seen about 8-10 successful test streams and two successful Sunday morning live streams. So I can't be completely confident it's resolved yet, but looking good.

WHAT WE TRIED
We checked cables, worried about the ATEM temperature, even tried replacing it, consolidated switches, found a possible IP conflict and tried DHCP and then a new static IP, all turned out not to have resolved it until this. One week I tried reducing bandwidth to Streaming Medium and that didn't help either. Sadly it also meant that our disk recording for the week was lower quality.

ADVICE
Obviously other things could cause these symptoms, but this definitely seems to be one solution worth trying if you're hitting this.

CONCLUSIONS
It seems to me there must exist a problem between Black Magic and at least some of YouTube's non-secure RTMP servers which thankfully doesn't exist with the RTMPS servers. It could be a bug in the YouTube servers, for example allowing too many connections so it's not able to keep up. It could be that the BlackMagic device has a slight protocol error which only occurs in RTMP, and perhaps some YouTube servers are more strict.

I hope Black Magic will look into this.

Thanks for your write up Geoff. It seems people are still struggling, while others can make it work by fiddling with newer soft-/firmware versions or RTMP settings. It's still sad that BMD hasn't chimed in.

Hi,

I'm not sure if this is a ATEM issue, i think it´s a YouTube issue.

I've seen this happen once with our ATEM Extreme SDI, thought it was something random, some glitch perhaps. But i have to say that we dont use the Extreme that often, only in different locations.

But i've seen this issue a lot with our TC2 and TC1.

I,ve tried everything and i'm out of ideas. We stabilized it a bit with manual settings on both TCs (CBR, high profile H.264, 4510bps, 25fps) AND creating stream on StreamYard, but yesterday happened again.

We have 2Gb up and down internet connection.

Every wednesday we stream at the same time to 5 places (YouTube, Vimeo, FB, Instagram and Linkedin) and we only have issues on YouTube.

I'll try the RTMPS sollution.

Hi,
I'm not sure if this is a ATEM issue, i think it´s a YouTube issue.

It is a combination of both. If you read back in this thread, you can see that people who struggle with this issue have no problem streaming through OBS in the exact same circumstances. It's also clear that something changed at YouTube's end, somewhere late October 2024 which started these problems.

Hi,
I'm not sure if this is a ATEM issue, i think it´s a YouTube issue.

It is a combination of both. If you read back in this thread, you can see that people who struggle with this issue have no problem streaming through OBS in the exact same circumstances. It's also clear that something changed at YouTube's end, somewhere late October 2024 which started these problems.

Both our Tricaster have the same issue, can relate with that time frame, somewhere Oct 2024.

What changed, YouTube side, to affect physical video switchers, but not SW based switchers?

I can stream to YouTube with no issues if i use Streamyard but i loose quality.

What a wonderful thread. I finally registered so that I can ask my question.

We too are suffering the Cache Full issue. It is random, but 80% of the time it happens.

We go live at 10AM, yet I run a separate mini announcements beforehand for 5 minutes.

From this thread I have realized that it is a you tube issue. We download at 100MB and upload 30/40 MB so it is not a bandwidth issue.

I have tried the rtmp and rtmps servers, same issue. I am not very good with audio equipment etc. I volunteer to help and it has become an issue. People can not watch the service live. We tend to upload it later, after the service as we also record it to a portable drive. This works fine but the live service is what we need. We have shut ins that try every Sunday and its an ongoing issue. This started in mid October and I have struggled ever since. We try on stream low setting on both Primary and Secondary servers.

The odd part is some random days it works ok, but mostly does not.

If it is a You Tube issue, as I believe it is, then I would not expect them to even care. What does bother me is the manufacturer of the ATEM Mini Pro. They have had this thread for 6 months now and nothing, not a single peep that I can find. Saddening.

I have asked for help in upgrading the software, but no one seems to have the Admin sign in for the PCs we use to install the software. The one whom set it all up has moved states away so is not able to help. My thoughts were to update software, currently running version 9.0. I have the latest version downloaded and also would like to update the firmware of the ATEM. Yet in the back of my mind, it remains a You-Tube issue and not the ATEM. It worked fine for a very long time until October.


The hassle of getting the software and firmware updated most likely would be moot to this issue.

I believe we will have to purchase other equipment so that we can broadcast our service to those that can not make it to the service.

This is more of a rant towards ATEM Manufacturer. I know they read these forums, yet why not chime in?

Help someone out, maybe they know how to fix it, maybe not but at least address the issue.

The hassle of getting the software and firmware updated most likely would be moot to this issue.

Just to reiterate: since I've updated ATEM Software Control and the ATEM Mini Extreme's firmware (9.5.1), we have no problems streaming to YouTube anymore. We did another 7-hour livestream last week. Not a single hiccup.

Thank you for the reply.

I am working on getting the passwords etc. It sounds so easy but for some reason, It is not.

My Tasks are:
(1) Get the latest software installed
(2) Get the firmware updated

It's Easter Morning...

April 20th 2025 - Easter Sunday - "He is Risen! He is Risen indeed! Hallelujah!"

Luke 24:12 - English Standard Version
12 But Peter rose and ran to the tomb; stooping and looking in, he saw the linen cloths by themselves; and he went home marveling at what had happened.


I hope it works this morning for sure....

We were gone for 2 weeks, today it all worked fine with rtmps - primary server.

It really is just random I guess.


We have not upgraded yet due to reasons beyond my control.

hi there
Part of the problem comes from the fact that when streaming under RTPM, this is "mounted" over TCP

Anything over TCP will bring cache problems because the "philosophy" under tcp is that no packets can be lost on its way to the final destination, which is good for sending a text file in which you need to receive it just as it was sent . So, when you stream under tcp, if a packet is not found fast your stream will not advance and waits for the delayed packet to put in its place to resume an ongoing stream

Think that if we are streaming at 30 or 60 frames per second, if one or more frames are lost, the final result will not be noticed and you can achieve this when using non-tcp protocol like SRT that does not wait for all packets to advance

I would suggest using SRT for streaming which goes over UDP

Also check if you do SRT that you need to have UDP ports open, usually 1935

I'm another to throw my voice in with this issue. It started to happen for me when I upgraded the Atem to 9.7 from 9.6.3. I went back to 9.5.0 then 9.5.1. The last one worked in one test but today it failed.
I'm going back to 9.6.3 and will try RTMPS instead of RTMP.

We broadcast to Restream.io which then sends on to Facebook and Youtube. But this issue just loads up the case and never gets to live.