cyberdrop-dl - cyberdrop.me Downloader written in Rust 🦀

Downloading starts off real smooth, and about half of the images in the album is downloaded. However the speed of the download significantly decreases, almost to nil. Additionally, this error appears periodically:

If the problem is on my side, help would be very much appreciated. In any case, I really like this downloader as opposed to the other ones available. TYIA!

I have never touched rust so maybe you could identify the issue.

I was trying to make an actions workflow to automatically generate builds for linux, windows, and mac to make it easier for people to get the tool up and running. I was able to confirm that the generated windows build works but the linux build, and probably the mac build too, throws an error about tokio:

user@lxc /tmp/releasetmp # RUST_BACKTRACE=1 ./cyberdrop-dl https://cyberdrop.me/a/1
Albums to download: 1
     Overall [░░░░░░░░░░░░░░░░░░░░ 0/1]
thread 'tokio-runtime-worker' panicked at 'Error creating dir: Not a directory (os error 20)', /project/src/lib.rs:188:29
stack backtrace:
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
thread 'tokio-runtime-worker' panicked at 'called `Result::unwrap()` on an `Err` value: JoinError::Panic(...)', /project/src/lib.rs:65:17
stack backtrace:
Done!

The /project/.... is from the github actions server, it kept that structure for some reason.

You can find the builds here https://github.com/cyberdrop-me/cyberdrop-dl/releases/tag/v0.3.1 and here's the workflow file https://github.com/cyberdrop-me/cyberdrop-dl/blob/main/.github/workflows/release.yml

I had to add a package to the Cargo.toml here https://github.com/cyberdrop-me/cyberdrop-dl/blob/main/Cargo.toml#L25 because the mac & linux build kept complaining about this error https://github.com/sfackler/rust-openssl/issues/1021

Hey!

There are two instances of the following line in the code:

let _ = sem_clone.acquire().await.unwrap();

This will acquire the semaphore permit and immediately drop it, as let _ does not actually bind the value (it's ignored). This means that may be more concurrent downloads happening than planned.

A quick fix would be let _permit = sem_clone.acquire().await.unwrap();, then it'd be dropped at the end of the scope. Note that you may need to increment the batch size to keep the current download speed.

Also, I personally find it better to name ignored variables, such as let _result = download_album [..] (line 61) and let _count = io::copy [...] (line 127), making it easier (when reading) to know what's being ignored.

References on _ not binding:

The Rust Programming Language: Ignoring an Entire Value with _ https://github.com/rust-lang/rust/issues/40096

$ cyberdrop-dl Traceback (most recent call last): File "/data/data/com.termux/files/usr/bin/cyberdrop-dl", line 5, in from cyberdrop_dl.main import main File "/data/data/com.termux/files/usr/lib/python3.11/site-packages/cyberdrop_dl/main.py", line 19, in from cyberdrop_dl.client.downloaders import get_downloaders File "/data/data/com.termux/files/usr/lib/python3.11/site-packages/cyberdrop_dl/client/downloaders.py", line 10, in import aiofiles.os File "/data/data/com.termux/files/usr/lib/python3.11/site-packages/aiofiles/os.py", line 31, in link = wrap(os.link) ^^^^^^^ AttributeError: module 'os' has no attribute 'link'. Did you mean: 'unlink'?

how to fix this issue? i was already install the requirements on python also didnt work

Actions workflow to build & upload binaries for Linux, Windows, and Mac whenever you create a new GitHub release.

For them most part the builds should work for almost everyone. Still have no clue if the mac build actually works but I assume so.

Tested on:

Windows 10
Fedora 35, 34, 33, 32
Ubuntu LTS 21, 20, 18, 16
Debian 11, 10
CentOS 8
openSUSE 15.3
Arch Linux 2021.09.01

the error is longer than this, but this is the first line code of the error, thread 'tokio-runtime-worker' panicked at 'called Result::unwrap() on an Err

Im trying to download an album but its stopping and throwing out errors. I assume its the file name being too long?

thread 'tokio-runtime-worker' panicked at 'called Result::unwrap() on an Err value: Os { code: 63, kind: FilenameTooLong, message: "File name too long" }', /Users/chrisgray/.cargo/registry/src/github.com-1ecc6299db9ec823/cyberdrop-dl-0.3.2/src/lib.rs:126:62 note: run with RUST_BACKTRACE=1 environment variable to display a backtrace thread 'tokio-runtime-worker' panicked at 'called Result::unwrap() on an Err Overall [░░░░░░░░░░░░░░░░░░░░ 0/1] thread 'tokio-runtime-worker' panicked at 'called Result::unwrap() on an Err value: JoinError::Panic(...)', /Users/chrisgray/.cargo/registry/src/github.com