Fix progress bar resetting during import/export operations

[rtibbles]

Summary

Fixes issue #5501 where the progress bar would go from 0% to 100%, reset to 0%, then go to 100% again during import/export operations.

Root cause: Multi-phase operations (channel database + content files) each independently reset and tracked their own progress.

Solution:

• Create DiskChannelResourceExportManager that coordinates progress tracking across both export phases
• Add import_channel_database parameter to import managers to include channel database import with coordinated progress tracking
• Update export/import tasks to use the new coordinated managers

The fix ensures:

1. Total bytes are calculated upfront for ALL phases
2. Progress is initialized once at the start
3. Progress updates incrementally through all phases without resetting

References

Fixes #5501

Reviewer guidance

• The main changes are in resource_export.py (new file) and resource_import.py
• tasks.py now uses the new managers instead of separate export_channel/export_content calls
• Test by exporting content to disk and verifying progress bar moves smoothly 0-100% without resetting
• 74 tests pass in test_import_export.py

🤖 Generated with Claude Code

[github-actions]

Build Artifacts

Asset type	Download link
PEX file	kolibri-0.19.1rc0.dev0_git.2.gec745d47.pex
Windows Installer (EXE)	kolibri-0.19.1rc0.dev0+git.2.gec745d47-windows-setup-unsigned.exe
Debian Package	kolibri_0.19.1rc0.dev0+git.2.gec745d47-0ubuntu1_all.deb
Mac Installer (DMG)	kolibri-0.19.1rc0.dev0+git.2.gec745d47.dmg
Android Package (APK)	kolibri-0.19.1rc0.dev0+git.2.gec745d47-0.1.6-debug.apk
Raspberry Pi Image	kolibri-pi-image-0.19.1rc0.dev0+git.2.gec745d47.zip
TAR file	kolibri-0.19.1rc0.dev0+git.2.gec745d47.tar.gz
WHL file	kolibri-0.19.1rc0.dev0+git.2.gec745d47-py2.py3-none-any.whl

[rtibblesbot]

Thanks for tackling this long-standing UX issue! The approach of coordinating progress tracking across import/export phases is solid, and the new DiskChannelResourceExportManager is a clean design. CI is fully green and the new tests cover the key scenarios well.

I have a few observations below — one suggestion about a behavioral difference from the original code, and a couple of minor items.

Summary of findings:

• 1 suggestion (upgrade DB path handling)
• 2 nitpicks (progress edge case, closure variable capture)

Let me know if you have questions on any of these!

[rtibblesbot]

suggestion: The previous code in transfer_channel() handled an upgrade path: it checked for a previously-downloaded channel DB at get_upgrade_content_database_file_path() and, if present, used COPY_METHOD from that file instead of re-downloading. It also cleaned up that upgrade file after import.

This new do_channel_database_import() always downloads/copies directly from the source without checking for an existing upgrade DB. This means if diff_stats had previously downloaded a new channel DB to the upgrade path (e.g. during a version comparison workflow), the new code will:

1. Re-download/copy the DB instead of using the cached version
2. Leave the upgrade file on disk (never cleaned up)

This may be acceptable since the remoteimport/diskimport tasks are the "combined" workflow and the standalone remotechannelimport/diskchannelimport tasks still use transfer_channel(). But it's worth confirming this is intentional — especially on resource-constrained devices where re-downloading could be costly.

[rtibblesbot]

nitpick: The 10000x multiplier comment is well-reasoned — overestimating so progress "speeds up" rather than going backwards is a good UX trade-off. However, this multiplier will cause the initial progress during the channel DB download phase to appear nearly frozen (the DB phase represents only 1/10001 of the estimated total). For a large channel DB download that takes significant time, the progress bar may sit at ~0% for a while before jumping when the actual content size is resolved.

Not necessarily something to change, but worth noting in case testers observe this behavior.

[rtibblesbot]

nitpick: When manifest_only=True and export_channel_database=False (as in exportcontent --manifest-only), total_bytes will be 0 since channel_db_size=0. This means start_progress(total=0) is called. The original code didn't explicitly call start_progress in this case.

This is unlikely to cause issues since the manifest-only path completes quickly, but it's a minor behavioral difference from the original code.