I think something more is going on here. There has been a huge increase in deletions and many of them have nothing to do with OF.

When this started, I thought it was just OF trying a porn guardian service. This happens sometimes. When everything from a particular site suddenly disappears, but then the takedowns stop a week or two later, that's a trial.

But for several weeks now, when I look at torrents that were downloaded 24 hrs ago on my seedbox, half or more are unregistered. Many are not from OF. Some are even from sites like Reddit that have no copyright on the material their members post.

I don't think the porn guardian services use Google. I think they get accounts on all the major sites, then either write automated routines to scan (inexpensive, prone to error) or hire humans (expensive, but almost impossible to fool with m15pe11ing.) As far as I can tell, in the past few weeks, misspelling and omission of anything resembling "OF" has not protected any torrent from deletion.

Consider the evidence:

• This site has been asking for new mods for several months now.

• Any clever, experienced porn guard employee could say all the right things to get elevated to moderator.

• This site probably doesn't keep audit logs of additions/deletions/modifications, for the same reason it doesn't comment on DMCA. What isn't documented can't be subpoened.

• Once they're a mod, they can delete anything they want, right away -- and these deletions are basically undetectable, assuming nobody but the original uploader receives notification.

• Now they can easily delete posts for all of their clients, not just OF.

I've also observed the uploads per hour rate cut to 50% to 25% of what we were seeing before this started. That's the real problem with constant deletions, uploaders get discouraged. Only a small percentage will re-post torrents, and even they will only re-post a few times before giving up. If someone spends an hour preparing an upload, and it's deleted in 15 minutes, they're very unlikely to try uploading here ever again.

@raphjd - would you please let the Site Owner know that there may be a fox in the henhouse? If I'm wrong about not keeping audit trails, unauthorized deletions will be easy to detect. If not, perhaps deletion logging could be enabled temporarily to track down the culprit... Thanks!

Based on the timing of deletions, I would guess it's someone in western Europe or eastern US. But it could be multiple porn guard employees sharing the same mod account.

Of course, I could be wrong about all of this. It's the conclusion I draw from the evidence I can see, but I only see a small part of the total.

Me too. Seems to vary, sometimes it's so bad only a few torrents are active, sometimes it's nearly normal. I tried increasing the torrent client's sync time from 600 to 900 ms but that didn't help.

@marcustehkid - You're absolutely right about that, the studios and their agents file paperwork then torrents are deleted. That takes time.

Prior to the recent innovations, there were roughly three classes of takedowns:

1. Depending on what time of day they were uploaded, BBA torrents are usually taken down in less than two hours, sometimes much faster, so I always assumed the studio owner was on friendly terms, and was given a mechanism to delete quickly. These torrents are almost always deleted regardless of obfuscation. Together with the time-of-day dependency, that suggests a real live human is doing the work.

2. Torrents from studios with expensive porn guardian services (FX, SS, SR, EL, HYB, MM, BT, AF, etc.) are usually taken down in 2-12 hours. Some of these torrents were protected by obfuscation, so detection probably depends on both humans and algorithms.

3. Torrents from studios with less aggressive guardian services (CM, Stxs, Cdnt, Mn, etc.) are deleted within a few days, and obfuscation is highly effective, so these detections are probably machine dependent.

I've been watching very carefully for the last three days (Thursday/Friday/Saturday) and I've seen exactly the same thing happen every morning at approximately 9AM US Eastern time. Almost every torrent with OF content (and many others too) is deleted, starting with the most recently posted. Then, until about 5PM US Eastern, torrents with OF content are deleted almost as soon as they are posted, typically in less than 30 minutes, sometimes in less than 10 minutes, sometimes before they even start to seed. After 5PM Eastern, deletion of OF torrents becomes spotty and slow.

That is consistent with someone in NYC getting up and going to work from 9 to 5, scanning everything that was posted during the night -- page by page, starting with the most recent -- and clicking on the "delete" button next to everything that might belong to one of their clients. Once they've finished, they refresh the uploads page every ten minutes or so, and click on "delete" for anything new they see.

Filing paperwork takes time. These deletions don't. This is new and different.

If you want to see this for yourself, load every OF torrent that's posted between 5PM and 9AM Eastern into your seedbox, then watch their status change from 9AM to 10AM. You will see them become "unregistered", starting with the most recent. (If it's a single person, they probably only work 5 days a week, so there may be two days per week when torrents survive longer.)

I completely withdraw my suggestion that a porn guardian employee has somehow infiltrated the site. That was a silly thought, and I apologize to anyone reading this who might have been upset by that suggestion. The site operators are aware. That's why they're promoting and freeleeching so many old torrents. They know that some users will be disappointed at finding so much less new content, so they're trying to provide alternatives.

