Quote from https://developer.apple.com/documentation/foundation/url_loading_system/downloading_files_in_the_background#3038438 " When the system resumes or relaunches your app, it uses a rate limiter to prevent abuse of background downloads. When your app starts a new download task while in the background, the task doesn't begin until the delay expires. The delay increases each time the system resumes or relaunches your app. As a result, if your app starts a single background download, gets resumed when the download completes, and then starts a new download, it will greatly increase the delay. Instead, use a small number of background sessions — ideally just one — and use these sessions to start many download tasks at once. This allows the system to perform multiple downloads at once, and resume your app when they have completed. Keep in mind, though, that each task has its own overhead. If you find you need to launch thousands of download tasks, change your design to perform fewer, larger transfers. Note The delay is reset to 0 whenever the user brings your app to the foreground. It also resets if the delay period elapses without the system resuming or relaunching your app." So you want a single session that launches (aka USUrlsesson.downloadtask(...).resume()) as many download tasks simultaneously as possible. If you just issue a single download task at a time, then your 2nd, and 3rd download tasks would be delayed by OS system gradually, at last your download task stops.

I came across laodingrequest being cancel after 1 sec like the op. But actually it is stalled on [AVPlayerItemVideoOutput hasNewPixelBufferForItemTime] which is solved by re initializing the whole Player Item output https://stackoverflow.com/questions/24800742/iosavplayeritemvideooutput-hasnewpixelbufferforitemtime-doesnt-work-correctly