Atem mini pro cache full

Well, back in late December 2022 I upgraded my ATEM mini pro iso and immediately started getting buffering issues streaming to YouTube. I rolled back to old firmware and my issues disappeared.
On October 13th 2024 with no code changes to my ATEM, YouTube started complaining that it was not receiving enough video and our users noticed gaps in receiving the Livestream. I completed work on our fibre optic Internet service and our Ubiquiti equipment with no improvement.
Today, I upgraded to the latest ATEM firmware and things got worse. The ATEM started buffering like back in 2022 and YouTube complained AS WELL. I tried all sorts of combinations to no avail.
Finally, I downloaded @Garyadams XML file and added iT via the Stream pulldown. It then showed up in the Livestream Output options. I selected YouTube and it offered me two sets of primary and secondary servers. Only the second set worked, but it now works without any issues. Woohoo.

It baffles me as to why, after two years, Black Magic still has not fixed their streaming issues to YouTube. We have to resort to using an XML patch file created by @Garyadams back in 2022.

I am back in operation and will not be updating time soon, if ever. It is not a YouTube problem or an Internet issue; it is a BlackMagic code/configuration issue.

I hope this helps someone experiencing the same issues.

Peter

Sent from my Pixel 7a using Tapatalk

we all knows , that its BMD problem .. On same internet u can switch to OBS and everything works perfect .. Or u can switch to different internet (mobile in my setup) and everything works too ..

I've been having this or a similar issue for the past couple weeks - here's what worked and did not work:
-downloading the custom RTMP xml file did NOT work for me
-the computer I use to monitor the streams is a 2013 MacBook air; updating to the latest software that will work on that OS also didn't make a difference (version 8.6.3, though this is notably the version everyone had the prior issue with)
-connecting the switcher to my personal computer that is Windows 11 and updating the firmware to version 9.5.1 DID actually work, however I had to downgrade the firmware when i returned to using the work laptop.
-changing the stream key on youtube from an RTMP variable key to one where I manually set the resolution and fps to 1080p/30fps turned out to be what has worked with the old 8.6.3 firmware (at least I have been streaming for 15 minutes so far with no buffering and no cache filling and no errors from youtube; I will run a longer stream just to check but if this post is unedited, assume it worked)

Update 10/29: What worked yesterday did not work today; attempting to recreate what worked yesterday, I remembered I had the USB cable connected initially and then had disconnected it after successfully going live in order to test recording. This was a fairly consistent works/doesn't work distinction today.

Tested multiple ethernet cables as well as plugging the atem directly into the router instead of into the gigabit switch; all I achieved was roughly doubling the time before youtube started to stutter. (filling the cache after 3-4 minutes instead of 1-2). In any case I think it might be a cable or network issue on my end. Strange that it manages to continue to stream successfully without the USB cable plugged in.

Three days ago I posted about a new round of issues streaming to YouTube. My fix/work around was to use the Stream RTMP.XML patch shared two years ago. I wondered why Black Magic had not fixed the issue. It looks like it is not Black Magic's problem.
I found a discussion on the Ubiquiti Networks site that makes a case that they are the source of the problem. They have known about the issue for more than 2 years.
https://community.ui.com/questions/UDM- ... 926?page=1

Stuck in the middle!

I'm making a contribution to this useful thread:

We have been using the ATEM Mini Pro at our church since early 2021. We first streamed to FB, then switched to YouTube in late 2021. We've had no issues UNTIL OCT 13, 2024, just like @user2021.

I've read every page of this forum, and based on what I've learned, I suspected a conflict between the XML file(specifying RTMPS) and our scheduled YouTube streams(specifying RTMP). I verified that our XML file has been using RTMPS since the very beginning. This will be important below.

