Why Does a Video Download Keep Restarting? Common Causes and Fixes

A download that starts over can be more confusing than one that simply fails.

You may watch a video reach 20%, 50%, or even 90%, only to see the transfer appear to begin again. Sometimes the speed briefly drops and then returns. Sometimes the same operation is retried several times. In other cases, a job actually fails and a completely new download has to be started.

Those situations can look identical from the user's point of view.

They are not.

A retry, a restart, a resume, a re-download, and a processing failure are different events.

Understanding that difference is the first step toward fixing the problem.

With MediaFetches, the server-side flow is broadly:

User → MediaFetches job → queue → preparation → yt-dlp download → processing → finished file → user

A problem can occur at several different points in that chain.

The goal of this guide is therefore not to tell you to repeatedly press Download.

It is to help you determine what actually restarted.

What Does "Restarting" Actually Mean?

When someone says "my download keeps restarting," they may be describing several different behaviors.

A temporary retry

A network request can fail temporarily and the downloader can attempt that operation again.

For example:

request → connection interruption → retry → continue

The entire video does not necessarily start from the beginning.

yt-dlp supports separate retry mechanisms for downloads and media fragments. Its current documentation lists configurable general retries and fragment retries.

A progress reset

A progress indicator returning to 0% is more significant.

It can mean that the operation being measured has changed, rather than proving that every previously transferred byte was discarded.

For example, a downloader may be retrying a particular operation while the user interface is displaying the state of a new attempt.

So:

0% again does not automatically prove "the entire video was downloaded again from zero."

You need to determine what operation actually restarted.

A new MediaFetches job

This is different.

If you submit the same URL again and MediaFetches creates a new job, that is genuinely a new server-side download request.

It should not be confused with an internal retry performed by the downloader.

A resumed finished-file download

There is another completely separate situation.

Suppose MediaFetches has already prepared the final file and your browser, phone, or download manager is saving that finished file.

If the connection between your device and MediaFetches breaks, the client can potentially request another byte range from the already-finished file.

HTTP Range requests are specifically designed for requesting portions of an existing resource and can be used by download managers to resume interrupted transfers.

That is not the same thing as MediaFetches resuming the original extraction from the source.

Retry, Restart, Resume, and Re-Download Are Not the Same

Think of the five terms like this:

Retry

The downloader tries an operation again after a problem.

Restart

An operation begins again from an earlier point or from the beginning.

Resume

A partially transferred resource continues from a previously received portion.

Re-download

A completely new request retrieves the media again.

Processing failure

The source transfer may have completed, but the final file could not be produced successfully.

These distinctions matter because the correct troubleshooting step is different for each one.

For example, a temporary network error may justify allowing a retry.

A source-specific problem may require trying again later.

A processing failure may have nothing to do with your internet connection.

And a finished-file transfer can use HTTP Range support without implying that the upstream source extraction is resumable.

Why a Video Download Can Keep Retrying

Unstable network connections

A large transfer depends on a working connection for a much longer period than a short webpage request.

A brief interruption can therefore become visible as a retry.

This can happen with:

unstable Wi-Fi weak mobile-data coverage temporary loss of connectivity network switching packet loss router problems

ISP routing problems

The important point is that a temporary network interruption does not necessarily mean the entire download must be discarded.

Whether a particular operation can continue depends on the downloader, the protocol, and how the source delivers the media.

Source-server interruptions

The source is another possible failure point.

The path is not simply:

your device → MediaFetches

It is:

your device → MediaFetches → source

MediaFetches has to retrieve the media from the source before it can produce the finished result.

If the source server temporarily stops responding, returns an error, interrupts a media stream, or changes the availability of a media resource, the downloader may retry an operation.

That can look like the download is randomly starting over even though your own internet connection is fine.

Rate limiting

A source or service can limit repeated requests.

HTTP 429 means Too Many Requests and is specifically used for rate limiting. A server can also provide Retry-After to tell a client when it should try again.

This is why repeatedly submitting the same download request is not a good troubleshooting strategy.

If the problem is rate limiting, hammering the source with more requests is the opposite of what you want.

Connection timeouts

MediaFetches currently configures yt-dlp with a 15-second socket timeout and 3 general retries.

These are configuration values, not guarantees that every interrupted download will eventually succeed.

A timeout can cause the underlying downloader to retry a request. If the same problem continues, the overall MediaFetches job can eventually fail rather than retry forever.

Media-fragment problems

Some media is delivered as multiple fragments rather than one simple continuous file.

yt-dlp has separate handling for fragment retries and concurrent fragment downloading. Its documentation lists --fragment-retries separately from general download retries.

