Course Download Does Not Resume and Only First Page of Courses Is Fetched

[mrrauf99]

Hi there!

I installed the desktop app and started downloading a course. After some time, I closed the app and opened it again later. However, the download always starts from the very beginning instead of resuming from where it stopped.

This causes unnecessary download time and data usage. The app should preserve the download progress and resume from the point where it was interrupted.

There is also another issue with course fetching. The app only fetches the courses from the first page instead of fetching all courses included in my plan. Courses on subsequent pages are not displayed or available for download.

Expected Behavior

• Interrupted downloads should resume from the last completed point.
• Download progress should persist after closing and reopening the app.
• The app should fetch all courses available in the user's plan, including courses across multiple pages.

Actual Behavior

• Downloads restart from the beginning after reopening the app.
• Only courses from the first page are fetched.

Please look into these issues, as they result in unnecessary data usage and prevent access to all courses included in the plan.

[tonhowtf]

Thanks — I traced both. One of them is narrower than it looks, and the other I can point at precisely but need one line from you to confirm.

1. Resume

There are two different kinds of "resume" here, and OmniGet does one of them and not the other.

Per-lecture resume works. Before downloading a video, the plugin checks whether the file is already there with content:

if file_exists_with_content(&file_path) {
    tracing::info!("[udemy] skipping existing video: {}", file_name);
    return Ok((0, 0));
}

So re-running the same course into the same folder skips everything already finished and picks up where it stopped. You should not be re-downloading completed lectures.

Within-a-file resume does not exist, and that's a real gap. The downloader opens the partial file with File::create — which truncates — and issues a plain GET with no Range header:

let mut file = std::fs::File::create(part_path)?;

So a lecture interrupted at 90% restarts from byte 0. On a long video that's a meaningful waste, and it's exactly the "unnecessary download time and data usage" you describe. This is a legitimate bug: the .part file already exists as a concept, it just isn't used for what .part files are for. Range-request resume is the fix.

But your report says the download "always starts from the very beginning", which is stronger than that. If completed lectures are being re-downloaded too, something else is wrong and the per-lecture skip isn't firing — most often because the output folder differs between runs (a rules-engine rule, or a changed default download directory), so it's looking for the files somewhere they aren't. Worth checking that the second run really is writing into the same course folder as the first.

2. Only the first page of courses

I can point at the suspect line. list_my_courses asks for every course in a single page:

/api-2.0/users/me/subscribed-courses?...&page=1&page_size=10000

10,000 is far outside what Udemy's API accepts for page_size. The pagination loop underneath it is written correctly — it follows the next link until it's null — but there's a bail-out in front of it:

let count = data.get("count").and_then(|c| c.as_u64());
if count.is_none() {
    tracing::warn!("[udemy-api] response missing 'count' field. Keys: {:?}", ...);
    return Ok(data);      // <- one page, pagination never runs
}

If Udemy answers that oversized page_size with an error shape instead of a normal paged response, count is absent, that early return fires, and you get exactly one page — silently, apart from a log line. That matches your symptom precisely. A sane page_size (100) plus the loop that already exists would be the fix.

What would confirm it, and turn this from "very likely" into "certain": open %APPDATA%\wtf.tonho.omniget\logs\ (or ~/.local/share/wtf.tonho.omniget/logs/ on Linux, ~/Library/Application Support/… on macOS) and search for udemy-api. Three lines decide it:

• response missing 'count' field. Keys: [...] → confirmed, it's the bail-out above.
• fetching page 2, page 3, … → pagination is running and the truncation is elsewhere.
• found N subscribed courses → tells me how many it actually got.

Also worth noting: a subscription plan (Personal Plan) is fetched from a different endpoint than purchased courses — subscription-course-enrollments, with page_size=50 — and the two lists are merged. If your plan courses are missing but purchased ones are all there, that narrows it to that second call, which is useful to know.

Both of these live in the courses plugin rather than the app, so they ship as a plugin update through the Marketplace. Keeping this open; paste those log lines and I can fix the pagination one with confidence rather than by guess.

[mrrauf99]

Feature Request: Resume Downloads After System Shutdown + Module-Level Downloads

I wanted to discuss two improvements related to course downloading in OmniGet.

1. Course Fetching

I tested both Personal Subscription and Business Subscription, and both work correctly.

One issue is that some courses I want to download do not initially appear in the course list. However, I found a workaround:

1. Enroll in the course.
2. Randomly play 1 to 3 videos from the course.
3. Refresh OmniGet.
4. The course then appears in the list.

So, for now, course fetching can be skipped or treated as lower priority, since there is a workaround to make the course appear.

2. Resume Downloads After Laptop Shutdown

The resume functionality works correctly when I close OmniGet and reopen it. The partially downloaded course continues from where it stopped.

However, there seems to be an issue after a full system shutdown/power-off.

For example:

• Start downloading a course.
• Download part of it.
• Power off the laptop.
• Turn the laptop back on.
• Start downloading the same course again.
• The download starts from the beginning instead of continuing from the previous progress.

Since the partially downloaded files are still present, it would be very useful if OmniGet could persist and restore the download state even after a system restart or shutdown.

3. Module-Level Downloading

Another feature that would be extremely useful is module-level downloading.

Currently, a course can contain many modules, but some modules may be unnecessary for the user. Downloading the entire course in such cases wastes:

• Time
• Storage space
• Internet bandwidth

It would be helpful to have a UI where we can expand a course and select the specific modules we want to download.

For example:

Course
├── Module 1  ☑
├── Module 2  ☑
├── Module 3  ☐
├── Module 4  ☑
└── Module 5  ☐

[tonhowtf]

Both confirmed in the code and fixed; ships as courses plugin 1.0.6.

Resume. The downloader now sends Range: bytes=N- when a .part file exists and appends on 206, restarts on 200/416, and checks the final size against what the server announced. For the power-off case you described: a file whose size was already on disk but whose last blocks never made it is detected by a zero-filled tail check on the .part file, and that tail is trimmed before resuming instead of splicing zeros into the video. .part files are no longer deleted on error, precisely so the next run can continue them. Per-lecture skip of finished files is unchanged.

Only the first page. page_size=10000 is gone (both the purchased-courses and the Personal Plan subscription-course-enrollments calls use 100 now), the early return on a missing count is gone, and pagination follows next until it is null with a loop guard. Your workaround (open a lecture so the course shows up) is a Udemy-side quirk of subscribed-courses ordering, not something the app can change.

Module-level download. Also in: courses now have a "Choose sections…" link under the download button that lists the course sections with lecture counts (and how many are DRM-locked), all selected by default — untick what you do not want. It uses a new udemy_get_curriculum command, so it needs both the plugin update and the next app release.