I see, im really not sure what the best way to fix this, other than hiding the non nzb results. i paged them about supporting it as nzbhydra reject results that dont have nzb in them.
A vpn is the opposite direction from where they're going. It may have to do with some big court cases in their country and they're trying to dodge the problem.
If you haven't tried MultiUp here, they give 3 or 4 more ddl-services you might have some luck with. Ignore any pull-down menus here and click on the site link then "download" to see the choices.
aside from suggesting a vpn which i have no idea if that would work or not i hope they decide to reverse their decision, the only other DDL i can use is clicknupload and it's pretty slow
Weird that a lack of an NZB would confuse the application - probably a bug that needs to be fixed on their side?
I'd imagine hiding those entries would be even more confusing (particularly with paging) because NZBs aren't added in any particular order, so you'd have entries randomly showing up at different places in the feed.
using torznab endpoint work as expected, because i assume all links have magnet and/or torrent link. however, nzb only avaliable when processed via your server. they still show up when /api?only_nzb=1 present which confuses the apps.
Unfortunately, I don't use that app so don't know what the problem is - are you able to give more info? The only_nzb/tor flags just suppresses including two enclosures as some applications can't handle them, and it appears to work as such. /api is preferred; /nabapi points to the exact same thing. They somewhat follow the Torznab/Newznab API, so that should provide needed documentation on the endpoints?
Hello, is it possible to fix the api in a way that only returns what is requested? /api?only_tor=1 and /api?only_nzb=1 animetosho api usenet is failing. using the new prowlarr app of *arr family. also it's possible to document the api endpoints e.g.
From a quick look, it seems like Free has disabled uploads to anyone not using a Free.fr IP. If anyone knows a way to upload to Free, am interested to hear.
If your question is specifically 'why', the parser doesn't fully recognise the naming format used by VipapkStudios (using pipes to separate everything), whereas it does understand Tangmen's format. In both cases, it can pick out the title, but to figure out the season, it needs to be able to extract the episode number.
Unfortunately, it's a problem with trying to automatically determine categorization - there's quite a variety of naming schemes used and it's hard to write a parser which accommodates everything. Pipes are more commonly used to separate alternative names rather than episode numbers, for example.
I've put in a specific rule to handle their scheme (though it's somewhat fragile, and their history shows that they change naming schemes every now and then).
Hi, long time freeloader and user here. I'm just writing here to thank you for the splendid service that you provide this community. Keep up the good work!!
Thanks for the suggestion. I feel that may be a little out of scope for this site. I'm not too familiar with anime trackers, but I imagine there's plenty of other sites/tools which can do this for you? If so, it's probably better to use that. Maybe start off with places like AniDB/MAL and the like and see if they have what you want.
Hi, not really hating this page, maybe a suggestion for improvement. I would like to be able to keep track of the Anime I want to download.
I frequently lose track of time, and forget to download the episodes for current Anime. If it was finished, you have a lovely archive or batches to get almost everything all at once. But if one is ongoing, and new episodes get released, I would like to see how far I have to download. Also if a sequel gets released down the line.
It would be really awesome if I could just pop in and check "My List"
Requests are rate limited and throttling is applied if too many are sent. If the feed is queried frequently, most of the data returned would be identical, and mediainfo can take up a lot of space/bandwidth when aggregated across many files. Constraining info to specific requests avoids this bandwidth wastage (assuming the client is well behaved).
I've added a torrent request function - you need to give it the ID of the torrent you're querying (example). Hopefully that gives you what you're looking for.
This sounds good, i was just afraid that crawling the links might put stress on the your servers where is not needed. but if thats the way you approve of then i think all good.
taking few secs to generate the feed server side and caching the result seems to be much more ideal then doing ( feed.count x feed.object.files x files.mediainfo ) requests. Of course the requests would depend on how you plan to implement files within. as in one request or induvial for media info.
if it's just {feed.id: { files:[ {info.., mediainfo: {} }] } then yeah that would work if it's individual request for each file to get media info. that wouldn't scale as some torrents has hundreds of files each.
Thanks for the suggestion. If people want it to be added, it can be looked into. Otherwise, if people are happy with the manually supplied links, I guess the current setup is fine.
If you add uloz.to as one of your ddl hosts, you might be able to minimize someone adding comments to new releases. It's requires a captcha, so it's not a great host.
12/06/2021 12:29 — admin