This creates an important distinction:

One fragment failing is not necessarily the same as the whole video download failing.

A downloader can retry a particular fragment while other parts of the transfer have already succeeded.

Temporary source URLs

Some media systems use URLs that are valid only for a limited period.

If the access URL expires or becomes invalid, a later request may no longer work.

That can create a pattern such as:

download starts → interruption → retry → source request rejected

The user may see this as "the download keeps restarting," even though the underlying problem is that the source request is no longer valid.

Large transfers expose retry problems more often

Large files simply have more time in which something can go wrong.

A small file might complete before a temporary network interruption occurs.

A large 4K video may take considerably longer and therefore encounter:

a network change a source interruption a timeout temporary rate limiting storage pressure

That does not mean large files are inherently broken.

It means a longer transfer provides more opportunity for an interruption to occur.

Why a Download Can Appear to Jump Back to 0%

A progress reset is one of the most confusing symptoms.

Suppose you see:

0% → 35% → 64% → 0%

There are several possible explanations.

Internal retry versus a genuinely new job

The first question is:

Did MediaFetches create a new job, or did the existing downloader retry something?

These are fundamentally different.

A new MediaFetches job is created when the user starts another job.

An internal yt-dlp retry can occur inside the existing job.

The public MediaFetches job API does not expose a dedicated "retry number" field, so the browser should not interpret every progress reset as proof that a brand-new MediaFetches job was created.

Progress information can change between stages

MediaFetches has separate states for:

queued preparing downloading processing ready failed cancelled

The progress percentage can also be unknown during some stages.

Therefore, a visual change in the progress indicator does not necessarily mean that the underlying media transfer was discarded.

Look at the state and message as well as the percentage.

What MediaFetches Actually Does When a Download Runs

A typical managed MediaFetches job follows this general path:

User

↓

MediaFetches job

↓

Queue

↓

Preparing

↓

yt-dlp extraction/download

↓

Progress updates

↓

Processing

↓

Finished file

↓

User saves the file

A restart or retry can mean something different at each stage.

Queue

MediaFetches has a bounded download queue.

The current default allows 3 simultaneous download processes, with up to 20 queued jobs.

A queued job is waiting for server capacity.

It is not necessarily retrying the source.

Preparing

The preparing stage occurs before normal download progress is established.

If something fails here, the user may see little or no meaningful transfer progress.

That is different from a download that reached 70% and then restarted.

Downloading

This is where yt-dlp reports bytes, total size, speed, ETA, and percentage when available.

The underlying yt-dlp configuration currently includes:

retries: 3 socketTimeout: 15000 concurrentFragments: 8

The project does not explicitly configure a custom fragmentRetries value, so the project's code should not be described as having a special custom fragment-retry count.

yt-dlp itself documents a default fragment-retry setting separately from the general retry setting.

Processing

After the media transfer, MediaFetches can enter:

Processing media…

For video jobs, FFmpeg can be involved in producing the final MP4 output.

This means:

download completed ≠ final file necessarily ready at that exact instant

A processing failure is therefore not automatically a transfer restart.

Ready

When processing succeeds, the job becomes:

Ready to save

The finished file then becomes available through the job's file endpoint.

Common Restarting Scenarios Scenario 1 — Speed briefly drops, then continues

This is not necessarily a full restart.

For example:

4 MB/s → 0 MB/s → 3 MB/s

may represent a temporary interruption.

The most important question is whether:

the byte count continues later the percentage continues increasing the job remains in downloading the job eventually reaches ready

A temporary zero-speed period is different from a complete new job.

Scenario 2 — Progress resets to 0%

This deserves more investigation.

Possible explanations include:

an internal retry a new extraction attempt a new MediaFetches job a change in what the progress indicator represents an actual failed job followed by a new user request

Do not automatically conclude that the entire source was transferred twice.

Check whether the job ID changed.

If you are observing the same MediaFetches job, that is evidence against assuming that the user simply created an entirely new job.

Scenario 3 — Download repeats after a timeout

MediaFetches has a default active-job timeout of 30 minutes.

If that timeout is reached, the server aborts the job and reports:

"This download took too long and was stopped."

That is a job failure, not an unlimited retry mechanism.

The timeout is configurable by deployment settings.

A later attempt by the user creates a new download job. That should not be described as the original job automatically resuming.

Scenario 4 — Same video repeatedly restarts but other videos work

This is a strong clue that the problem may be source-specific.

For example:

Video A → repeatedly restarts

while:

Video B → completes normally

The difference could be related to:

the source's media delivery a particular media stream source availability temporary URLs source-side rate limiting an extractor/source compatibility issue

