AssetManager load queue stalls at 75% progress

Question

AssetManager load queue stalls at 75% progress
In a libgdx project using AssetManager to load multiple textures asynchronously, the getProgress() method reports 0.75 and never reaches 1.0 even after repeated calls to update(). The AssetManager is initialized on the main thread, and update() is invoked inside the render loop. All assets are queued with load() before the first call to update(). The OpenGL context is active during rendering, and no errors are logged. The goal is to determine why the loading queue appears to halt at 75% and whether the issue is related to reference counting, backend behavior, or queue management.
Specific questions:

What internal condition can cause getProgress() to stop advancing after a certain threshold?
Does the presence of a shared texture across multiple scenes affect the reference count and stall the queue?
Is there a known backend difference between desktop and Android that could explain a partial loading halt?

Siddharth · Answer

Resolving AssetManager Progress Stalls
A stall at a specific percentage (e.g., 0.75) in AssetManager.getProgress() typically indicates that one or more queued assets have failed to transition to a "loaded" state, but have not thrown an exception that would terminate the update() loop. Because the progress is a ratio of completed tasks to total unique queued tasks, the queue halts when the remaining assets are blocked by a dependency or a hanging loader.

Likely Explanations

Dependency Cycles: If a custom AssetLoader is used, a circular dependency (Asset A depends on B, which depends on A) or a self-dependency will prevent the asset from ever completing.
    Hanging Loaders: A loader that enters an infinite loop or deadlocks during the loading phase will stop the queue without necessarily logging an error to the console.
    Missing Dependencies: If an asset depends on another file that was never queued via load(), the manager may wait indefinitely for that dependency to be resolved.

Confirmed Facts

Reference Counting: Sharing a texture across multiple scenes does not stall the queue. AssetManager coalesces multiple load() calls for the same asset into a single queue entry; reference counting only affects when an asset is finally removed from memory during unload().
    Platform Consistency: The AssetManager queue logic is platform-independent Java. There is no inherent difference between Desktop and Android backends that would cause a partial loading halt.

Resolution Steps

Force Synchronous Loading: Replace update() with finishLoading() in a controlled test environment. Because finishLoading() blocks the main thread, the application will hang exactly at the problematic asset, allowing you to identify the culprit via a thread dump or debugger.
    Enable Debug Logging: Set the log level to DEBUG to catch loader exceptions or repeated dependency resolution attempts:
        Gdx.app.setLogLevel(Gdx.LOG_DEBUG);
    
    Audit Custom Loaders: If using custom loaders, verify that getDependencies() does not return the asset's own path or create a loop.

Required Diagnostic Detail
Are you using a custom AssetLoader or a modified AsyncExecutor? If so, the issue may be a silent hang caused by attempting OpenGL calls on a background thread, which some drivers handle by freezing rather than crashing.

AssetManager load queue stalls at 75% progress