Minimize disk usage by uploading files as they get downloaded in qbleech

[cleanerspam]

Feature Request: Implement a streaming mode for qbleech to minimize disk usage

Is your feature request related to a problem? Please describe.
When using the qbleech command to download and send files to Telegram, the bot currently downloads all files before uploading. On small VPS instances , this quickly fills up the disk.

---

Describe the solution you'd like
Add a "streaming mode" that processes one file at a time sequentially:

• Prioritize the first file in the torrent and begin downloading it.
• Once the file finishes downloading:
  • Upload it immediately to Telegram.
  • Delete the file from the VPS.
  • Mark the file as "do-not-redownload" in qBittorrent so it isn’t fetched again.
• Move to the next file in sequence , increase its priority and repeat until all files have been uploaded.

This way, at most one file is present on disk at any given time, greatly reducing storage usage. Also it increases efficiency by doing parallel download and upload reducing waiting time if network is not congested

---

Describe alternatives you’ve considered
Implementing an auto-adjusting download process, such as:

• Pausing the download when the disk is almost full.
• Uploading already-downloaded data to Telegram.
• Unmarking uploaded files in qBittorrent so they can be cleaned up.
• Resuming the download after freeing up space.

While this could work, a sequential streaming mode would be simpler and more robust.

---

Additional context
This feature would help those of us running WzML/qbleech on low-storage servers or small-disk VPS instances, allowing large torrents to be leeched without worrying about disk capacity.

Key considerations:

• If uploading is faster than downloading, files are uploaded and cleaned up immediately — minimal disk usage.
• If downloading is faster than uploading, a backlog of files could accumulate.
• To prevent running out of space:
  • Pause new downloads when available disk drops below a critical threshold (e.g. 2 GB).
  • Upload and delete already-downloaded files.
  • Mark uploaded files as completed in qBittorrent so they aren’t redownloaded.
  • Resume downloading once enough space is freed.

[SilentDemonSD]

Interesting.., we actually need a dynamic System of simultaneous DL/UP, everything can be done.. but what about progress !? Either need dual progress or silent progress !

[cleanerspam]

Revised Approach for Progress Tracking

Persistent Log Per Torrent

• Once the bot finishes downloading the torrent's metadata from qBittorrent:
  • Create a log file named after the torrent hash (e.g. log/<torrent_hash>.json).
  • Populate it with:
    • A list of all file names in the torrent.
    • Columns for:
      • downloaded (yes/no)
      • uploaded (yes/no)
      • file_size (in bytes)

This log file stays even if files are deleted from disk.

---

Updating Progress

During Download:

• Continuously update the log file with the progress of each file.
• Prioritize sequential order:
  • Give the top-most file the highest priority.
  • Begin downloading the next file simultaneously at lower priority for pre-fetching.
• Mark as downloaded = true once file download is complete.

During Upload:

• Update the log file's uploaded column after each file is sent and deleted.

---

Progress Calculation

Total Download Progress (%)

 sum(file\_sizes of completed files + partial progress of downloading files)

 sum(file\_sizes of all files in torrent)

Total Upload Progress (%)

sum(file\_sizes of uploaded files + partial progress of current file)

sum(file\_sizes of all files in torrent)

Remaining Time (ETA)

Estimate:

• download_eta = remaining_bytes_to_download / avg_download_speed
• upload_eta = remaining_bytes_to_upload / avg_upload_speed
• Final ETA ≈ max(download_eta, upload_eta)

---

Example

Imagine a 12-file torrent (total size 22 GB) with two files downloading concurrently:

• Highest-priority file (video4.mp4)
• Pre-fetch file (video5.mp4)

File	Size	Download Progress	Downloaded	Uploaded
video1.mp4	1.5 GB	100%	yes	yes
video2.mp4	1.2 GB	100%	yes	yes
video3.mp4	2.0 GB	100%	yes	yes
video4.mp4	1.7 GB	35% (high-priority)	no	no
video5.mp4	2.2 GB	12% (low-priority)	no	no
video6.mp4	queued	no	no	no
…	…	…	…	…
video12.mp4	queued	no	no	no

Totals so far:

• Total size: 22 GB
• Download progress: 8.8 GB / 22 GB ≈ 40%
  (includes partial progress of video4.mp4 and video5.mp4)
• Upload progress: 4.7 GB / 22 GB ≈ 21%
• Remaining to download: 13.2 GB
• Remaining to upload: 17.3 GB
• Estimated time left: based on average speeds.

---

Benefits

• Persistent log allows bot to resume cleanly after restart.
• Concurrent pre-fetching keeps download process smooth without filling up disk.
• Progress updates can be displayed like:

Download: 40% (8.8/22 GB) — ETA 35 mins
Upload:   21% (4.7/22 GB) — ETA 1 hr 10 mins

This design supports sequential order with minimal disk usage and optional parallelism for efficiency.
Or you can make it simpler by just showing number of files uploaded and number of remaining , because in the end for leeching what matters is that you got the file uploaded or not

---

[cleanerspam]

Please prioritize this @SilentDemonSD , it will save so much money of hosting on high storage capacity servers