It does not prove the source is responsible, but it changes what you should investigate first.

Scenario 5 — Every video repeatedly restarts

If unrelated sources all behave the same way, investigate the broader system:

network stability Wi-Fi/mobile-data switching MediaFetches server conditions server resource pressure temporary service problems storage conditions deployment infrastructure

If every source exhibits the same behavior, it is less useful to keep testing the exact same video URL.

Scenario 6 — Download finishes, then fails during processing

This is a different problem.

The sequence may be:

Downloading → Processing → Failed

The source transfer itself may have completed.

Processing can involve FFmpeg and final output creation.

So a failure after the download stage should not automatically be diagnosed as a network retry problem.

Scenario 7 — The finished file itself restarts while being saved

This is another separate layer.

Imagine MediaFetches reaches:

Ready to save

and your browser or device begins receiving the finished file.

If that connection breaks, the transfer between your device and MediaFetches may need to be repeated or resumed.

MediaFetches supports HTTP byte ranges on its finished-file endpoint. It sends Accept-Ranges: bytes and handles Range requests with 206 Partial Content.

HTTP Range support is specifically designed for retrieving parts of an existing resource and is commonly used by download managers to resume interrupted transfers.

But this does not mean the original source extraction is automatically resumable.

That distinction is critical.

How to Diagnose a Repeating Download

Use this sequence instead of repeatedly restarting the same request.

1. Observe exactly what restarted

Ask:

Did the speed briefly drop?

or:

Did the percentage reset?

or:

Did the whole MediaFetches job disappear and a new one start?

or:

Did the finished file download to my device restart?

These are four different situations.

1. Check the progress state

Look for the actual stage:

Waiting for a free slot Preparing your download Downloading media Processing media Ready to save Failed Cancelled

A processing stage should not be diagnosed as an internet-speed problem.

A queue state should not be diagnosed as a source retry.

1. Check the network

If your Wi-Fi or mobile connection is unstable, repeated interruptions become more plausible.

Check whether:

normal websites work another large download works streaming remains stable the device is switching networks the problem occurs on multiple sources

If everything else is unstable, solve the connection problem first.

1. Test another download

Use a different, authorized source.

The result is informative:

Only one video restarts

→ investigate that source.

Many unrelated videos restart

→ investigate network/service/infrastructure conditions.

This is not absolute proof, but it is a useful isolation test.

1. Check the source

If the original media has changed availability, the downloader may repeatedly encounter the same problem.

Do not attempt to bypass access controls or private-content restrictions.

If the source legitimately requires authorization that MediaFetches does not support, there may be no client-side fix.

1. Consider rate limiting

If the same source is being requested repeatedly, rate limiting can become relevant.

HTTP 429 is the standard status for too many requests, and Retry-After can indicate when another request should be attempted.

The safest response is to stop repeatedly submitting the same request and allow the service/source condition to clear.

1. Distinguish processing from downloading

If the state changes from:

Downloading media…

to:

Processing media…

the network transfer is not necessarily the current problem.

Give the processing stage its own diagnosis.

1. Make one controlled new attempt

If the original job genuinely failed, a new attempt can be reasonable.

But avoid this pattern:

Start → fail → immediately start → fail → immediately start → fail

Repeated requests do not make an unstable source more reliable and can contribute to rate limiting.

MediaFetches Retry and Resume Behavior

This is where precision matters most.

The current retry configuration

The current MediaFetches yt-dlp base configuration explicitly sets:

3 general retries

and:

15,000 ms socket timeout

It also enables:

8 concurrent fragments

These values are current project configuration values and can be changed in future code/deployment versions.

They should not be interpreted as a guarantee that every download will recover.

A retry means:

"Try this operation again when the downloader considers the error retryable."

It does not mean:

"The complete download will definitely succeed."

yt-dlp documents general download retries and fragment retries as separate mechanisms.

What noPart means

The MediaFetches project sets:

noPart: true

for its managed download pipeline.

yt-dlp documents --no-part as disabling .part files and writing directly to the output file. This is separate from its --continue option.

That distinction is important.

The presence of noPart: true does not by itself mean that the project explicitly set --no-continue.

The current MediaFetches code does not explicitly configure a continuedl/noContinue option.

Therefore, the safest description is:

MediaFetches does not expose a user-facing upstream pause/resume feature, and its use of direct output means you should not promise that a partially completed source extraction can always be recovered from exactly the previous byte.

Do not turn noPart into a claim that every retry starts from zero.

What the project does not guarantee

MediaFetches does not provide a user-facing control labelled:

Resume Pause Continue from previous source position Retry this fragment Retry automatically forever

