iyear
[Feat] --skip-same should count skipped ones as completed.
Proposal
May i ask if you can make new overriding parameter such as '--count-skipped-as-downloaded' to mitigate such ineffectiveness? i think some people would be concerned about integrity in a strict manor as we cannot have file's hash but only filename and filesize from TG server.
Background
Hello. Recently i had very edge case which TG server corrupting one of the media that i archived on. it seems like their server sided video conversion has fucked up my original data, which causing loss of video length.
Because of this issue, File download request via TDL does not sends full data of its own unless it's downloaded by desktop client. for some reason TG server only tries to send "in-tact" data of that video, when requested via TDL.
After checking this incident i decided to manually remove corrupted index from TDL's message json file list, but this revealed as a bad idea because it reset unfinished download records. because of this, it started to compare file from the start, again.
The worst part of this is, when files are validated to be existing via '--skip-same' parameter is not getting saved. only fully downloaded ones are counted as "downloaded", which makes '--continue' super ineffective and getting stuck on FLOOD_WAIT with tons of times, getting repeated every single time when i tries to resume it.
Workarounds
There was no such workarounds of this, maybe reading entire source and manipulating .tdl\data\default file would work, but i didn't had time to achieve such things.
also, when --skip-same is used with --continue, if i manually cancels download progress with Ctrl+C it's progress doesn't seems to be get saved. even if i downloaded 1k+ items, those records are not getting saved and it counts from the first message from the json i exported with TDL. i am not sure if tdl is not saving Ctrl+C suspension's progress, or it's a bug that related with those two parameters.
also, when --skip-same is used with --continue, if i manually cancels download progress with Ctrl+C it's progress doesn't seems to be get saved. even if i downloaded 1k+ items, those records are not getting saved and it counts from the first message from the json i exported with TDL. i am not sure if tdl is not saving Ctrl+C suspension's progress, or it's a bug that related with those two parameters.
that is right man, i have meet same problem, seems tdl wont remember the progression
that cause slow starting of download when i have 4000 files to download, and have 1000 downloaded file (for example)