The popularity of OF has exploded in the last few years, especially during Covid. As most of the major studios had trouble operating under restrictions, individuals were still able to produce more and more OF content. Prior to the recent innovations, at least half of the new content posted to this site was from OF. Its absence will be sorely missed.

I love this site and I don't want it to change. I bet the operators don't, either. They must have been under tremendous pressure.

This site always had a terrible problem with torrent longevity -- most torrents die within a month or two -- but if the operators start re-promoting every old torrent when it gets down to 2 seeders, it could become a very impressive archive of gay porn history. I love libraries full of old books, so I'm sure I'll love a torrent site full of old porn. But that's very different from what this site once was, and us users will need time to go through the grieving process before we can accept what we've lost.

If I could make one request: please re-promote and freeleech more of the old amateur, homemade, and twink torrents. This site hosts a truly stunning amount of Asian porn, and it's very nice that so much of it has been re-promoted recently, but it only appeals to a subset of users.

It happens on qbittorrent v4.3.9 (old) and rtorrent / rutorrent 4.0 (the latest). It does not happen with Tixati.

qbittorrent 4.3.9 is at least a few years old so I don't think rolling back will help.

I think the only difference between these clients is the "default tracker timeout" value. Based on what I've seen, Tixati has a much longer default timeout so it doesn't have this problem. rtorrent says "Tracker: timeout reached" and qbittorrent says "skipping tracker announce (unreachable)."

Unfortunately I can't find any way to change the default tracker timeout value on any of these three clients. I thought I found the setting in rtorrent but it was the GUI sync timeout not the tracker timeout

This started 5-6 days ago and seems to get a little better sometimes. It might be load related.

Another possibility, has the site's tracker software been updated or changed recently?

I hope you can get this fixed, it's a real PITA.

@raphjd - If I have a tab open for a torrent that's been marked as a duplicate, and I refresh that tab, I see "Access Denied" and the page title looks like "DUPLICATE https://gaytorrent..." (the word duplicate followed by a link to the original upload.)

If I have a tab open for a rule-breaking torrent that is in Themed Movies, but isn't gay themed, and I refresh that tab, I'll see "Access Denied" and the page title will say something like "NOT THEMED". Similar for "collections" that are determined to have no common theme.

These torrents aren't deleted, they're restricted so that no ordinary user can see them in the search results or download them.

This is different. These torrents are being deleted. If I refresh the tab, I'll see "No torrent with ID."

There were always lots of takedowns on this site, and as others have pointed out, if this site didn't comply with DMCA it would have been sued out of existence many years ago, just like TBP.

What's different in the last few weeks is the speed and quantity of takedowns. Even the most rapid deletions used to take at least a few hours, and torrents often lasted for a day or two before disappearing. Now it happens very quickly, often in less than 30 minutes, and the number of torrents that are being deleted is much, much greater, covering a much wider range of material.

I tested this again this morning by looking through torrents posted during the night, opening them in tabs, then waiting a few hours and refreshing the tabs. At least two dozen of them were deleted, and some of them had nothing to do with OF. Some included amateur vids that have never been deleted before, i.e. part 2 of a Voyeur compilation from a site that doesn't exist any more and never had any copyrights over its user-contributed contents to begin with. None of them were duplicates or against the rules.

I understand that OF is on a takedown binge and it might last for a very long time; they have plenty of money to pay for takedown services. They've become the dominant source for porn, and prior to the last few weeks, more than 50% of the new content posted to GTRU was from OF. Why so many other torrents are also disappearing quickly is much more of a mystery to me.

In any case, the OF takedowns are having the desired effect. There is already much less content from OF being posted, and as more and more users see their uploads deleted in 30 minutes or less, they'll give up and go elsewhere. Of course, if "elsewhere" gets too popular, OF will go after it too, and the users there will go through this same frustrating experience.

@MrMazda thanks for the reply!

Found these two snippets online:

1. The rTorrent torrent client is a digital software that allows users to engage in peer-to-peer file sharing. The software was first released in 2005. It uses the C++ language and is based on the libTorrent (not libtorrent) libraries for Unix.

2. qBittorrent is based on the Qt toolkit and libtorrent-rasterbar library.

I don't think rtorrent uses anything from libtorrent (lowercase T) because libtorrent, as used by qbittorrent and bittorrent, was still in beta in 2005.

I was told by another mod here that this was the reason rtorrent doesn't deal with padding files correctly: it doesn't use libtorrent.

The other suggestions about the DDoS protections being too strict make perfect sense, but if nobody made any changes to the site, the tracker software, or the DDoS protections about six days ago, it's still a total mystery.

