Over the years we have tried many things and I can't say that we found anything that noticeably extended the life of links for targeted shows. Last season the only thing that worked more or less reliably was for users to plan for less than a 48 hour window to download their favorite shows from their favorite ddl-service. I think it is unreasonable to expect links to last long anymore no matter what we do, if a show has been targeted.
It's also true that last season the targeted shows were quickly removed from certain ddl-services but remained available at other ddl-services. I don't know if those other sites ignored take-down requests or were just not contacted. I don't want to mention names because I've seen discussions in our Feedback that resulted in changes elsewhere.
I'll be collecting info for this season to see if anything has changed. I already see they have expanded the ddl-services at AT which are targeted and/or compliant. They will probably also look for quicker ways to enforce. It also looks like dub has become more of prime target.
The general answer will probably continue to be for users to plan for downloads of their favorite shows as soon as they are available, and flexibility in which ddls and "brands" of shows they use when necessary.
i wont be surprised if crapimation is behind all those links going down fast. quite a few crapimation licensed shows dont last even a week after being uploaded.
Reply to FAQ: Why so many dead links? (for a recent file)
You are probably aware of this, and it's not possible to implement (resources). Nevertheless I thought I'd mention it, just to make sure.
Over the years I have noticed .rar/.zip/.7z files often stay up longer. Especially when the filename is unrelated to the content. I may stumble into an old thread in a forum (several years old), all the links to .avi/.mp4/.mkv are dead. But that one link to a "22392873.rar" file is still working. Obviously not always, but I've seen it quite a few times. Likely depends on policies of the host. If processing power was available to create archives (uncompressed) of each episode. An automated script could assign each show a specific number + number for release (+ number for file, if multiple). And upload it like that.
Recently uploads have been going down very fast. In the past you could still find working links for files uploaded 1-2 years ago. Now links from Jan./Feb. are already down. It might be worth it, to do an experiment (manually?), just renaming files. Maybe that would already help a bit. Since files go down quickly, the results would be available fairly soon.
Once links are dead, it's over. So the hassle of having to rename files back after dl, is worth it (imo). But of course, if someone is taking the files down by following their links from AT. Nothing will help, I guess?
it would be nice, if the header/info for a "series" would contain links to related "series" on AT. this would help explore/search and get it all quicker. also, it would be more convenient. if the main MAL link of the "series" in question, was always accessible via the letters "MAL". even when there are multiple links (which is great).
for the same purpose as above, it would be great (to have an option) to search for "series" instead of releases. it would deliver cleaner results. a more direct way to find the "series", and then the release you are looking for.
since some releases seem to end up unsorted. it would then be necessary to also offer a search within unsorted files only.
------------------- otherwise I believe AT is pretty much as good as it can get, which quite frankly is pretty damn awesome. thank you.
ClickNUpload's uploads are done by posting <80MB chunks. Unfortunately, their upload handler doesn't give a reliable way of knowing whether a chunk was uploaded successfully (I've only got the HTTP response code to rely on). To put it another way, the script doesn't have any way of easily knowing whether the file was fully received by ClickNUpload - it can only guess. This means that if there's a failure, the file could be missing a chunk or more. The example you gave follows this pattern.
ClickNUpload doesn't seem to have an API to query received sizes with, or a documented way of sending uploads. This makes it hard to solve this problem here unfortunately. Usually the script tries to detect faults and retry, but there's no reliable way to do it with ClickNUpload.
Note that I consider AT to be in two main parts: file processing (downloads/uploads) and the website (what's shown to users). I run these on separate servers, and I'll assume you'll do the same; you can run everything on the same server (may be handy for testing/development), but I'd advise splitting up the website and processing components unless you want the complexity of managing QoS and the like.
I generally wouldn't recommend doing anything off a home connection. File processing may be feasible, but you've indicated that you couldn't do the volume with that. For testing/development, you could always just run with a smaller sample. I strongly would discourage running a website off a home connection, though, like above, you could use it for testing/development purposes.
This means that you'll need to rent one or more servers. What you get exactly will depend on many factors, which you'll have to work out. Bandwidth will likely be a concern for mass uploading so you'll need to ensure that there's enough, though if you've only got one target (usenet), it won't matter as much. I/O (disk speed) might also be a concern, if you're like me and stick with cheap single disk servers. For the website server, you'll probably need to experiment with what works for you, depending on how you manage/develop it. I generally wouldn't go with anything less than an SSD (referring to disk speed that is), though you could do fine with a HDD if you have sufficient RAM.
My opinion on tech stacks is that they really don't matter. Use whatever you're comfortable with, unless you actually want to learn something new (which is also fine, but it'll be more effort on your part).
I'm guessing you don't have much experience with running websites yourself? This definitely isn't the simplest thing to start off with, but if you do continue, there's a lot to learn from it. One piece of advice I'd give you is to think beyond the technical side of things. Newbie programmers like to think that's the only thing that matters, but you should consider aspects like your goals, funding, whether or not you'll still be running it in 10 years time, etc.
I noticed that, and on AnonFiles the file sizes were larger than they were supposed to be. When I tried a force recheck on the ClickNUpload files with torrent to finish them off it would go to 23% or 77% and then drop to 0% after a few seconds and start over. Other torrents working fine so the file must be corrupted.
i think its more a case of failed uploads than CNU altering it. before there used to be like 3 uploads to CNU - one from animetosho, one from MultiUp and one from Jheberg so if even one of those uploads were broken, you still had two other CNU links to get from. now it's just one, if that is a failed upload then i go to DropAPK but it's so slow :( i have also seen some CNU files being way over the actual size.
It seems ClickNUpload alter the files in some cases. I hadn't encountered this problem before on other sites and when I upload files to iClickNUpload myself. Also AnonFiles is OK. It just shows the size of files wrongly.
Basically tech stack advice. Uploading to usenet isn't a technical problem but I couldn't do that volume from my home connection. Advice for that? Thanks to my day job I can do basic sites with python but I assume that's not optimal. Advice on what to learn?
Unfortunately, the naming scheme confuses the classifier and they don't even consider it to be One Piece, so One Pace releases will get mapped to random series, based on what appears to be in the title. I basically throw my hands up in the air with those...
These are all One Piece releases (fan re-edits to remove filler and make them closer to manga pacing), but they get tossed in random series EXCEPT One Piece. :D
Thanks for pointing that out. Unfortunately, it looks to be the same issue with another YakuboEncodes' release, which is being rejected due to slashes in the name. It might be best if they could fix their torrents not to do that, as it appears a number of torrent clients don't handle it well.
Seems to be working now, though there was a period where all uploads were failing (appears to be gateway errors on their side). Generally if uploads fail, they are queued to be retried, which means that links can take a while to appear if the host is having issues.
11/04/2020 22:22 — Anonymous