Artifacts being introduced randomly in files grabbed by RDT-client
What version are you using? 2.0.58 Wat OS are you running? Unraid OS 6.12.6 Are you using Docker or as a service? Yes Which debrid provider are you using? Real Debrid Which downloader are you using? Internal downloader Please attach a log file here with the log setting set to debug
I’ve noticed a ton of artifacts popping up lately when there used to never be any (using qbittorrent). Almost every movie or show. I can download an mkv, notice there are artifacts, then delete that file and get the same EXACT one and it will be fine or have artifacts in spots the other file did not. Anyone know what might be going on? It’s literally the same file imported the same way by sonarr or radarr. Tested multiple times on multiple devices.
Unraid OS Docker Version 2.0.58
I am seeing the same thing as OP. To test I have downloaded the same file using qbit and the file was fine. I have notice this happening since the last problem with not downloading #391. Files seems to download a lot slower than before as well but will download now. I also have tried to adjust the "Parallel connections per download = 4-6" and "Chunk Count = 0-4" with no luck.
Unraid OS Docker Version 2.0.58
I am seeing the same thing as OP. To test I have downloaded the same file using qbit and the file was fine. I have notice this happening since the last problem with not downloading #391. Files seems to download a lot slower than before as well but will download now. I also have tried to adjust the "Parallel connections per download = 4-6" and "Chunk Count = 0-4" with no luck.
Thank you for validating what i’ve been seeing. I asked on reddit and just got downvoted lol. It’s really frustrating.
All videos that i have downloaded using rdt-client have random artefacts throughout the video. I have downloaded many through rdt-client, and I have yet to see a video without artefacts. They are uncommon (maybe 10 per video for 1-2 seconds each) but very noticeable when they occur. Attached an example of an artefact.
I'm also seeing the same artifacts in downloaded videos. Might be something wrong with the unpacking process?
I wonder if it's something with the unpacking process, maybe a new version of that package broke something as I see other reports too about unpacking. Could you try taking a CRC of the file you downloaded manually and 1 that comes through RDT? And see if the are different?
Also, those torrents were the zipped in the first place?
I wonder if it's something with the unpacking process, maybe a new version of that package broke something as I see other reports too about unpacking. Could you try taking a CRC of the file you downloaded manually and 1 that comes through RDT? And see if the are different?
Also, those torrents were the zipped in the first place?
I'll try when I get some time, but honestly I'm not too well versed in this kind of stuff although it should be simple. I do not believe they were zipped...just simple .mkvs.
I wonder if it's something with the unpacking process, maybe a new version of that package broke something as I see other reports too about unpacking. Could you try taking a CRC of the file you downloaded manually and 1 that comes through RDT? And see if the are different?
Also, those torrents were the zipped in the first place?
Taking the example of the same torrent, which is unzipped:
CRC32 of file downloaded via qBit: 23DB4722
CRC64 of file downloaded via qBit: 95A1F35288906B46
CRC32 of file downloaded via rdt-client: 6B63A2EA
CRC64 of file downloaded via rdt-client: BCF9E58F3A6FE243
I'm guessing this is related to the unpacker because I do receive this error for torrents downloaded that are compressed:
Can you confirm the crc if you download directly from Real Debrid? Is it RDT or Real Debrid introducing these artifacts? I have noticed issues with things streaming directly from Real Debrid as well, wondering if it was this.
Can you confirm the crc if you download directly from Real Debrid? Is it RDT or Real Debrid introducing these artifacts? I have noticed issues with things streaming directly from Real Debrid as well, wondering if it was this.
CRC32 of same file downloaded direct from Real Debrid: 23DB4722
CRC64 of sane file downloaded direct from Real Debrid: 95A1F35288906B46
But to be clear, it only happens with torrents that are packed?
Unfortunately not, the file above was not packed. With packed torrents, I get the error in the application in the screenshot
Right ok, that makes sense in a way because the zip is corrupt too.
It's curious because I have seen an odd error of the same thing with the previous downloader too, but now switching to the other downloader I thought it would be more stable.
What is your Parallel connections per download and Chunk Count setting set to?
I deployed .59 in which I replaced the internal downloader once again with the one I write and seemed to work OK.
If you want to go back to the other downloader, I added it as an option called Bezzad downloader.
Experiment with the internal downloader and see if you're still getting this issue.
What is your Parallel connections per download and Chunk Count setting set to?
I had it set to default, so 4 parallel connections and 0 chunk count.
I deployed .59 in which I replaced the internal downloader once again with the one I write and seemed to work OK.
If you want to go back to the other downloader, I added it as an option called
Bezzaddownloader.Experiment with the internal downloader and see if you're still getting this issue.
I've tested and a packed download has worked on the legacy downloader, and CRCs now match with direct-downloaded files. Looks like we're good, will continue to check for artifacts.
Thanks @rogerfar!
I've bene super busy and haven't been ablate check in but I do believe you have fixed it. Thanks @rogerfar!
Btw, is there a recommended parallel and chunk count to use given I have a 1gb symmetrical connection?
Depends on how many downloads you do in parallel, but you can start with something like 8 and if you're experiencing slowdowns when writing to disk you can try to go higher.
So you’re suggesting 8 parallel connections per download? Any recommended chunk count? Truthfully I am unfamiliar with parallel connections per download (I’ve only heard of chunk count). For maximum parallel downloads…is that just preference? I don’t want to get into any trouble with Real Debrid. On Jan 23, 2024, at 12:11 PM, Roger Far @.***> wrote: Depends on how many downloads you do in parallel, but you can start with something like 8 and if you're experiencing slowdowns when writing to disk you can try to go higher.
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you commented.Message ID: @.***>
8 should be fine. The larger the files you can up that number a bit. I'm sure RD has some limits, but I can't find them right now.
If this is still an issue let me know.