@bi4smooth said in No face.. warning:

Curious that there are NO POV movies where the POV is from the BOTTOM's perspective!

There aren't many, but check out VirtualRealGay POV for a few scenes from the bottom's perspective

Overly restrictive DDoS settings could be the cause. Definitely possible that Cloudflare made some changes and didn't tell anyone... but at least one other tracker that also uses Cloudflare is not having this problem. I use four trackers and this is the only one with timeout errors.

Or perhaps something happened that overloaded the server, about a week ago, and now it's timing out because of load. The problem seems to get worse at certain times of the day but that is compatible with both DDoS and server overload explanations.

Tixati does not have this problem at all. rtorrent and qbittorrent do. The only difference that makes sense to me is the default timeout value for initial contact with the tracker. I can't find any way to change this setting in either rtorrent or qbittorrent. (The rtorrent documentation is non-existent; I couldn't even find explanations of the settings in the source code.)

However there is an advanced setting in Tixati called upc_mss_init, default value 1212 ms, minimum value 300 ms, max value 1800 ms.

If your torrent client is having this problem, and you can find the setting for initial tracker contact timeout value, please increase it to at least 1.2 seconds and let us know if the problem goes away...

PS qbittorrent has more documentation but I could only find one use of "timeout" and it seems to only take effect when a torrent is stopped, not started:

"Stop tracker timeout — (default: 5 s) is the number of seconds to wait when sending a stopped message before considering a tracker to have timed out. This is usually shorter, to make the client quit faster. If the value is set to 0, the connections to trackers with the stopped event are suppressed."

@justanedflan - yes, I've seen him in four or five vids, all with Sammy. I think I got them from this site. If you download every Sammy Martin collection, you'll probably find most of them:

https://www.gaytorrent.ru/search.php?search=martin_sammy*&incldead=0&inname=1&indesc=1&orderby=added&sort=desc

But some of the collections are not well labeled so they might be hard to find, and some of the collections don't have any vids with Toby.

I might be able to post a Toby collection but it will be at least a week or two before I can do it.

Thanks for the info @lololulu19 and @john32123666 that's very helpful.

Here is another torrent that works with Tixati and qbittorrent, but doesn't load in ruTorrent and Transmission:

https://www.gaytorrent.ru/details.php?id=a918ac96bb2367e4e36d8b0cc7c85021226b58414ad7c0bf

This one also has padding files.

Overly restrictive DDoS settings could be the cause. Definitely possible that Cloudflare made some changes and didn't tell anyone... but at least one other tracker that also uses Cloudflare is not having this problem. I use four trackers and this is the only one with timeout errors.

Or perhaps something happened that overloaded the server, about a week ago, and now it's timing out because of load. The problem seems to get worse at certain times of the day but that is compatible with both DDoS and server overload explanations.

Tixati does not have this problem at all. rtorrent and qbittorrent do. The only difference that makes sense to me is the default timeout value for initial contact with the tracker. I can't find any way to change this setting in either rtorrent or qbittorrent. (The rtorrent documentation is non-existent; I couldn't even find explanations of the settings in the source code.)

However there is an advanced setting in Tixati called upc_mss_init, default value 1212 ms, minimum value 300 ms, max value 1800 ms.

If your torrent client is having this problem, and you can find the setting for initial tracker contact timeout value, please increase it to at least 1.2 seconds and let us know if the problem goes away...

PS qbittorrent has more documentation but I could only find one use of "timeout" and it seems to only take effect when a torrent is stopped, not started:

"Stop tracker timeout — (default: 5 s) is the number of seconds to wait when sending a stopped message before considering a tracker to have timed out. This is usually shorter, to make the client quit faster. If the value is set to 0, the connections to trackers with the stopped event are suppressed."

@MrMazda thanks for the reply!

Found these two snippets online:

1. The rTorrent torrent client is a digital software that allows users to engage in peer-to-peer file sharing. The software was first released in 2005. It uses the C++ language and is based on the libTorrent (not libtorrent) libraries for Unix.

2. qBittorrent is based on the Qt toolkit and libtorrent-rasterbar library.

I don't think rtorrent uses anything from libtorrent (lowercase T) because libtorrent, as used by qbittorrent and bittorrent, was still in beta in 2005.

I was told by another mod here that this was the reason rtorrent doesn't deal with padding files correctly: it doesn't use libtorrent.

The other suggestions about the DDoS protections being too strict make perfect sense, but if nobody made any changes to the site, the tracker software, or the DDoS protections about six days ago, it's still a total mystery.