Most of the advice here is to modify the Streaming.XML file(or importing Gary Adam's XML file) to specify RTMP. I thought I would try the opposite: make sure that the YouTube setting specified RTMPS. This worked immediately, and we didn't have to change our XML file!

Unfortunately, we schedule our YouTube streams in advance(one month out), and I could not discover a method to get YouTube to remember to use RTMPS. Once our streams are scheduled, we do not open YouTube Studio until we're ready to schedule another month's worth of streams. As most of you know, this simplified our process: when we're ready to stream, we just hit the On Air button on the ATEM Mini Pro. Easy. I've tried to open a future stream, change it to RTMPS, and exit. But when I try to stream to it, YouTube reverts it to RTMP. We cannot afford to open YouTube Studio each time we wish to stream, just to change it to RTMPS. Does anyone know how to get YouTube to preserve our scheduled choice of RTMPS?

Part of the reason is that we sometimes stream outdoors. Indoors or outdoors, we connect the ATEM Mini Pro to an Ethernet cable. But outdoors, we do not have our computer available to open YouTube Studio and make the change every time we stream. We are loath to introduce a new step in our process anyway.

First, it has been implied here that the problem is an incompatibility between the setting in the XML and the setting in YouTube. However, this (undiscovered) incompatibility has never been an issue for us until Oct 13, 2024. I can guarantee you that we've been using RTMPS in our XML file since 2021. What I don't understand is why this incompatibility has never caused a problem until(for us and @user2021) Oct 13, 2024. I acknowledge that resolving this incompatibility solves the new problem. But I can't stand not knowing why this is a new problem; it should have wrecked our stream the moment we changed from FB to YouTube back in 2021.

Second, some of you have alluded to temperature problems. I have a data point for you: in my nearly two hours of careful testing yesterday(including measuring bandwidth, we have tons to spare), I ran into this temperature problem. I spent a long time(nearly 2 hours) ensuring that I could make the RTMPS problem happen, make it go away, and make it happen again, reliably. Except on the last two tests, the problem recurred despite compatible RTMP settings. This time, however, the cache filled to 55-65%; it never reached 100%. And it took 3 minutes to begin filling, whereas when I induce an RTMP incompatibility, the cache will start filling in about 1 minute. After two hours of being powered on and encoding, I suspected temperature. So I started blowing through one of the cooling ports. Sure enough, the cache began to drop. Even after I stopped blowing, the cache completely emptied to zero. I think this explains why some of you suspected temperature problems, then retracted your suspicion. Temperature is a confounding factor, but it has to be 'high enough'. In our case, this is an edge condition; we never encode for more than an hour straight.

I will do more testing, but those are my contributions. I'm very VERY grateful this thread existed. We've been tearing our hair out trying to figure out WHAT CHANGED. In fact, something seems to have changed, but it was nothing in our process, XML file, YouTube settings, bandwidth, hardware, etc. It seems to be something out of our control. We will most likely resort to using RTMP and not RTMPS. Thanks again, Gary Adams

Adding my experience with the cache issue with the ATEM switchers.

I went through similar symptoms; cache filling up shortly after the stream began. Network speed is 300/300 Mbps. I tried to modify the XML file to transfer the signal via RTMPS, which did not help in my case. Cooling the ATEM did not do much either.

Suddenly I thought of this: would the issue persist when I stream via other platforms? I tried restream.io and to my surprise, the cache did not fill up unlike YouTube. ATEM is streaming with 9~10 Mbps.

I came to suspect there is some discrepancy between ATEM and YouTube RTMP, will update.

We have been streaming since 2022 without issue on a once week for church services schedule.

Our ATEM Mini is connected to an Ethernet switch to the Internet. We recently changed internet providers (with higher speeds). Like others, on Oct 13/24, our stream started ok, but started to fill up the cache over about 5 minutes. This same issue has taken place for 3 consecutive weeks. I have confirmed our internet provider has been able to support our 9.15 to 9.25 mbps upload to YouTube. The ATEM mini reports consistent upload speeds and YouTube does not report any issues with the stream.
We have not updated the mini from version 8.6.

I have not reviewed the xml file, nor have I looked at the mini temperature issue (yet) that’s been reported. I will be looking at this tomorrow.

Any additional support will be appreciated.

Since I started reading this forum, I tried a little experiment on Sunday before our stream (which runs about 1 hour or so).
I used compressed air to clear the ATEM mini pro unit at both ends.. our stream performed perfectly for the entire 1 hour plus; no caching!
I did check both the YouTube setting (RTMP) and the xml file (RTMPS). I will leave alone for know, knowing I can nake the change when needed.

Since I started reading this forum, I tried a little experiment on Sunday before our stream (which runs about 1 hour or so).
I used compressed air to clear the ATEM mini pro unit at both ends.. our stream performed perfectly for the entire 1 hour plus; no caching!
I did check both the YouTube setting (RTMP) and the xml file (RTMPS). I will leave alone for know, knowing I can nake the change when needed.

@Philipt57 Just to be clear, you have(and like us, always had?) incompatible RTMP and RTMPS settings between the XML file and YouTube, and you left this unchanged. You have encountered cache filling problems(just recently, or this has never worked properly?). But simply blowing compressed air through the cooling ports solved this problem?

I'm not questioning your findings, just trying to understand them properly, since it's contributing to a hypothesis I'm building...

In the last three weeks (about 27th Oct) we have also been plagued with Buffering using the ATEM Mini Pro and streaming via YouTube. It case caused our livestream to get jittery with video and audio. We began powercycling the device and had to do that about every 15min. I suspected overheating as it was above 27degC inside with no aircon. Suspecting temp issues after the first 15min today it started to buffer again so I pointed a small desk fan at the air vents on the left hand side and over the next 15min buffering continued to climb, but did not go above 80% and then gradually came down to 0% over the next 45mins and stayed at 0%. I suspected the fan had stopped working but when I pulled it apart, unplugged the fan and plugged it back it it worked fine, so the fan is operating. Next time I will use the desk fan again but blow with the internal fan direction and point it into the right air vent. I suspect the temps will stay lower quicker and I might avoid the buffering issue?

We stream our Sunday service every week. We also encountered the "cache full" issue. We could solve it by changing the protocol of the YouTube upload URL from RTMPS to RTMP protocol (Atem Control software). Perhaps that helps some of you too.
Best Carsten

Encountering the same problem here in the Netherlands with the weekly stream at our service in church since approx. half of octobre. We had never before this caching problem. Seen that in YouTube Studio, the stream URL is the RMTP-one.
Red the solution to replace the .XML-file by the ons Gary Adams made.
Will try that before coming sunday.

Only through page 1 of posts on this thread. But I tried hitting Off Air once cache approached 40%+ and going back On Air once it dropped to zero. Looks like I had to do it twice. But it ran flawlessly after that. I would like a more holistic solution so we don't have to take this approach, but I'll keep reading and give updates if there's any

Tried the new XML, didnt work. At times it filled cache even faster. Went searching on YT and came across a guy saying that whenever the switcher isnt acting right, put it in recovery mode to do reset. That process is to unplug cable, press Mic 1 ON button and hold while plugging in power, then opening setup to begin update which will force it to latest version for anyone wondering.

Now, I have been able to stream two 2-4 hour services since then, but, big but; I still have to unplug right before going live as I mentioned in previous post in another thread. I create a stream in YT, then before going live I need to unplug (adjusting mic levels after reset), and then replug and it seems to work. I shoudlnt need to disconnect though.

Chiming in from Upstate, NY. Our company sold a church a Mini Pro about a year ago and they streamed weekly to Youtube with no issue until mid-October when these same issues popped up (cache filling, stream skipping, "YouTube not receiving enough data"). Testing at our office, we had the same issue with our Mini Pro. I streamed with a Mini Extreme using all of the same settings and internet connection, and it worked perfectly. So after reading through this thread, I went into the streaming.xml file and changed the service settings for "Youtube RTMP" to use the RTMP server address and not the RTMPS address that was there. The cache no longer filled up, and the stream seems to work well, but I still intermittently get the not receiving enough data error message...

Then I realized something. Our Mini Extreme was on Switcher version 9.5.1. This came out in June 2024, and both Mini Pro's that are having problems for us and our client were using 9.6+ Software Control, but no one opened ATEM Setup to update them. Once I updated our Mini Pro to 9.5.1 it streamed flawlessly. No cache filling up, no error messages. So to everyone experiencing this problem, check that you have actually updated your switchers firmware to the latest 9.5.1. Hope this helps!

So far I have upgraded the ATEM mini code to the latest, installed the patched RTMP XML file, selected YouTube, and made sure to select the second "Primary" in the list of four options. This worked for one Sunday but then the issue of YouTube complaining that it was not receiving enough data returned.

I have confirmed that my fibre based Internet service is fine. My Ubiquiti network equipment is all up to date. I configured high priority for RTMP and RTMPS in my network, but that made no difference. A traceroute to the YouTube rtmp server shows that it is not very far away and response time is 26mS as I recall. Oh, I blew any dust out of the ATEM. The errors are worse during the first 5 minutes so I figure that overheating is not my issue.

We still get complaints from YouTube about not enough data and occasionally see buffering on the ATEM multi view panel.

My next test is to use Wireshark to analyze the data conversation between the ATEM and YouTube to see who might be dropping packets.


Peter

Sent from my Pixel 7a using Tapatalk

Wow, I'm glad to read these posts. I am pulling my hair out. We have been streaming to YouTube for 2 years with no issues, and then WHAM, October 20, 2024, our stream cached to 100%. We use the same stream key and settings every week. We stream to YouTube Primary, and on HIGH. Never once had issues in 2 years. Last Sunday with exact settings I couldn't stream on LOW. The ATEM Mini Pro starts fine then starts catching about 4 minutes in. I need to read through all these posts and sort it out but by the looks of it YouTube has changed something on their end to cause all these issues and it's not the fault of our Internet speed, our ATEM Mini Pro, etc. There are too many other people having this issue at the same time starting in Oct 24.

Reading through this OP...

Our situation at my church is we haven't had a single issue with cache in the 2 years that we have been online since COVID. Then BAM, big issues starting Oct 20th, 2024. Others are posting the same issue starting around the same time in mid-October, so whatever changes over at YouTube is affected a bunch of us all at the same time.

By switching out YouTube to Secondary and Low, that worked one time. The next time it cached full so I believe that's not the answer.

This solution is working for me.
1. open ATEM software control
2. Platform: select Custom URL H.264
3. Server: copy and paste Stream URL from Youtube.
4. Key: copy and paste Stream key from Youtube.
ONAIR
Good luck.

This solution is working for me.
1. open ATEM software control
2. Platform: select Custom URL H.264
3. Server: copy and paste Stream URL from Youtube.
4. Key: copy and paste Stream key from Youtube.
ONAIR
Good luck.

Interesting. I have three questions.

Did you paste the rtmp or the rtmps url? Did you start experiencing issues in October like many of us - please elaborate? How many live streams have you successfully run with this setup (eg: just one so far or many).

Thanks for sharing.


Sent from my Pixel 7a using Tapatalk

Same issue here.
Device - ATEM Mini Pro.
More than 2 years live streaming to Youtube (1080p) once per week. Suddenly last 4 streams started to lag and Youtube showed bitrate error (poor). I was ready to change internet service provider, then found this tread. Will try to update ATEM settings and see if next stream will be OK again.

My issue started in mid Nov. Updated to the latest ATEM Switchers 9.6.2 Update. Tried several fixes, finally found this solution. It seems to be working two weeks in a row so far.
Hope it helps.

RTMP

FYI: Before yesterday's church service, we changed YouTube stream key to HLS(advanced) and settings to HD 1080p upload. On our laptop we changed the XML document to reflect the new HLS URL. I ran 4 tests with different Stream High, Stream Medium, Stream Low and I was still getting the caching issue about 4 minutes in. I thought this HLS was going to solve the caching issues but I was very disappointed and perplexed and our service at 11am was about to start.
At 10:59am the organ starts the prelude and with one last ditch effort to get online, I switched the YouTube Primary to SECONDARY on the ATEM control panel.
I hit LIVE and our 1 hour service streamed without and caching errors!
YouTube initially said my stream was healthy, then gave me an error that "not enough video is being sent and that it was low" - Well I was on streaming LOW .... But it never cached and the video looks fine.
Next week I will try YouTube SECONDARY and STREAMING MEDIUM using the HLS stream key and see if that works.

Much to our dismay, we're in the same boat as many others here. We're streaming 7-hour events to YouTube since early 2020 with ATEM Mini Pro's, and since it came out with an ATEM Mini Extreme. We've done about 35 events since, and we always use the same settings, which worked flawlessly up until now:

- Fixed streaming key
- 1080p@30fps
- 4.5kbps
- Ultra low latency

Our network connection is fast (500/100) and stable. In these years, we have never encountered the dreaded "YouTube is not receiving enough video to maintain smooth streaming" error. But I'm getting this error consisently now, no matter what I try. And I've been trying a lot of things today:

- Changed YouTube stream setting to "low latency" (from "ultra low latency")
- Changed the ATEM switchers config to RTMP (was RTMPS, was indeed mismatched in the XML "switchers.xml" config.
- Lowered quality to 2.5kbps
- Changed to "Secondary" server in ATEM Software Control (which would be rtmp://b.rtmp.youtube.com/live2?backup=1)
- Removed a switch from the network stack, directly plugging into the fiber modem

None of this made any difference. I tested in two completely different venues, with completely different networking setups But after about three to four minutes after starting the stream I see the same error appear, which I have never seen before in either location. I don't think this is a local networking issue, especially since people report it started about the same time (mid October 2024).

For the people who think that Gary Adam's "patch" from 2022 is something magical: it's not. It's just a configuration file where the YT servers are without the "s" (so the server URLs in there are reading "rtmp" instead of "rtmps" (TLS/SSL)). I tried this, it doesn't work. I do have to try setting both the scheduled stream to RTMPS and the settings file to RTMPS, but I'm not holding my breath.

So, like others have mentioned: it's likely a change on YouTube's end. But it seems to only affect ATEM Mini's, other soft- and hardware encoders seem to have no trouble streaming to YT.
I'm also pretty convinced that temperature is not of any influence. I've been testing in rather cool environments, and there's no hot air coming from the switcher.

BTW, I don't see the cache percentage, it just always says "Cache: OK", even when the YT stream is heavily buffering. Not sure what that means. Where can I see the percentage?

I'm going to update the MacBook Pro running Atem Software Control to Sequoia (from Big Sur: if it's not broken, don't fix it) and Atem Software Control to the latest and greatest, update the Extreme's firmware and see it this makes a change. If it still fails, then I'll be looking for a stop-gap solution with a machine running OBS in between. That would be embarrassing for BMD, we trusted them for their hard- and software, but these seem completely unreliable now. I don't understand that if this problem is so widespread (which it seems to be), why BMD is not stepping in.

Will also be looking at the "Custom URL H.264" https://forum.blackmagicdesign.com/viewtopic.php?f=4&t=210801#p1095271 option, but have to do all the updates to see it, I suppose.

In two days from now, we have two consecutive days of 7-hour streaming, so I'm desperately looking for a solution.

In two days from now, we have two consecutive days of 7-hour streaming, so I'm desperately looking for a solution.

I think I may have found a bypass to the troubles. I am not positive, but I'll share what I have tried in hopes that it works for Pancake.

Each time you press the On Air button the ATEM looks up a YouTube server via a DNS lookup and connects. It stands to reason that there are many physical Rtmp servers and each time the ATEM does a look up, the DNS server gives out a different IP address for a different server.

I have completed two tests. Well in advance of my stream time I press On Air while watching my YouTube session and if I get errors I press Off. Sometimes it takes two or three minutes to close the session (to clear the cache). I try again. I do this until I connect to an RTMP server that does not cause errors and then when I am ready, I press go Live. No errors or issues for the duration of the live stream.

In both tests it has taken four or five On Air presses to find a stable server. I suspect the servers are all over North America and the connect performance varies.

I plan to use Wireshark to sniff My ATEM connection to track which RTMP server IP addresses are stable. In the meantime I'll try my test method again.

Give it a test and see if it works for you.

Peter

Sent from my Pixel 7a using Tapatalk

Thanks for sharing this Peter. I must have stop/started my test streams at least 20 times yesterday (Europe), but never ended up with a stream that did not bring up the "YouTube is not receiving enough video to maintain smooth streaming" error.

I found this topic from the end of October (I wonder...), where poster @AVLTechJim writes:

I spoke with a BMD Tech today and he stated that something is broken with the RTSP protocol on YouTubes end. Causes "YouTube isn't receiving enough video to keep the stream smooth" and cache pile up. States new software/firmware update in several weeks.

The last post in that thread makes me cautiously hopeful...

Okay a few hours later I can report that:

- taking a freshly wiped MacBook Pro M1 with macOS Sequoia...
- installing Atem Software Control 9.6.2 on it...
- having ATEM Setup update the Extreme's firmware to 9.5.1...
- using our normal streaming settings (see above)...

...completely fixes the problem at hand. I'm currently streaming for over 4.5 hours without a single hiccup. YouTube only reports "Excellent connection", and the latency is indeed "ultra low". I've stopped and started the stream a few times, even changed to a higher bitrate option, just to see if it holds up, but it does. This was impossible yesterday.

I was actually planning on updating everything and using a freshly M1 MacBook Pro the day before yesterday, but out of time-constraints didn't. Now I was forced to do it anyway, and hopefully the setup will stay as robust as it is today for a long period of time.

Apparently there was a problem with ATEM Mini + streaming to YouTube and it got fixed somewhere, just like was reported here. Judging from the number of people seeing this error, BMD didn't communicate this broadly (please correct me if I'm wrong). If only there was a release notes page where you could just see what all the release notes were per version. You know, like pretty much every other software company does...

I KNOW THE BALCKMAGIC ADMIN IS MONITORING THIS FORUM.
WHY ARE YOU NOT PROVIDING THE FIX?????????????????????
ARE YOU ABANDON THIS PRODUCT AND NOT SUPPORTING IT ANYMORE?

BTW, I don't see the cache percentage, it just always says "Cache: OK", even when the YT stream is heavily buffering. Not sure what that means. Where can I see the percentages?

We use the ATEM Mini Pro, and in the output monitor is a "box" which has the ON AIR description with a Livestream timer counter and gives the Mbps rate that you are streaming at and also indicates the CACHE. Our percentage is shown here, a good stream it reads 0% cache but then climbs to 100% CACHE FULL on a bad stream.
BTW last week for our church service, we switched from RTMP to the supposedly more stable HLS URL on YouTube. It took us 4 tries to get a stable(no caching) stream but was finally successful.

We use the ATEM Mini Pro, and in the output monitor is a "box" which has the ON AIR description with a Livestream timer counter and gives the Mbps rate that you are streaming at and also indicates the CACHE. Our percentage is shown here, a good stream it reads 0% cache but then climbs to 100% CACHE FULL on a bad stream.

Strange, I'm only shown this:

streamstatus.jpg (21.79 KiB) Viewed 18036 times

Not super helpful TBH.

I've been running some more tests today, because this morning it suddenly occurred to me that my tests yesterday did not involve an extra router that we use to isolate us from the venue's network. Because people in this thread were suspecting their network hardware to be of inluence, I did some extra tests. I don't have my production router with me here, so I took an old DSL router and configured it the same way we use for production. Like yesterday, I did not see any errors, just an "excellent connection" for hours and hours:

excellent.jpg (64.61 KiB) Viewed 18036 times

We stream through Restream to Facebook and YouTube. Today we had Restream end the stream unexpectedly multiple times, then the cache started climbing. I read on here that the temp may have something to do with it so I put a fan on the Atem mini pro and the computer. From then on, the cache stabilized and then dropped and the streams stayed on. Not sure what is going on, but thought I would share... As a side note, we are still on windows 10 on our computer with the Atem Software Control and that we are streaming from, in checking, the CPU is not upgradable to windows 11.

#streamen #atem mini pro #ausfälle #cache läuft voll #tonausfall #youtube #video stockt #video mitschnitt ohne ton #firmware #update

Hardware: Atem Mini Pro, 2 Kameras mit 1080/50fps, mit Fritz Box per LAN verbunden. 50 Mbit Upload. Atem in der Fritz Box priorisiert.
Problembeschreibung: Stream stockte, Videodaten kamen sehr gering auf YouTube an. Verbunden mit Tonausfällen. Cache lief beim Atem nach sehr kurzer Zeit voll auf 100%. Ließ sich nur durch Strom Wegnahme abschalten. Video Aufzeichnung erfolgte ohne Ton, trotz Anzeige das Ton aufgezeichnet wird.

Problembehebung: In den Foren wird beschrieben das die neuste Software von Black Magic runter geladen werden soll. Atem Software Control (Version 9.6.2) ! Was aber nicht beschrieben wird ist das in dieser Software eine weitere für die Hardware beinhaltet ist. Diese nennt sich Atem Setup (Version 9.5.1) ! (Firmware). Bei der Installation des Software Paketes wird die installierte Version kpl. entfernt, somit auch alle Einstellungen für den Stream! Leider auch die Einstellung für die Datenrate!!! Sichert euch die Einstellungen vor der Neuinstallation, somit könnt ihr die Sicherung in Windows oder bei Apple 1:1 übernehmen. Hierzu gibt es Anleitungen im Web wo ihr diese XML Dateien auf euren Rechnern finden könnt. Hintergrund ist der, das die Auswahl zur User Bitrate nicht mehr vorhanden war und nur HyperDeck High/Mid/Low auswählbar war. Hier wurde dann die volle Bandbreite mit 50 Mbit seitens Internet Abschluss in Anspruch genommen. Mit User Bitrate lag diese bei 8-12 Mbit Upload! Der Stream mit HyperDeck Mid/Low funktionierte bei meinen Tests nicht. Überprüft auch die Firmware eurer Fritz Box. Wir hatten dort automatische Updates eingestellt, was aber nicht durchgeführt wurde! Konkret hatten wir 7.5.x drauf, nach dem Update 8.0.x, ein großer Sprung! Nach diesem Firmware-Update reagierte sogar der PC um einiges schneller! Tests zuvor und danach mit Speedtest nahezu identisch. Aber die Reaktionszeit fühlte sich schneller an.

Abschließend möchte ich den hervorragenden Support der Video Abteilung von Thomann erwähnen! Sie stellten ein kostenloses Leihgerät zur Verfügung und reagierten telefonisch sowie per Mail sehr schnell und hilfsbereit!!!

Ich hoffe und wünsche anderen Nutzern das dieser Beitrag zu eurer Problemlösung beihilft und ihr nicht Wochen im Dunkeln tappen müsst.
Eine gesegnete Weihnachtszeit!
HJ Germany

I updated the firmware yesterday on our ATEM Mini Pro to 9.5.1 and it did NOT make any difference. We still got buffering errors during the service and I had to go "off air" and clear the buffer several times. Once the buffer was cleared and it showed we were no longer "on air", I would hit the go live button again. Eventually, we got a YT server that did not give us the error message and the cache did not fill up. This seems to support the idea that certain servers are capable of handling the streams coming from the ATEM Mini Pro while others are not.

Thanks Pancake

I installed new software a month ago, but your note finally triggered my memory that installing new software on my controlling computer DOES NOT install firmware on the ATEM Mini. That is a separate manual process!!!! I have been lazy and not upgraded code in two years and had forgotten the steps.

So for all reading this with caching and video errors from YouTube, upgrade your ATEM switcher.

Install the latest software on your PC or Mac. Select the File pulldown and select Connection . At the PopUp window, press: ATEM setup. A msg will pop up stating there is an update available. Install that.

Back in the ATEM control application I set Stream output to "YouTube SRT. (Beta)". SRT is Secure Reliable Transport. I want reliable! Even though it is beta, it seems stable.

Finally back to error-free Livestreams.

Someone mentioned recording issues. I'll test that next, but we only record to see a couple of times a year so it is a lower priority.


Sent from my Pixel 7a using Tapatalk

I updated the firmware yesterday on our ATEM Mini Pro to 9.5.1 and it did NOT make any difference.

That is unfortunate to hear. Can you post your other streaming settings here? Are you using rtmp or rtmps in both YouTube Studio and in the switchers.xml file? What bit rate are you targeting? What speed can your internet connection handle?

I've just run two days of both 7-hour streams, and they went flawless with the streaming settings that I mentioned earlier. Absolutely no problems, and it proved that the ASUS router we have in between the venue's network and our ATEM Mini Extreme was of no influence. I was very happy, the outlook on last Thursday when I first discovered this issue wasn't making me hopeful.

Are you using rtmp or rtmps in both YouTube Studio and in the switchers.xml file? What bit rate are you targeting?

Where do I find these xml files? Also, where do I view the targeted bit rate?

Are you using rtmp or rtmps in both YouTube Studio and in the switchers.xml file? What bit rate are you targeting?

Where do I find these xml files? Also, where do I view the targeted bit rate?

Randy, it's just one XML file. You have to read back in this thread to know what the issue at hand was. You have different streaming quality (bitrate) settings which are defined in the switchers.xml.

@kenbobpdx and @randyg

If you have successfully installed 9.5.1 on your switchers, then in the Output Streaming tab you will see the first option is "YouTube SRT (Beta)". SRT is Secure Reliable Transport. Give that a try - it is working well for me.
Ignore my suggestion if you are not streaming to YouTube.

The cash filling problem is never solved or even reacted to by black magic. It is the worst behavior of the whole line of atem mini products. I have experienced these cache full 'crashes' with all my mini's and I had/have them all starting with the mini pro. The extreme iso has exactly the same problem. One thing in the big avoidance game which I have not yet seem mentioned is that it helps to lower the frame rate output of the atem. Whenever I do low bandwidth gigs and I need to set the 'streaming low' setting, I switch the atem mini to 24frps to keep a decent image quality.

The cash [sic] filling problem is never solved or even reacted to by black magic.

Jan, did you update the firmware on the ATEMs? As you can read in this thread, I was struck by this problem but new firmware fixed it. I did two 7-hour streams without any hiccups, 30fps.

My guess is that other things solved your issue. Mybae your bandwith just got better I always update the software and firmware to the latest. Expereinced the cache full during testing yesterday again. The issue is not solved in the software as also I cannot find any mention or reaction by Black Magic to this problem anywhere.

The cash [sic] filling problem is never solved or even reacted to by black magic.

Jan, did you update the firmware on the ATEMs? As you can read in this thread, I was struck by this problem but new firmware fixed it. I did two 7-hour streams without any hiccups, 30fps.

My guess is that other things solved your issue. Mybae your bandwith just got better

I notice your smiley, but in two completely different locations, with completely different networking hardware in the mix? No, I don't think so.

also I cannot find any mention or reaction by Black Magic to this problem anywhere.

I have to agree on that. Maybe I didn't search for it in the right places, but to me it seems as BMD is not being straightforward here. But you did see this message, right? Although circumstantial, this describes exactly what I have experienced, and apparently BMD was aware of. But why are they keeping this quiet?

My guess is that other things solved your issue. Mybae your bandwith just got better

I notice your smiley, but in two completely different locations, with completely different networking hardware in the mix? No, I don't think so.

also I cannot find any mention or reaction by Black Magic to this problem anywhere.

I have to agree on that. Maybe I didn't search for it in the right places, but to me it seems as BMD is not being straightforward here. But you did see this message, right? Although circumstantial, this describes exactly what I have experienced, and apparently BMD was aware of. But why are they keeping this quiet?

mmm I did not see that post. But was the latest update not after this message? I checked again after you mentioned it to see if I indeed had the latest updates/firmware on both my mini pro iso and extreme iso and I had. The test yesterday I did set to 'streaming middle' and the cache filled up. I just wanted to try if the cache-crash problem was still there. I do not think it was caused by YouTube. The test was to see if my phone could handle it being the upload device because we are currently at a location (Batenburg) with not too good mobile connection. When switching back to 'streaming low' at 25 frames ps I had no issues at all anymore. So in this case not the youtube problem you guided me to. But thanks for that anyway Most important I learned today was reading that when you hit stop and it does not react, the atem has not crached and recording keeps running. Not that I need that because the whole reason I have two atems is that I want to record the live mix at the higest quality while broadcasting in a lower quality. Thank you for your reactions. Much appreciated.

But was the latest update not after this message?

It was, just as the poster of that message already predicted. So as I see it: there was a problem, BMD fixed it. But they seem to have kept it quiet.

What I did to solve the cache problem:
1. Run "ATEM Setup"
2. It automatically asked me to update to the latest firmware.
3. Waited for it to complete the firmware update and recycled power.
4. Then run ATEM software.
5. On AIR

Three Sundays already no issues.

Same problem here, Atem Mini Extreme running 9.5.1 . When I broadcast from the Restream studio on my PC (connects to ATEM via USB), there are zero glitches and no dropped frames. When I try to stream directly from the ATEM it works sometimes, doesn't work other times, with the cache filling up and providing a poor experience for the viewers. Atem is on a chill pad, firmware updated, rock solid gigabit ISP connection thru Ubiquiti DMP with an isolated WAN for the ATEM and broadcast PC, and a 5G cellular backup connected to the ATEM. Because of all the aforementioned steps I'm absolutely certain the problem lies within the ATEM itself. The ATEM is brand new out of the box in the last 90 days. Would love to have someone from BMD figure out what's going on and solve the issue which many seem to have, and include 4k support. Even with the issues I still love the ATEM and feel it's the best product out there to meet our needs, and I'm thankful for a great year broadcasting with BMD, Ubiquiti, Restream, and all the other great companies out there!

Had a few weeks where our livestream was down and wouldn't work; changed MacBook profiles, usb cables, Cat ethernet cables. So with all the switches, it was hard to narrow down the problem. General FYI, there's no warning, or specific indicator that a cable needs to be switched out with the ATEM. We got the new 40gbs usb-C cable, and it immediately came on. Then in the switch we unintentionally swapped to an ethernet cable that was bad, so there was all types of errors and limitations on our ability to go live.


But after rereading some of the later posts, and spending two weeks streaming with OBS no problem (but with the unintended and undesirable latency), realized that we should stream on a lower setting. We were already streaming on Medium, but cache still filled so now we're on low with no issues. So probably stream on a lower setting than you think you need.

Buy any different encoder and problem will be gone .. I was bought some cheap AVMATRIX now and works like charm ..

ATEM Switchers 9.6.3 Update seems to fix the buffer issue for YouTube on ATEM Mini Pro

I had same problem this weekend. It seems that when recording and streaming at the same time on the ATEM, and cache fills up, there will be a problem with stopping the recording on the hard disk.

What happened was like this:

I started recording and streaming and for about 20 mins everything was fine. I have set the streaming to Low so that only 4.5Mbpsis required. After about 20 mins, I saw the cache filling up... Up to 45% and then back to 0. then it started ramping up until cache was full. Stream was lagging and there were multiple dropped frames.. however audio seemed to be without any issues. I stopped stream, disconnected my 4G modem and connected it more near the door, and restarted stream. In the meantime recording kept going on. Once restarted stream, cache filled up to 63% and remained constantly like that until the end of the event. I stopped the stream and when I came to stop the recording, no matter how much i press the STOP button it didn't stop. The led on the SSD (Samsung T5) was flashing so i though it was still writing content to it from cache. I left it until I dismantled everything and was still flashing. So i decided to leave the mixer overnight plugged in and see if till the morning this would be solved. However 12 hours later and still the STOP button of the recording was unpressable. I had to power off the atem from the power source.

Recording and streaming on ISO is not reliable. Thanks god i was outputting a PGM to a video assist where i was recording the event to, as else I would not have a copy. Blackmagic need to up their game and have these units more reliable! One option would be to use dynamic bitrate like OBS does, and adapt the stream according to the upload speed the internet connection is currently having.