maybe its because they are in a container instead of being uploaded as single files.
Forcing everything into an archive will obviously force indexers to treat the whole thing as one file. But wrapping things in RARs is generally a silly thing to do and isn't what's done here. It's unfortunate that this is the case, but that's just Usenet I guess.
the known bad stuff like cleo or judas which take another release and re encode it
I believe Cleo generally re-encodes off someone else's encode, but Judas generally encodes directly from source, which presumably fits your definition of "original release", so you'd be mistaken on that part.
i see usenet as a backup for obscure and hard to find content that might not be seeded anymore when i find it so that why i see this site as a huge waste of potential
Processing more content is nice, and I have no idealistic objection against it. However I have limited resources to work with, so, as much as I don't like it, I have to draw a line somewhere.
I'm glad that you see an opportunity for hosting obscure content in Usenet, and again, I'm not against the idea - I just am unable to do it. And this is where you can help - with that motivation, I'd encourage you to look at what's needed to make it happen. If it's of any help, I do publish the tools I've written for Usenet uploading, free to be used in any way, to further assist you (or others) in achieving such a goal.
I'm hoping you see AT not as "wasted potential", but more as a demonstration of potential. Go and achieve what I am unable to!
What you want doesn't suit me and what I want doesn't suit you. But it sounds like you have plenty of resources, so I'll just wish you good ridden-- luck.
interesting. they never got split up like that when i uploaded complete packs. maybe its because they are in a container instead of being uploaded as single files. and for the encodes i was talking about the known bad stuff like cleo or judas which take another release and re encode it. you upload plenty of those but miss the original release. these days many releases can be up to 30gb in size and sometimes even more. i see usenet as a backup for obscure and hard to find content that might not be seeded anymore when i find it so that why i see this site as a huge waste of potential
splitting complete season packs before uploading them?
No such splitting is performed. The NZBs available here are how the files are posted - i.e. as one complete pack. Many indexers are unable to properly group files together, so they display them separately. Unfortunately, I am unable to fix their problem, but if you know of a feasible way to signal that files should be bundled together, do let me know. Alternatively, you can try pointing out the issue to them so that they can group files properly.
your uploads are not worth getting anyway
If you want to completely exclude AT's uploads from your searches, check if your indexer/application supports a poster exclusion filter, as uploads here are always posted with the same name. Alternatively, posts are always made to a.b.multimedia.anime.highspeed, so you could filter out that group, though that may also exclude other uploads. Presumably that would also fix your "flooding problem".
If you're looking for something that adheres to your own subjective notion of "good encodes", you're more than welcome to run your own setup.
why do you flood usenet by splitting complete season packs before uploading them? these are only annoying on the search result listings of indexers and also much harder to download than the complete pack. most of your uploads are not worth getting anyway because your size limit skips almost all of the good encodes and uploads some shit tier mini encode instead
> I wasn't able to replicate an issue with ClickNUpload though. It looks like they send a double Content-Disposition header
I'd guess Click embed the error with poor handling of the input initially. Nothing like misreading the headers initially and hardcoding the problem for subsequent serves. (Stripping commas should fix theirs too, if that's the case.)
Firefox gives the filename as the shortlink for the free download, sans extension. Can be saved, and then just renamed to the true name.
As an above poster points out, it looks like Free isn't wrapping quotes around the filename they send, which gives an error in Chrome, and gives a weirdly named download in Firefox (I'm guessing the file is valid, just the name is weird). A different browser may give different results (like the poster above trying HR's version), but regardless, it's a spec violation on Free's side. I can work around the issue by stripping out commas in filenames when uploading to Free.
I wasn't able to replicate an issue with ClickNUpload though. It looks like they send a double Content-Disposition header, which some browsers may not like, but this seems to be the case regardless of commas in the name. Firefox doesn't seem to have a problem downloading the file though.
Using ep7, downloading the HR version with Free, and the Ember version with ClicknUpload was fine on my laptop. Both versions have commas.
I suppose you can try other hosts. If your native alphabet is different, I suppose there could be some kind of non-ascii problems. Or if you're using the same anti-virus or ISP for both devices.
i have a weird problem that only started a couple weeks ago with free and clicknupload, it only seems to be affecting this series specifically from what i watch but whenever i download "Kumo desu ga, Nani ka" via them it seems to be giving me problems of a broken download webpage on my phone and no download or it just gives me a windows file if i do it on desktop, i have a feeling the comma in the filename is causing problems
Comment in Feedback 19/02/2021 15:02 * — Anonymous: "Fallon"
I'd like to think this is the kind of thing I'd build if I had the skills... but since I don't, I'm glad someone else dreamed it up. You're doing the lord's work here, thank you.
The cache period is set to 5 minutes, so there's little point in querying it more frequently, as you'll just get the same result. I personally think 5 minutes is too frequent for most people as I can't see much reason for such frequency, but I'll let you be the judge there.
I generally don't trust people to follow any suggestion I'd make for an "acceptable refresh interval", hence the enforced caching period.
I see, thanks for pointing that out. Hah, talk about poor documentation. I can look at implementing some of those parameters (though maxage is less useful if sorting by date).
Has Search here always been limited to 15min updates here, or are you getting squeezed by all the other stuff most of us will never use like NZB and RSS? Your own search seems more integral to the site.
Interesting quirk: reloading the Search page only refreshes the left banner system clock every 15min as well.
Ah I see what happened here, that particular readthedocs page seems to have omitted the Optional Parameters section on search for some reason. It's still present in the document if you click "View page source" in the top right.
Every other raw version of the API spec that I can find has it as well.
I don't believe it ever was supported, and Newznab doesn't define that parameter for search anyway. They only define it for movie-search, music-search and book-search, none of which is supported here.
ah, I wasn't sure if you modified torrents or not, since Nyaa does, which I consider shit, it's fully understandable why you wouldn't do it, I've just been going around and asking for WebTorrent support and already got a few uploaders to add wss trackers so it's great that they aren't stripped, thanks for the quick reply and implementation! <3
Thanks for the suggestion. I've added CORS headers to feed.animetosho.torrentbay.st and storage.animetosho.torrentbay.st
AT is currently neutral in that trackers are passed through, as is. As such, I'm somewhat unwilling to modify torrents at this stage. I think it'd be better to get the uploaders to add Webtorrent trackers to their torrents, and/or get Nyaa/Anidex to support/enforce it on their side. If support is added there, it'll naturally work here (maybe the seeder/leecher scraper would need to get updated, but that's about it).
hey, now that webtorrent is slowly becoming a thing, will tosho add support for it? its mostly really easy 1line shit like adding a wss tracker to torrents and enabling cors ONLY on RSS feeds
It's behaving normally for me: Ads blocked and just mkv files downloading. Can you provide a link to the AT page that produced an exe download for you?
Otherwise, perhaps you can update your blocker. uBlock Origin has been recommended by several users here.
03/03/2021 11:54 — admin