It happens on qbittorrent v4.3.9 (old) and rtorrent / rutorrent 4.0 (the latest). It does not happen with Tixati.

qbittorrent 4.3.9 is at least a few years old so I don't think rolling back will help.

I think the only difference between these clients is the "default tracker timeout" value. Based on what I've seen, Tixati has a much longer default timeout so it doesn't have this problem. rtorrent says "Tracker: timeout reached" and qbittorrent says "skipping tracker announce (unreachable)."

Unfortunately I can't find any way to change the default tracker timeout value on any of these three clients. I thought I found the setting in rtorrent but it was the GUI sync timeout not the tracker timeout

This started 5-6 days ago and seems to get a little better sometimes. It might be load related.

Another possibility, has the site's tracker software been updated or changed recently?

I hope you can get this fixed, it's a real PITA.

Me too. Seems to vary, sometimes it's so bad only a few torrents are active, sometimes it's nearly normal. I tried increasing the torrent client's sync time from 600 to 900 ms but that didn't help.

Just FYI. Some European DNS servers appear to have deleted the entries for tracker.gaytor.rent and plab.site.

tracker.gaytorrent.tw (this site's original tracker address), tracker.gay-torrents.net, and gay-area.org still seem to work... at least, for now.

If you're affected by this, your torrent client will say something like "timeout reached" or "lookup failed" or "address unavailable".

You can bypass by configuring your resolver to use a public DNS server (google for a list) and you can test to make sure that it still serves these sites with nslookup:

> nslookup
> tracker.gaytor.rent
No records found
> server 4.2.2.2
> tracker.gaytor.rent
Address:  103.86.96.100

@WikiDude completely agree with your last post.

Some good news! This torrent has the problem with loading, despite the fact the Uploader is using the latest version of qbittorrent:

https://www.gaytor.rent/details.php?id=a63f1c805bc2cb03c5b667a78b72ba10eaa36d4243ea72b9

But @duncalem posted a solution in the comment section:

"When using qbittorrent, under tools ---> torrent creator, set torrent format to V1. That got rid of the padding for me and I upload big chunky torrents. Nobody has had an issue."

So it sounds like this problem is NOT fixed in the latest libtorrent release... but if everyone sets their torrent type to V1, this problem will not occur again.

Would it be possible to add this to the site-wide banner? "If you're using qbittorrent, under tools ---> torrent creator, please set torrent format to V1, otherwise many users will not be able to download your torrent."

Thanks again!

@WikiDude - "distracted by other business" - me too, sorry for the delay.

I want to separate my dislike of padding files from this particular problem.

As you mentioned, other sites edit the .torrent file headers / metadata by which I mean the human-readable ASCII text stuff at the start of the .torrent file. Of course it is mathematically impossible to edit the CRC data without access to the original files.

I believe this particular problem is in the metadata, not the CRC data, which means the site processing code could fix it, at least theoretically.

Here's a really interesting data point: someone recently uploaded 3 HYB collections, all with padding files. The first has this particular problem, it doesn't load in rutorrent etc:

https://www.gaytorrent.ru/details.php?id=fc1302d52e36a1f4e36d8b0cc7c850219bb656a051b3bd24

But the second and third load correctly!

https://www.gaytorrent.ru/details.php?id=daf5924632c7b6eae36d8b0cc7c850216126d5762d5a277f

https://www.gaytorrent.ru/details.php?id=21c9b85cbd858c96e36d8b0cc7c85021a59b36317074b75d

Unfortunately I can't see any major differences in the header / metadata. All three have this odd "root32" keyword followed by non-ASCII text, which I've never seen before in any other .torrent file.

Maybe the other sites are automatically stripping out any keyword they don't recognize, like "root32", and that kept this particular problem from happening to them.

Anyway, thanks again for all the help and support, it's always nice to think through these issues with another pro

@WikiDude thanks for looking at this, I really appreciate it!

I am responding to your most recent post in that torrent's comments, quoted here:

Thanks for your comments:

1. this isn't a qBitTorrent issue, it is a libtorrent issue (libtorrent is the "driver" software that qBitTorrent uses - but it is from a different development team. Kind of like differentiating between the Windows OS, and the qBitTorrent app.)
2. I hadn't thought of it, but yes - a non-padded torrent WOULD appear significantly smaller... however, as I noted in my post above: those "padding" files are created as "sparse" files with all zero data. ACTUAL XFERED DATA is practically nil! Depending on the filesystem you download into, they may also store as practically zero-length files (in storage, not in the OS listing of the file size).
3. exactly how is requiring uploaders to use a specific encoding client any different from requiring downloaders to use a different torrent client? Keep in mind that there is nothing preventing you from using multiple torrent clients on your system... I would presume that you have more than 1 browser on your system?
4. Neither this site, nor any torrent site that I am aware of, actually CREATES the .torrent data! Uploaders (users) do that!
   That you haven't run into this issue on another site is simply a matter of chance. To wit: How many "collections" are you downloading from other sites? (For my own personal use, this site has an enormously larger percentage of "collection" torrents - the ONLY torrents this would apply to, as padding data exists solely to "space out" data in the stream so that individual files always start on a "block boundary"). I'd say that, other than torrents where there is a separate .srt file, or those damnable uploader text files, the VAST majority of my downloads from other locations are single files...

#2 is unfortunately incorrect for most torrent clients and filesystems. When I download a 32MB file of all zero bytes from my seedbox, it takes exactly as long as downloading a 32MB file with non-zero bytes.

Same for ratio: when I download a torrent with lots of padding in Tixati (my alternate client when rutorrent doesn't work) all of the padding bytes count against my ratio. Not that I care, I have a 2 petabyte buffer, but some people have to worry about their ratio.

For instance, when I deleted the .pad directory for the ASG torrent, I got about 34 GB of disk space back. File with all zero bytes are only more efficient if you're using compression. If you're not using compression, then on the disk, and through the network, there is no difference between files with just zeroes and files with both ones and zeroes.

qbittorrent may never actually download the padding files at all. I believe the default behavior is to completely hide everything having to do with padding. That's why so many Uploaders don't know their torrent client is adding pad files, I usually have to ask them to click on [See full list] before they believe that such a thing exists. So if you're using qbittorrent, the pad files may indeed appear to take no time to download, because they're not being downloaded. However most torrent clients don't have this feature, so they treat the pad files just like any other pic or vid file.

#3 I don't want to require anyone to do anything, but this error was introduced recently, and it would be very nice if we could "patch" it by removing whatever extension field or metadata that's causing this error in so many other torrent clients.

I've read a lot of comments from frustrated users on the torrents with this error, and it appears most people only use one torrent client, so when they get an error, they think there's something wrong with the torrent file, they don't think there's something wrong with their torrrent client, and they don't try a different one.

BTW, it's possible this error was fixed by an even newer version of qbittorrent/libtorrent, because I've recently seen a few large torrents with lots of padding files that load correctly in rutorrent. So maybe the solution is to ask all the libtorrent users to do one more upgrade. I don't know for sure, because I can't figure out what's causing the error. However when I look at the headers in these .torrent files it seems like there's some entries I haven't seen before.

#4 I download a large number of multi-file torrents from other sites. You're right, no other site has anywhere near the content that we have here, but I get probably a third of my torrents from other sites, and many of them have those pesky .srt files and thumbnail pics etc. This particular error (fails to load in rutorrent, Transmission, and others) started a few months ago. On GT, I run into this error maybe once per day (I don't post every link here, and I didn't start this thread until recently.) On the other sites, I've never had this happen, not once. Just based on the numbers, I don't think it's coincidence.

Yes, Uploaders create the initial .torrent file, but this site's processing engine modifies them too. When I upload a new torrent, the .torrent file I download from the post-upload page is not the same as the .torrent file I initially created with my torrent client.

Maybe the other sites are using some logic that strips non-standard extensions and metadata from .torrent file headers.

Again, really appreciate you taking the time to discuss this. If there's a solution, it may apply more broadly, and shield us from the next bug that the programmers will inevitably introduce...

Here's another: https://www.gaytor.rent/details.php?id=6a809e77600f674be36d8b0cc7c8502181602e1508fbea21

@raphjd or @DandyLion or @MrMazda -- would it be possible to post a site-wide notice recommending that uploaders turn off padding? This torrent has > 33 GB of padding files with meaningless random data. Some downloaders will not realize that they have to unselect all the padding files, so they will waste quite a bit of their ratio on useless files. And most Uploaders don't even realize that their torrent clients are adding pad files... Thanks!

Here's another that doesn't load in some clients:

https://www.gaytorrent.ru/details.php?id=81f383cfd172816fe36d8b0cc7c85021fe6fa0f9067eb7f4

But this one, with the same .pad files and from the same uploader, did load correctly in ruTorrent:

https://www.gaytorrent.ru/details.php?id=84dbfeeba59b9ef2e36d8b0cc7c8502144a4fda46cd45dd3

No idea what the difference is, except the second is smaller than the first.

And here's another larger torrent that doesn't load in some clients, also with .pad files:

https://www.gaytorrent.ru/details.php?id=ee8de7a2fd80e9e0e36d8b0cc7c850212568fe7288f45e39