Only half true. Admin could add target="_blank". But yeah, that's not needed. Depending on browser you can config it in settings or firefox f.e. about:config the browser.link.open_newwindow settings (esp. external). Or you could hold the STRG key. You could also use addons (even on specific sites only).
Would it be possible to set links like ddL's that go to another website, to open up in a new tab instead of opening in the same? It's more a convenience request than anything else. Normally we have right click for a context menu and choose "Open in New Tab" to get the link into a new tab.
I ultimately don't know how common this occurs, but it does automatically get rectified most of the time, but may take a while. There are retries in place, but it doesn't eliminate the issue. For example, if there's a 10% chance of failure, a single retry reduces this to 1% (assuming 0% correlation across requests, which isn't the case). I'm tweaking the strategy to lessen the likelihood of failures, but what you'll see are the residual cases where the automation didn't succeed.
For such a scheme to be useful there would have to be an initial success followed by failures, which would be a very limited thing here, I believe. Until a success, there would be nothing to re-check.
The last failed scrap I know of was [Pizza] Maison Ikkoku - 15 [BD 720p HEVC Opus]. After it was manually added it has remained here, as have all of the other 15 episodes over the last several weeks. I don't think there was an initial success of ep15 followed by failures.
Setting up a multi-sampling, multi-status new system at a busy place like this would require a very significant proof of need.
if we're talking about the yugen example, ep 1 had been here long enough that no one complained about not being able to find it. Three weeks later, and almost no one probably would still be looking to get it. Such a thing would not be worth much additional effort.
The initial scrape problem is more interesting, but appears usually self-correcting.
Not rly, you can check, c&u has has time as AT, while gofile has same time as nyaa. There was a good 2h delay. Still that probably had nothing to do with deletions but probably slow upload
I did get 404 every now and then too simply accessing the page. Maybe too overloaded then and/or a mehanism to slow requests down? Maybe it would be worth adding a mechanism to just mark as deleted but leave it still searchable, only if it got 2,3 repeated 404 remove it from common listing? Or - maybe on 404 do other files get those too? It probably depends on how you do request that. Hope note all at once but probably best in packages. Anyway (also on single requests) you could save results first, compare last idk 5? results and if all are 404 add delay, then retry.
Ok so how did you check? I mean did you watch the startpage or even enter the id manually on a link? Did it actually show deleted? Or did you only check Episode/Series/Search? Second case can also simply be a slow torrent upload or many files at once in which case you simply have to be patient.
Huh, yeah it seems the glitch as mentioned above may have happened again today with the same show, Nirvana's release of Hell's Paradise, but I can wait until it gets scraped later today.
Deleted items do get rechecked, but the interval is rather long. I don't know if they're actually deleted and reverted - I've seen Nyaa report entries to be deleted (or rather, 404) but don't appear to be, likely suggesting some glitch on their side, though this seems to mostly be for new entries (which is usually why some entries get missed here).
Ah ok. Out of interest: those periodic checks from AT - do they also check on deleted items (idk may limit few weeks after creation) on of they are actually not deleted and reverse that automaticallly? Or is it not worth the effort, dunno how often that does happen?
Yeah, I know about that one but I mean its also just another color only through a userstyle. The main idea behind was to not use the style selector always, which the above 2 lines (+ definitions like include https://animetosho.torrentbay.st* / run-at document-end) do allow.
For some reason, Nyaa sometimes reports files as deleted (404 page), but reverts it later - this was the case for this entry. I've gone and fixed it, thanks!
Hm, nothing at Userstyles.org, userstyles.world, greasyfork.org, nothing at github. I do have css but very little js knowledge but in the end I managed to get for violentmonkey: const opt = {value:"https://animetosho.torrentbay.st/inc/style_231.css", rel:"231"}; themeChange(opt)
I don't use RSS but I would doubt it. Entries marked as deleted are removed from AT's listings and searches. It's more a matter of if you know of a specific missing entry finding the reason, like it being in wrong category on Nyaa.
get a usenet provider like newshosting, eweka or frugalusenet (they are all paid, but you can split with other people), add it to sabnzbd (https://sabnzbd.org/downloads). Once that's done just drag & drop the file provided by AT or double click the unzipped .nzb
As suggested, usenet access requires a usenet provider, account and credit card. Look for providers with google. I would say paying in general isn't popular here, for several reasons.
Hm ... maybe anything from anydex that is a iso. This is probably good enough. The few uploads every few weeks I believe could be manually fetched if wanted. I mean you could go deeper and also consider from accounts that (didnt upload much, may also recent uploads size vs. total upload size, did upload that series before, check on a easy to manage list of words (series, group names and such), check on last online, yeah ... may there is still s.t. else to compare). But that's imo not worth any effort. Or if the download traffic doesnt mather, download it and check the iso's content before uploading it.
27/04/2023 06:55 — Aryma