I checked and the dashboard does seem to be malfunctioning. Here’s a temporary workaround while we work on patching it.
In the global resource group there is a storage account named <abcxyz>admin. Go to Containers in the left side panel and in the zips folder is a file called unreal_1.zip, which is your app. The app gets downloaded and unzipped with each new VM, so you can directly replace this with your updated version. You’ll need the name to exactly match unreal_1.zip and you upload with the “Overwrite” option. (You might be able to use the “Uploads” folder and increment versions there, but this seems more direct)
Any new instances will grab it, but for running instances you’ll need to manually delete them from the “Instances” tab in the VMSS for each region so a new one is created. Alternatively you can use the “Scaling” tab to manually set the instance count to 0. Hopefully this works for you.
One other layer of protection would be to make a clean or personalized distribution URL that redirects to the traffic manager, so that a new deployment could be used without changing the user-facing URL. It’s obviously too late for that to solve the current situation and shouldn’t be necessary for this current issue we’re facing.
Thanks for this Stephen! We will try out this solution in the meantime.
We were already thinking about creating a distribution url to redirect to the traffic manager just for user readability and also being easily remembered (5 random characters at the start of a URL isn’t the easiest haha) so we will implement this too!
Thanks again for looking into this so quickly, looking forward to the patch
If we have an update for the matchmaking servers and web frontend, how would we update that? Would stopping and starting the matchmaking VM allow any updates to trickle down to there as well?
In the same “zips” folder where the app lives, there’s a zip called “msImprovedWebservers.zip”. Not sure if it’s the same for you with a custom one. By default, that file gets downloaded with each new VM just like the app, so you should be able to replace anything here. Luckily it’s not all baked into the VM itself.
The VMs with the UE app also host the frontend web page, so instructions for refreshing them are the same as above. The matchmaker VM is not scaling up and down fresh machines like the UE scale set, so if you have custom matchmaker code to replace you might need to RDP in the matchmakers, replace stuff, and restart.
If we use a custom websignalling/webservers, do the various configs during deployment getting overridden? I’ve noticed in the webservers that there are settings for all the things that get set in the azure template/deployment such as scaling, resolution, turn/stun etc. from memory. I mostly just want to know that if we are overriding the webservers, do we need to ensure azure settings are replicated into the webserver source files or if that gets handled dynamically.
I’ve been doing some testing today, and it seems that I now only can’t create new versions in the dashboard if the percent buffer is set to 0, despite setting it to 0 working in the azure template. It does fail quietly so no specific errors to give you though
EDIT:
Using the scaling tab to set instance count to 0 seems to break the deployment actually, at least for me. I start getting “all cirrus servers are busy” on the matchmaker. I have tried setting to 0 and then letting the webservers bring up more VMs (they didn’t, it is stuck at 0 instances) and setting it back to 1 instance. Both methods seem to break the deployment.
Hey, I ran into the same problem. I made the edit to install the certificate inside the file Start_Azure_SignallingServer. This works for me but I have to remote into each instance and restart unreal to be able to use the plugin that requires the certificate.
Do you have any insights into which scripts to edit so that I can install the certificates before unreal starts?
The default Signaling Server deployed by Azure Marketplace deployment is not working for me. It instantly disconnects and crashes the video game with the error ‘streamer disconnected: 4000 - failed to parse answer’s SDP’. The only fix i found was updating the app.js with the fix found here: Pixel Streaming not working in Chrome version 89 - Development / Programming & Scripting - Epic Developer Community Forums (unrealengine.com) which is adding offer.sdp = offer.sdp.replace(“a=extmap-allow-mixed\r\n”, “”) to the SetupWebRTCPlayer. Why is this necessary? My Chrome and MS Edge is fully updated. I would like to avoid customizing the web server deployment for this. Is this an outstanding bug in the default version or perhaps some other issue I have in my game or other deployment settings.
@Mattttrick What version of Unreal Engine are you using? And did you specify HTTPS or HTTP when you deployed?
The root cause of the error you linked to for Chrome version 89 was definitely fixed. I remember when that happened and when the fix was implemented. I haven’t seen this SDP error come up recently.
@OwenAlister1 Unfortunately I don’t have a fix in mind for the problems with certificates. I’m curious about what plugin requires certification?
Thanks for the great solution, however there is a “big” problem that happens right now, trying to setup the solution from Azure marketplace, and all the NV12s v3 instances are backlogged… I was told by Azure support I would be notified in a month if there was any openings, but that its not looking good.
Any other instanced (even if more expensive) can run the offer ?
If not, what changed to config are needed to get it to work on another type of GPU ?
Uh oh. That’s not great. The solution defaults to NV12s_v3 because that was supposed to be the most available. The better VM to use is NC8as_T4 if you can get a quota for it. And if money is no issue, you can try to get quota for NV*ads_A10, but unless you go for the priciest one, you don’t get a full GPU reserved.
The complete list of supported VMs is:
“Standard_NC4as_T4_v3”,
“Standard_NC8as_T4_v3”,
“Standard_NC16as_T4_v3”,
“Standard_NC64as_T4_v3”,
“Standard_NV12s_v3”,
“Standard_NV24s_v3”,
“Standard_NV48s_v3”,
“Standard_NV6ads_A10_v5”,
“Standard_NV12ads_A10_v5”,
“Standard_NV18ads_A10_v5”,
“Standard_NV36ads_A10_v5”,
“Standard_NV36adms_A10_v5”,
“Standard_NV72ads_A10_v5”
You could theoretically build a custom AMD image, but the hardware is limited to the above list unfortunately.
Keep in mind that quotas are per-region, so try some alternative regions if your first pick is backlogged.
That explains the error, as that first came up when 4.26 was current, and your fix was implemented in 4.27. Significant improvements were made to the pixel streaming plugin for 4.27+, and this solution does not support older versions. Can you upgrade your project?
Perfect, it kept returning quota not met errors when I tried other instances, I guess is it something else and I’ll see with Azure support, thanks a lot ! This list probably should be added to the tutorial because there are a lot of options . If I find a proper solution I’ll share it here.
When using a custom domain with https enabled it asks for a Base64 encoded Public & Private key.
How would I go about generating this data?
Do I need to create a SSL/TLS wildcard certificate or is that something that gets created for me during the deployment?
You have to provide this yourself. " To use HTTPS, you must have an Azure DNS resource enabled and have the public and private key pair in base64 encoded format."
We are testing with the First Person Project UE 5.1 and the PixelStreaming plugin activated, inserting the modification files without touching them from “WebServers_Marketplace_4.27.2.zip”, since our application will have some small changes in the Signalling Web Server.
. If I find a proper solution I’ll share it here.