One of the parts fails to download in entirety, but it is still reported as downloaded sucessfully.

[DingoPD]

I've been noticing this happening more and more often. One of the parts just fails to download but it still reports as downloaded, and the resulting file is corrupted:

[Part 14] Successfully downloaded 109.12 MB in 0:10:22 (speed 179.62 KB/s)
[Part 15] Successfully downloaded 109.12 MB in 0:10:21 (speed 179.92 KB/s)
[Part 16] Successfully downloaded 109.12 MB in 0:10:22 (speed 179.59 KB/s)
[Part 17] Successfully downloaded 109.12 MB in 0:10:22 (speed 179.59 KB/s)
[Part 18] Successfully downloaded 109.12 MB in 0:10:22 (speed 179.6 KB/s)
[Part 19] Successfully downloaded 38.32 MB in 0:03:38 (speed 180.22 KB/s) <---
[Part 20] Successfully downloaded 109.12 MB in 0:10:22 (speed 179.59 KB/s)
[Part 21] Successfully downloaded 109.12 MB in 0:10:22 (speed 179.62 KB/s)
[Part 22] Successfully downloaded 109.12 MB in 0:10:22 (speed 179.71 KB/s)
[Part 23] Successfully downloaded 109.12 MB in 0:10:21 (speed 179.85 KB/s)
[Part 24] Successfully downloaded 109.12 MB in 0:10:23 (speed 179.46 KB/s)
[Part 25] Successfully downloaded 109.12 MB in 0:10:22 (speed 179.54 KB/s)
[Part 26] Successfully downloaded 109.12 MB in 0:10:22 (speed 179.52 KB/s)

Deleting all relevant data and restarting the download does not help, it just fails in exactly the same spot.
Setting number of parts to less than the damaged part, makes it fail in another spot (setting this download to 18 parts will make it fail around part 10)

the download to reproduce the issue: https://uloz.to/file/ug2IbKt8kVqY/

[SpiReCZ]

I wondered if someone had the same issue recently... This seems like something that will need some additional work on the downloader.

[Vojtak42]

This might be the same issue as has VŽUM in last days. But VŽUM does not even start to download.

[zbyna]

I have not encountered such issues yet. Is it possible to verify that above-mentioned video file is possible to play in case of not using ulozto-downloader for download ?

[DingoPD]

I have not encountered such issues yet. Is it possible to verify that above-mentioned video file is possible to play in case of not using ulozto-downloader for download ?

Downloading the same file via the website works, no problems at all, it just takes an eternity and half :).

I clean up all downloaded video files with mkvmerge script that strips any extraneous information - attachments, extra foreign languages/subtitles, fonts, that kind of thing, before ever opening them. Files that failed to download all the chunks fully with the downloader generate lot of track errors when (mkv)merging, the same file downloaded via browser will parse (and play) just fine.

I have thought of the possibility that the problem might be an attempt by the uloz.to devs to curb use of the downloader ... maybe i'm just paranoid.

[zbyna]

@DingoPD If you downloaded this file, please check the integrity with some tool mentioned here: https://technastic.com/check-md5-checksum-hash/
and if you encounter simillar issues with another files post here with integrity hashes to clarify this problem.

[DingoPD]

@zbyna md5sum of the file i mentioned in my original post 8cb2ad21a1af1876f5ac93a6e471972f, though i don't really have anything to compare it to.

Will do, thank you for looking into this.

[czAdamV]

I ran into a similar issue. I'm not sure what caused the partial download, it could be some random connection issues as the internet is really unstable where I am, but the result is the same: some parts download only partially. If I stop the program mid-download and start it again, it resumes the affected part just fine, but this doesn't work after the other parts finish because the .udown file is already deleted.

[zbyna]

@DingoPD MD5 sum of the file downloaded with ulozto-downloader without issue with corrupted part: 8cb2ad21a1af1876f5ac93a6e471972f, it is possible to play it well. Seems like hashes are the same.

[jko-nic]

This problem still persist on newest version 3.1.0, with python 3.9.14. I have tested it on multiple networks (wired and wireless), so this can be rather problem of downloader itself, because file's hash differ every time i try downloading it.

Could be possible to maybe add some checks, if downloaded part has the correct size, and if not, delete this part and try downloading it again?
Edit: This problem appears in about 10% of downloaded files, not everytime.

[Vojtak42]

I don't have this problem on python 3.9.13

[MartinLojda]

Same problem here, Python 3.9.2 (Debian Linux).

[SpiReCZ]

Something like this happens sometimes with my ulozto-streamer. Some file part download does not start or is disconnected. The other parts are downloaded fine. If i restart the download the remaining parts get downloaded and file seems to be okay. (I have not tried to create a hash from the file, but i have not seen video artefacts, extraction or other issues).