This might come as a surprise to you but anime is not American TV. There's nothing wrong in an obese person trying to fit herself into slim clothes. Fact is it won't work and if it does work you can picture how she's going to look.

This might come as a surprise to you but anime is TV so there's nothing wrong with organizing it under the same rules one does other TV

thank you, much appreciated !

Anime databases are geared towards anime while tvdb guys aren't anime fans. Only when tvdb's anime users began crying did they make this hack job solution.

truly based!

I find anime databases to be way more inconsistent with their rules while thetvdb just treats anime like TV which you know is what it is

People will have their own opinions on matters.
By all means, put forth your points, but there's no need to devolve into pettiness.
Please remember to respect everyone's differences.

you mispelled best.

Thanks for the correction 😊

TVDB is one of the worst indexers for anime. Period. It makes up it's own rules and is a pain to work with. AniDB is infinitely better.

Just wanted to mention that TMDB does.

anidb you've often got these issues that crop up as there is no standard and seasons get split into multiple entries etc, while tvdb wouldn't have any of this issues as long as its listed. Anyways doesn't matter to me, it's your site to do as you want, so I'll drop it.

I'd definitely disagree on all accounts. S00 is the best option and anidb is always bad.

I'd argue the opposite actually - TVDB doesn't have 'proper' listings and 'S00' is an ugly hack to workaround their limitations.
And TVDB is generally worse than AniDB for anime - if anything, they still don't have listings for the specials mentioned above, whilst AniDB does.

why not simply use tvdb always anyways... considering mal and anidb don't have proper seasonal listings to begin with?

Unfortunately 'S00' doesn't provide clarification on what the correct season is.
But I've mapped those entries to the correct AniDB episodes.

for what its worth labelling under S3 should be enough. this is out of tosho's hands, as theres no anidb listing for it.

Thanks for raising the issue.

The 'S00Exx' naming scheme almost guarantees entries to be mis-classified, as it's not a scheme recognised by AniDB (or any database other than TVDB for that matter) unfortunately, and there's no obvious way to automatically map them correctly.

here whats tvbd list: https://www.thetvdb.com/series/laid-ba...official/0

as per yameii on nyaa: TheTVDB seems to be late once again adding these specials to their database. Specials seem to be completely locked from being able to be edited by the community on their site. Once they do add these specials, they will be named S00E20, S00E21, and S00E22 respectively.

not sure why tosho doesn't label the yuru camp ovas as seperate entries. they are OVA specials but the database lists them as under season 2, which is not the case. can the admin make new entries for the yuru camp ovas

https://animetosho.org/view/yameii-lai...r.n1890156
https://animetosho.org/view/yameii-lai...r.n1890155
https://animetosho.org/view/yameii-lai...r.n1890154

yuru camp s3 ova: anidb - https://anidb.net/a17676
anilist - https://anilist.co/anime/177007/Yuru-C...ASON-3-OVA

Lol, that happens for us as well when using miru.watch / Miru app

A 'new release' filter might not do what you want as the time it takes for NZBs to appear can vary.
It might be better to fix the error instead?

Have you tried asking SABnzbd on why an error occurs if there's a missing NZB?

I found a maxage switch but there isn't one for minage. Can the developer add this? This should stop the really new links from showing up in my feed. Unfortunately SABnzbd filtering quite limited

I just wanted to add i have the "only_nzb=1" in the URL

I use this site RSS to fetch NZB to SABnzbd, however, I find that for very new releases < 1hr, the NZB isnt ready yet (not available) and this will result in an error. Is there a parameter I can add in the RSS URL to limit the min age to say 6 hrs. SABnzb cant do this, there is no filter for age. Any suggestion is helpful. Thanks

same.. I stick with rio for the dark color scheme.
I don't want to be blinded by random bright colors.
That's what DarkReader browser extension is there to ensure against.

"But once you've put in a few years here you will come to understand the joys of the new seasons colors"

Speak for yourself, I always use the same one. I detest the bright ones.

Where the site design and color schemes originate we dare not ask, we are not worthy. The internet historians of 2099 will wonder at the artisan that designs the site in the same way we wonder at someone like Van Gogh. We find ourselves asking - How?...Why? and, Where even do the colors like this come from? and crucially: Why do I like it? We do not know, and if we did we would not be able to express it with language. We can only sit back in silent wonder.

There is color options for newfags. But once you've put in a few years here you will come to understand the joys of the new seasons colors, and the sadness as we say goodbye to the previous schema.

so true. thank you anon.

Revolutionary 3D-CGI music drama series "Girls Band Cry" will stream on Crunchyroll starting 6th Nov 2024. It was announced to coincide with MC Iseri Nina's birthday (10.24) Anime industry will be disrupted for certain by our favourite 200,000 polygon gremlin!

Sorry, I don't understand your question?

seems like it :/

Is tosho down for indexing rn?

yeah oldman, but i like bright mode...

ahhh this yellow burns my eyes

There are several limits in place.
It might be best to avoid concurrent requests, and space them apart to avoid hitting the limits.

only reason i was hitting the limits was because i was making concurrent requests.
also what kind of rate limiting do you have? like burst or normal (one request every x sec) it feels like its normal

Thanks for the suggestion.
I'm rather reluctant to add details of such, as I don't promise anything and like to be able to change how it works when necessary. I also consider the limits to be relatively generous and don't want to encourage getting close to the limits.
You (as a human) generally shouldn't hit them under normal usage; as for applications/scripts you'll need to be considerate and space out the requests to not overload the server. I don't have any concrete guideline, but if you're hitting the limit, you're querying way too fast.

I don't believe limits to be unusual - practically every sizable website implements them, and they almost never provide any details.

If you need a lot of data, I provide database exports for that.

you should add rate limit details to the FAQ page

np

Requests are rate limited to prevent misbehaving clients from overloading the server.
nginx defaults to sending HTTP 503, likely because 429 is a relatively newly defined HTTP return code.
I can change it, though it's always been 503 for as long as this site has existed.

Sorry for your lost time.

i spent a solid hour plus one sleep wondering why one specific request was only getting 503'ed

why does the rate limited response from the json api give `503 Service Unavailable` and not `429 Too Many Requests`?
well i think its a rate limit?

Thanks for the correction, but are you sure?
https://www.wordnik.com/words/labelled
https://www.wordnik.com/words/labeled

*labeled
"Led to label" makes no sense :P

You can try enclosing terms in quotes for results to match more precisely, which might help, otherwise it's a keyword based search.

I don't understand why you're needing to look at the page source. It's minified (whitespace removed) to minimise bandwidth consumption.
If you want a list of info hashes, I make database exports available which you can use to search on.

Thanks for the suggestion on search. I had originally thought about using it to search for file hashes instead, but that never got implemented, and, now that I think about it, redirecting on info hash doesn't really interfere with such a feature.
So if you put an info hash in the search, it should now redirect you.

if you need to transfer binary data through a text interface you can make use of base64 or some similar encoding, the it only enlarges the datastream somehow (base64 about 1/3) but sometimes its easier to encapsulate something then finding a way to get an alternative/"out of band" stream ...

thats nice that this works with some url-aliases but why not also put it in that search form , especially that info hash is so unique that you can detect it and then just skip to the info page skipping search resoults, i mean from a user perspective, now i know there are url-aliaess but the normal thing to do would be using a search box and not trying some urls that most users wouldnt be aware of existing...