I am Evelyn from Adfinity reached out with an offer to boost website revenue using non-intrusive ads (download button and pop-under) that integrate seamlessly. They promise competitive average CPM rates ($20-$60/day), flexible daily, weekly or monthly payouts, 24/7 support, global traffic monetization, and a live stats dashboard. You should check one of our client example (Getintoway.com). We provided multiple contact options to discuss a potential partnership.
For Anime Tosho, the 75-item RSS feed limit may work with reasonable Delay Profiles, but other indexers with more releases can lose the best release before the delay ends. This is why *arr apps cache links, and their maintainers likely won’t change this.
If renaming or deleting NZBs isn’t viable, please consider blocking downloads of deleted release NZBs for clients with Sonarr, Radarr, Prowlarr, or NZBHydra2 user agents.
The cache is required because new releases can flood the RSS feed during the delay, potentially pushing the best release out of the feed’s size limit before the delay ends.
Thanks for the explanation! I don't quite get it though - if it's checking for "better" versions, it needs to make another query. And if it's making another query, it'll know if something has been deleted. So I don't understand why it needs to cache anything.
The NZBs are keyed by ID, so can't really be renamed easily. It's a possibility, though I don't look too fondly over such a change.
Sonarr and Radarr have "Delay Profiles." This feature makes them wait for a set time (e.g., 60 minutes) after finding a matching release before starting the download. The idea is to allow time for potentially better quality versions to be uploaded. During this period, download links to suitable releases are cached.
Invalidating the original download URL upon deletion (perhaps by renaming the target file like some-release.nzb.gz to some-release.nzb.gz.deleted) is an equally effective solution without requiring the removal of the NZB files.
I don't use those applications, so don't really understand the issue. I would've thought that the application makes queries for the latest stuff, then downloads them. So what's being cached? Old search results? If so, why are those cached?
I don't really want to remove the NZB files, as they're still valid uploads.
I don't really get what you're trying to say, but you can restrict a search to entries tagged for a particular series if you tick the option whilst browsing that series.
Could you please look into removing the NZB files for deleted releases? It seems they currently remain active, which can cause *arr users with cached entries to unintentionally download them.
I noticed something when I looked up group releases for a single show (**Example) If the search peformed, is made from a show, the search returns, only what a group has released for without needing to add a shows name to the search. Whether it was fluke and I stumbled onto it or the search parameter has recently been added. Its an excellent and efficient way to save time searching. However, something weird also happened. After the focused search was made. A check box for making the same focused query, appeared under the search box(left side of screen). Never a dull moment on AT
(**ex: Anime Tosho Home » Star Blazers Space Battleship Yamato 3199 » [Group name] )
There you stated irefresh-type 1 was used, but seek time is very fast, how could you achive that?
Mine open GOP act like so: start video(~24m) and switch to middle(~12m), it requires ~30s to vlc/mpv to truly change the scene But yours behaves like closed GOP, what the secret, magician?
Also pls provide svt-psy vesrion, because i cannot recreate image quality used this as a source: https://nyaa.land/view/1876552 (av1an 0.4.4-unstable, SVT-AV1-PSY v2.3.0-B-0+17-b834bf13)
There's no stated rate limit. I request that clients be "reasonable" with the number and rate of requests sent. For "reasonable", consider the page browsing activity of an average user.
Hopefully that helps.
(I don't manage or check the Discord server, so you probably won't get responses for these sorts of questions there)
I opened a ticket on discord for this as well, but that didn't receive a response so I'm trying here too :D What's the current rate limiting with regards to API queries? I'd like to implement the limit client-side to avoid requests being blocked.
I see, thanks. I realize it's not that hard to code, although I suppose it's somewhat more work than just slapping some remote embed on your page, and can get more involved when you also need to manage users or implement moderation (depending on how much spam they get). I think many do just slap together some wordpress comments or something of that sort, but then you also need to keep watching for vulnerabilities in those large packages (which happen quite often), so it's still not that hands off either.
Unfortunately the code isn't open source, and it's not really its own component either, meaning that others wouldn't be able to utilise it even if they had the code. The system here is really quite simple and bare bones, so I can't imagine it to be difficult to implement by someone knowledgeable enough.
I suspect the appeal of Disqus is that it does everything with minimal setup, from user registration/management to comment storage and database maintenance, without the website admins needing to care about any of that. So depending on how much effort the admins want to put in, a self managed open source comment system may not be what they're after.
Thanks for your concerns. Sorry if I implied that your searches are having a significant performance impact - it's not really what I meant. Terms like 'a*' showed up as queries taking the most time, indicating that it potentially could be something I'd want to restrict in the future. Whilst the searches are relatively expensive, there isn't too many of them. (also part of the problem is the search server not using the correct index)
?aid=18576&qx=1&q=("1080p")|(NOT("720p"|"480p"|"360p")) does not return any 2160p entries, however
When positive terms are specified, they must be present in the results. So if your 2160p entries don't contain "1080p", they won't show up.
For negative terms, they must be absent in the results. So if !(*720*) is specified, the following examples will not appear in the results: - [Group] Title - 05 (Web 1080p) [A1E720F8].mkv - Title.S01E720.1080p-Group.mkv
i kinda want to use it because some shows are tagged as 1920x1080 or even 1920x1080p which is awful, so *1080* does x1080 x1080p and 1080p
You can just specify all those cases, e.g. (*x1080|*x1080p|1080p).
admin, is this minimal no-javascript comment system open source or available in some form? Asking because recently some anime releasing sites (and not only) recently lost their cloud comment sections (banned for piracy by disqus), and I'm sure some of them are in need of something simple, easy, fast and secure. I'm aware of many implementations of such things, but they're always really large and consume a lot of resources and tend to get some 0day every few months.
yeah, I'm fairly sure something is wrong ?aid=18576&qx=1&q=("1080p")|(NOT("720p"|"480p"|"360p")) does not return any 2160p entries, however ?aid=18576&qx=1&q=!("720p"|"480p"|"360p") returns 2160p entries, this is woeful
sorry for the spam, but i'm actually at my wits end trying to get this working, while making sure i dont tank your servers with my users, i didnt expect my app to actually impact you this much :/
hm, actually this isnt correct, I think I'd be looking for ?eid=293094&qx=1&q="1080p"|-("720p"|"540p"|"480p") but i cannot get this to work correctly....
tell me if you'd prefer if that wasn't the query used, i kinda want to use it because some shows are tagged as 1920x1080 or even 1920x1080p which is awful, so *1080* does x1080 x1080p and 1080p
just was wondering if there was a way to get results for specific torrent/file quality, i.e search for only 1080p torrents, etc. thanks for clarifying admin.
Unfortunately I don't have any suggestions - it's likely not what you want to hear, but pure exclusion filtering is just hard. If you don't expect to exclude much, filtering client side might be a solution.
You should now be able to use negative-only terms in searches when an aid/eid is supplied. Hopefully that works out for you.
14/04/2025 13:17 — Anonymous