by Vika » 02 Oct 2026, 22:36
ra_trong_em wrote: 25 Sep 2026, 00:22
Epub, mobi, cbz, cbr,... are compressed files basically. I use ftp to upload, everything went smoothly for a long time. I suddenly wonder why some files don't have cover picture, even though they are in the same series. I pick at random, 1 corrupt in page 5, 2 others in page 15. 2 of those 3 even got approved. I still haven't clicked through all 60 pages for 3000 uploaded ones, Those same files on my PC are intact and readable.
Its not just corruption of the files. There was a thing recently (and I've seen it before) where FTP failed to populate the database with the book's metadata. 70%+ failure rate. File itself was fine, just had to painstakingly put that metadata back.
This is why its worth it to use meaningful-to-uploader file names, so you can tell which book was which in case that happens. My latest collection populated at 100%, so I'm hoping that bug is squashed for now - but I expect another of its family to come back.
Corruption is a major issue yea, I tend to hover around the books I've restored like a mother hen till someone else moderates it so I can check its all there, for that reason. Slows the whole process down, but is a very necessary step. Even redownloading from FTP back to your pc to check it doesn't stop it corrupting later in the publication process.
Libgen+ will outright say uploaded file is corrupt or wrong extension. I know there's community feedback for bad file but it takes ages and if found, not sure if the uploader still have the data to repair. Corrupt file and normal file definitely differ in MD5 or SHA so this is automatable.
Uploader can't repair the file once it's up; only upload another and request the first be deleted.
This is why on web-FTP you have the option to delete your upload before you click publish, and the permissions to delete your uploads in the FTP client. Gives you a chance to make sure its all there, before you submit.
There is community feedback, but some of the moderators are moderating in bad faith. We're slowly identifying them, but it tends to be a persistent problem among those who see 'moderation' gives you points, and so try to moderate as fast as possible (read: don't look at or change anything) for points.
What are you comparing against to tell if the file was corrupted or not? Even comparing to original upload is only semi-helpful if the file was already corrupt. Thinking here of one particiular uploader and 120,000 files back in August, that particular example was easy clean-up. They aren't always, as a lot of uploaders don't check their file opens before they upload.
P/s 2: I even found some corrupt pdfs.
They're left over from a period of a couple of days about ~eight? months ago where upload was corrupting everything. It was fixed quickly, but that was still time for tens of thousands of files to be uploaded, due to a bad timing coincidence when the bulk uploaders did their business.
Most are easily identifiable as they have the same string in author name as they do title, and no cover. They're slowly being manually moved to the deletion pile.
[quote=ra_trong_em post_id=851 time=1790295756 user_id=4394]
Epub, mobi, cbz, cbr,... are compressed files basically. I use ftp to upload, everything went smoothly for a long time. I suddenly wonder why some files don't have cover picture, even though they are in the same series. I pick at random, 1 corrupt in page 5, 2 others in page 15. 2 of those 3 even got approved. I still haven't clicked through all 60 pages for 3000 uploaded ones, Those same files on my PC are intact and readable.
[/quote]
Its not just corruption of the files. There was a thing recently (and I've seen it before) where FTP failed to populate the database with the book's metadata. 70%+ failure rate. File itself was fine, just had to painstakingly put that metadata back.
This is why its worth it to use meaningful-to-uploader file names, so you can tell which book was which in case that happens. My latest collection populated at 100%, so I'm hoping that bug is squashed for now - but I expect another of its family to come back.
Corruption is a major issue yea, I tend to hover around the books I've restored like a mother hen till someone else moderates it so I can check its all there, for that reason. Slows the whole process down, but is a very necessary step. Even redownloading from FTP back to your pc to check it doesn't stop it corrupting later in the publication process.
[quote]Libgen+ will outright say uploaded file is corrupt or wrong extension. I know there's community feedback for bad file but it takes ages and if found, not sure if the uploader still have the data to repair. Corrupt file and normal file definitely differ in MD5 or SHA so this is automatable.[/quote]
Uploader can't repair the file once it's up; only upload another and request the first be deleted.
This is why on web-FTP you have the option to delete your upload before you click publish, and the permissions to delete your uploads in the FTP client. Gives you a chance to make sure its all there, before you submit.
There is community feedback, but some of the moderators are moderating in bad faith. We're slowly identifying them, but it tends to be a persistent problem among those who see 'moderation' gives you points, and so try to moderate as fast as possible (read: don't look at or change anything) for points.
What are you comparing against to tell if the file was corrupted or not? Even comparing to original upload is only semi-helpful if the file was already corrupt. Thinking here of one particiular uploader and 120,000 files back in August, that particular example was easy clean-up. They aren't always, as a lot of uploaders don't check their file opens before they upload.
[quote]
P/s 2: I even found some corrupt pdfs.
[/quote]
They're left over from a period of a couple of days about ~eight? months ago where upload was corrupting everything. It was fixed quickly, but that was still time for tens of thousands of files to be uploaded, due to a bad timing coincidence when the bulk uploaders did their business.
Most are easily identifiable as they have the same string in author name as they do title, and no cover. They're slowly being manually moved to the deletion pile.