ContentProvider acting strange

When making a loading screen I use this common method to wait until everything is loaded:

while ContentProvider.RequestQueueSize > 0 do

However, most of the time it finishes without everything being loaded. I’ve noticed that sometimes the queue size rises after it has hit 0 which is the cause. What is causing this? And is there an alternative way I can check to see if everything is loaded?

1 Like

This happens to me aswell. As I was taking a look at Shift+F3 and the RequestQueueSize, I noticed that the numbers isn’t only decreasing, it sometimes decrease and also increase and at some point it’s very random. In those “random” times, it might hit 0 and then spike back to 300 making the loading screen load without the entire game actually loading.

1 Like

If this is a bug report this is not the procedure to report a bug, you can see the process to take at

This is obviously a question and asking for others’ support and to see if they found a way around it. This has been a thing for a while, probably years.

It sounds like OP is reporting a bug, they are stating that

is not providing accurate results, I don’t how else you would read this message without it sounding like a bug report.

1 Like

The request queue size is increased when ContentProvider:PreloadAsync is called or assets are used for the first time, which is probably what’s going on here. As more assets are rendered/shown, the request queue size increases appropriately.

This is not a bug, rather documented and expected behaviour. @Astralyst @OverHash

Also, note that it’s a bad idea to wait for the queue size to drop to zero before starting the game. This will ruin the experience of those with low-end network connections; players should be able to join games as soon as possible. Use DataModel:IsLoaded and DataModel.Loaded with ReplicatedFirst’s functionality if you’re going to create a custom loading screen.


RequestQueueSize is a dynamic property, for which it’s name is very literal. It is the size of the queue of assets left to download for the first time.

Preloading does not increment this value if the asset exists in the DataModel, it bumps the asset up to the front of the list; the value gets incremented only if the asset isn’t there, because now you’re introducing a new asset to the cache.

I personally only rely on this as a lazy workaround for loading screens, but it’s not really the best idea. Depending on networks, devices and the server region, loading could take an abysmal amount of time. You can wait until DataModel.(Is)Loaded returns a true value, which will determine when the server finished replicating it’s assets to the client. After that, you can preload any assets you need immediately available, then dismiss the screen when this assets have loaded.

cc @Dandystan
(Corrected a point or two)


I understand what you mean, but it took a second. To clarify for everyone else: “first time” means the first time for that particular asset, not first time on game join. Each asset gets downloaded once. Any time an asset needs to be downloaded – be it at the beginning, middle, or end of the session – RequestQueueSize goes up by 1 then goes down once the asset is downloaded.

Using RequestQueueSize for this is not a good idea:

  • The behavior may change in the future, and the queue might run out a lot later than it use to, causing your loading times to increase. Roblox has no obligation to keep RequestQueue behavior the same since this is not what you’re supposed to use that property for.
  • Even when this does function how you would expect, devices on bad networks will have to wait a long time for assets that likely are not essential to the game. You might even lose players that don’t like waiting at the loading screen. Even if you switch to PreloadAsync, keep this in mind!

If you need to wait for some assets that are essential to the game, you should be using ContentProvider:PreloadAsync.


As @Corecii said, try and utilise PreloadAsync for any necessary items in the game.

My only critique to your code is that your “while” statement will not work if the queue is zero when it reaches that line. Instead, use a repeat loop that checks whether it does equal zero. I also recommend making your wait()'s longer (maybe a second or so) as it gives your client time to get all of the items collated together.

Apart from that, not sure what else to help with :D!

This isn’t really an issue. If there’s no items in the queue, you don’t want to wait for nothing – that’s a bit silly. while is better here because it means that if there’s no items in the queue you won’t wait at all.

This also isn’t an issue. How long your waits are does not affect how quickly Roblox works through the queue. Shorter wait time means faster response after the queue empties.

An objection to both of my corrections: you might need to wait for a little bit of time in order for Roblox to add items to the queue. The queue might be at 0 while there are still some items that need to load but Roblox hasn’t added them yet.

Neither of the above proposed changes is a guaranteed fix for that issue:

  1. Because there is an undefined amount of time before objects get added to the queue, you don’t actually know how long to wait. Your arbitrary additional wait time might work on your computer, but on a different computer, different network, or after a Roblox update, it may not solve the issue.
  2. Because loading assets takes a variable amount of time, you can still coincidentally hit a point when the queue is 0 before Roblox picks up more items to load, regardless of how long your wait time is.

The only way to solve both of those issues is to use PreloadAsync:

  1. You’ll know that all of the objects you want to load are in the queue.
  2. You’ll know exactly when it finishes, and you’ll know that nothing else you want to preload is still in the queue.

That’s true, but I suggested the repeat loop because it means that it’ll atleast attempt a wait before checking whether there are items in the queue. After testing in studio, a while loop will completely skip forward past the loop, if it == 0, while a repeat loop will atleast do it once before going ahead with the script. It is likely also necessary to know what needs to be loaded and you are right to presume that. I didn’t put as many details in my last post as I’d liked.

Apart from that, no, it is not a proposed fix but he can always try a different method and it might work better. I think ideally, it’d work pretty well for a loading screen as it won’t dismiss it instantly if there wasn’t anything anything to load at the start. To be honest it was a really hacky alternative that I typed on the way to math class (so sorry if it’s a rash response). @Dandystan’s method of waiting till game.Loaded is probably the most ideal in my eyes.