The current implementation also has a bounded job lifetime and explicit cancellation.

Therefore:

A retry is possible at the downloader level, but successful recovery is not guaranteed.

HTTP Range support for finished files

The finished-file delivery layer is different.

Once MediaFetches has a completed file, its file endpoint supports:

Accept-Ranges: bytes

and valid byte-range requests can receive:

206 Partial Content

HTTP specifications and MDN describe this mechanism as a way for clients to request only part of an existing resource, including for interrupted download resumption.

So there are two separate paths:

Upstream

Source → MediaFetches

and:

Downstream

MediaFetches finished file → User device

Range support applies to the downstream finished-file transfer.

It is not proof that MediaFetches can resume an interrupted upstream source extraction.

When There Is No User-Side Fix

Sometimes the correct troubleshooting result is:

There is nothing useful to change on the user's side.

That can happen when:

the source is temporarily unavailable the source repeatedly interrupts the media a source URL has expired the source is rate limiting requests the service is temporarily overloaded the server reaches its configured timeout the requested output exceeds the configured server limit the source media cannot currently be extracted successfully

In those cases, repeatedly changing Wi-Fi settings, restarting the browser, or submitting the same URL over and over is unlikely to solve the underlying problem.

Wait when the condition appears temporary.

Then make one controlled attempt when appropriate.

Quick Troubleshooting Checklist

If your download keeps restarting:

Did only the speed drop, or did the percentage reset? Did the MediaFetches job state change? Did the job ID change? Is the job queued, preparing, downloading, processing, or failed? Does another download work normally? Does the original source still work? Could the source be temporarily limiting requests? Could Wi-Fi or mobile data be changing during the transfer? Did the job reach processing before the problem appeared? Did the server report a timeout or another failure? Are you dealing with the finished file download rather than the upstream source transfer? If a new attempt is appropriate, make one controlled attempt instead of repeatedly hammering the same request.

Frequently Asked Questions

Why does my download keep going back to 0%?

A reset to 0% can represent several things.

It may be an internal retry, a new extraction attempt, a genuinely new MediaFetches job, or a progress display changing between operations.

A visible 0% alone does not prove that every previously transferred byte was lost.

Does a retry mean the entire video starts over?

No.

A retry can apply to a particular network operation or media fragment.

yt-dlp has separate retry concepts for downloads and fragments.

Whether previously received data can be reused depends on the specific download method and source.

Does MediaFetches automatically resume a partially downloaded source?

Do not assume that it does.

The project uses yt-dlp retry behavior and noPart: true, but it does not expose a user-facing upstream resume control.

The finished-file endpoint does support HTTP Range requests, but that applies to the completed MediaFetches file being delivered to the user, not automatically to the original source extraction.

Why does the same video keep restarting while other videos work?

That pattern points toward a source-specific possibility.

The source may be delivering that particular media differently, experiencing a temporary problem, limiting requests, or exposing an extractor/media-stream issue.

If other unrelated videos work, repeatedly changing your own network settings is unlikely to be the first thing to investigate.

Why do all my downloads keep restarting?

If unrelated sources all behave the same way, investigate the shared parts of the path:

Your network → MediaFetches server → infrastructure

Check your connection and whether the MediaFetches service is experiencing capacity or temporary infrastructure problems.

Can a finished MediaFetches download resume if my internet disconnects?

The finished-file endpoint supports HTTP Range requests, which are designed to allow clients to request specific byte ranges and can support interrupted-transfer recovery.

Whether your particular browser or download client actually uses Range requests is a separate matter.

Is a processing failure the same as a download restart?

No.

A job can successfully retrieve the source media and then encounter a problem during processing.

With MediaFetches, downloading and processing are separate job states.

So:

Downloading → Processing → Failed

is different from:

Downloading → retrying the source transfer

Related MediaFetches guides

For related guidance, see stuck download troubleshooting and master troubleshooting checklist.

Final Takeaway

A download restarting does not automatically mean the entire file was lost.

First determine what actually repeated:

Retry?

A temporary operation was attempted again.

Restart?

The current transfer began again from an earlier point or from the beginning.

Resume?

A client continued receiving a previously existing resource.

Re-download?

A completely new request was made.

Processing failure?

The source transfer may have finished, but the final output could not be completed.

With MediaFetches, this distinction is especially important because the downloader has its own retry behavior, while the managed job system separately tracks preparation, downloading, processing, and final delivery.

The best troubleshooting approach is therefore:

Observe → identify the stage → isolate the cause → make one controlled attempt

rather than:

fail → restart → fail → restart → repeat

A progress reset is a symptom.

It is not, by itself, an explanation.