for the extended search, is there any way to only exclude specific strings? say i want to find all torrents that aren't DTS, I tried enabling extended syntax and writing !("DTS"|"DTSHD") but it doesn't output anything but doing say !("DTS"|"DTSHD")ab outputs things????
I see. If it helps, you can try the BEP 48 scrape extension to reduce the number of requests sent. In the past, Nyaa was iffy about scrapes, but it generally seems to work these days.
ah right I could have just looked at when the torrent was released and base it off of that, my bad, thanks for the field tho
I'm using tosho in an app, so it's a lot of separate users that query it, not just 1 endpoint, so it can't really be cached, I also compile all torrents for a given episode, if I was to scrape say 40 torrents per episode Nyaa could end up banning my users which I'd like to avoid as much as possible, but as you said I am gonna scrape as much as possible myself, except the things I don't need to which is why i asked for the date
I've added it via tracker_updated, though it could be null if the data isn't sourced from a single tracker. I've probably said this before, but if tracker info is important to you, you shouldn't be using the data here, particularly if you're looking at older entries. I don't know what you're using the API for, but if you're primarily focused on items posted in the last week, the data here might be fine. But if you're often looking at stuff older than a month, you're probably going to need to scrape everything yourself (or find some other way) as the data here is almost guaranteed to be seriously out of date.
any chance the JSON api could return the "last scraped date" for the tracker it returns data from, so the end developer could scrape the peer info themsvels if its outdated?
Hi guys. There is a page that pretends to be you that has the same architecture. It literally copies everything. When searching AnimeTosho on Google, it always appears as the 1st search result. I hadn't entered for a long time and when I found this I didn't believe at first that it was false. I realized then when I see that the links to the servers are not the original ones, as if suddenly you now use ads. They take you to really dangerous pages with viruses and data theft. alert everyone This is the page: ***https://ideesg.com/***
Unfortunately we don't have any 'popularity' statistics here. Seed/leech count is also a bit tricky to implement (plus as you pointed out, it's inaccurate anyway), so I'd recommend using the original trackers if that's important.
Hey new user glad to see ya doin the lords work here. Just wanted to say it'd be nice to have some sorting options like popularity and seeds/leech(even if it is estimated it's still a rough idea) if possible. Not gonna complain too much though just saying it'd be really helpful imo!
I renamed all subtitle tracks so that they conform to the [name].[lang].[ext] convention, which hopefully makes it easier to import into MKVToolNix GUI.
Extraction is just a mkvextract [file] tracks ... command. It seems like Inviska's tool does basically the same thing.
It looks like MKVToolNix GUI does recognise a *.[lang-code].[ext] pattern in the filename to pick up the language, but I can't see the track title info being picked up. The language + title info is metadata from the MKV file itself, not part of the subtitle, so it doesn't make much sense for it to exist after extraction (unless some trick is being done with the filename, like the language code).
The language code here is delimited with a '_', which you could replace with a '.' to get MKVToolNix GUI to parse (e.g. rename 'track14_spa.srt' to 'track14.spa.srt'). Again, the title is lost, but I don't see any way to handle that. Does that more-or-less get what you're looking for?
I've got no idea what tool you're using to extract attachments right now, but with mkvmerge (inviska mkv extract on Windows), extracting subtitles keep their language tag. Your current method gets rid of them. I could bet ffmpeg can just as well keep the attachments metadata if the right setting was provided to it, but I have too little experience with it compared to mkvmerge.
Can attachments keep their language and title tags please? It is especially annoying to have a release with such big amount of subtitles (e.g https://animetosho.org/view/zigzag-bub....n1686112) and importing the subs into mkvtoolnix they lost all of their metadata and are all set to "unknown" language.
Feedback page is just perfect the way it is currently. Actually with reversing order, the comments here will look quite absurd. Please don't change anything, admin ;)
"RSS (Really Simple Syndication) is a web feed that allows users and applications to access updates to websites in a standardized, computer-readable format." AT has several types of such feeds.
is there a way to like get an email every time a new episode comes out? it doesn´t matter wich anime is it, i just wanna get notified when new anime chapters are available
Thanks for the suggestion. I can see the merit, though the feedback page has been like this for a long time, and isn't really meant to be a forum. It's meant to be the same as the comment section for each torrent (modeled after typical blog comments). You can view it in descending order though, through the view latest link - hopefully that's close enough to what you want.
Any chance you'd consider reversing the sort logic of the feedback page? I get sequential ascending makes sense for forums and the like, but for something like this you'd generally assume page one would be the newest; think forum thread logic, rather than forum post logic.
The API was mostly a hastily put together modification to the RSS feed. The feed is basically an alternative form of torrent listings here; on any listing here, there should be a feed icon in the top-right, which gives you the parameters to generate the listing (just replace /atom with /json).
The /api endpoint is for Newznab/Torznab clients, so is a limited implementation of the Newznab API.
There aren't that many accepted input parameters - basically enough to cover what the listings here show. Parameters like 'page' that you'll find in listings, but not listed in the feed URLs, also work, since the feed/API is just a listing with XML/JSON output instead of HTML. The only other thing I think is that 'aids' and 'eids' parameters accept a comma separated list of IDs.
Maybe I'll get around to writing something like a documentation for it some day (though the lack of it does have the nice effect of discouraging its use).
jesus it feels amazing when an admin actually listens and actually fixes and implements stuff
since i've gotten this far, i might as well try to milk this opportunity, any chance we could get documentation for the api[s] in the FAQ? like what fields u can query, [ex: eid, aid, cat, t] what values they can have [t=search, cat=5070] what those values mean [cat=5070... ????] what fields we can filter by [nyaa_cat] what fields we can order by [size, date, ...?]
I've been trying to figure the ins and outs of the API, but without documentation its very hard, and its even harder when the names u need to query by are different than the ones returned by the query itself [eid, aid]
for the linked torrent it believed it's blocked [I assume]
It's not blocked. The script just focuses on updating stuff from the last week, and rarely checks stuff older than a year. The more torrents accrue in the database, the rarer the checks on older torrents will occur.
I've added the "completed" value to the JSON API as 'torrent_downloaded_count'.
getting good tracker stats isnt realistic, i fully agree, but i think there are cases where updating seeding/leeching information is important: - on highly volatile torrents which decrease in seeders rapidly [say reporting 3k seeders, when it already dropped to 300 is bad] - on torrents that had no seeders, but now do I feel like those 2 things are important for discerning how usable a torrent is, for example the torrent I linked was reporting 0 seeders, when in fact it had 10, this is the difference between thinking a torrent is usable vs not, however I struggle with coming up with a way to choose which torrents should be updated when
whitelists i agree are annoying to maintain, and i agree with the ideology of "automate it once, have it work forever", it was just a suggestion to fix the fake seeders issue without creating complex heuristics
i dont think you should check if you can scrape a tracker or of its blocked on per torrent basis, for the linked torrent it believed it's blocked [I assume] yet it tried scraping other torrents
I also wondered if it would be possible to announce the "completed" count on the json feed, either from the "primary" tracker or from the 2nd biggest tracker on the list
Thanks for the suggestion. I've made it fall back to the old behaviour, if there's no info from the primary tracker, so it should be more likely to return something.
Getting good tracker stats is problematic here because all info has to be scraped, and with an ever increasing number of torrents, priority gets placed on the newer stuff. So it's not a case of a scrape fail preventing updates, it's just that old stuff gets updated much less frequently (if ever).
Whitelists need to be maintained, and that's not something I particularly want to do. It's not ideal either - I'm not sure how often it's still the case, but Nyaa's tracker used to not respond to /scrape requests for a while, so a lot of stats were missing (hence the old behaviour of not prioritising the primary tracker).
The tracker stats here are mostly about providing some info, even if inaccurate. If the info is important, you're honestly better off grabbing the data from Nyaa/Anidex, as they have direct access to their tracker stats without needing to periodically scrape.
it's also a bit problematic that trackers we KNOW are reliable arent re-scraped once a scrape fails, the link above failed a scrape 500d ago and hasnt been ran again since
sorry for breaking the reply chain, that was accidental, feel free to hide/remove the other comment
I assume this is due to the very recent "I've changed it to prefer the primary tracker over the highest figures, which should hopefully be more accurate." it needs some fallback
maybe tosho could use primary tracker, and also have a whitelist of trusted trackers?
I assume this is due to the very recent "I've changed it to prefer the primary tracker over the highest figures, which should hopefully be more accurate." it needs some fallback
Speaking about search, is it possible to filter out all ongoing episodes?
I.e. show only things like movies, batches, and/or episodes of series that finished airing long ago (maybe at least a week/month/year ago), e.g. fansub work in progress or encoding experiments.
14/07/2023 10:34 — Anonymous