Unexplainable "Unregistered Torrent" Warnings

Kevin4fm

I've currently got eight torrents (out of c. 490 for this site) that are showing as warnings in qBittorrent, with the message "Unregistered torrent". The number has grown over the last couple of months.

"Unregistered torrent" is usually a sign that a torrent has been deleted from the site for some reason, but in all cases each torrent is still showing, and appears to be active. Two of these eight are torrents where I'm the originator. In all cases (except the latest), I've deleted the torrent, redownloaded it, and forced a recheck, but the warning returns.

I'm not hugely concerned about probably losing upload credit, but seeing warnings and errors in my client drives me nuts! Five of these are torrents I plan to seed long-term, so the issue won't just "go away" when I delete individual torrents.

Can anyone tell me what I'm missing, or suggest a possible cause?

Kevin4fm

Correction! As is obvious from the screenshot, I've only tried redownloading five of these torrents, not the three most recent ones.

MrMazda

@Kevin4fm Do you have the URL for these torrents? It may be possible that our sysop needs to poke the database with a hot stick.

Kevin4fm

@MrMazda

ianfontinell

@Kevin4fm i tried a few and they appear as working without any tracker message, could have been just a glitch, or like the youth say now "it must have been the wind"

Kevin4fm

@ianfontinell Oh, they're working. "#helix" is seeding as I type, but it's shown as unregistered and as a warnnig.

The "weird" thing is that they should be no different to any of my other torrents, which work fine. And readding them doesn't cure the glitch.

Dracula975

@Kevin4fm First let me say that whenever there's a "strange" issue, my first reaction is "are you using qBittorent?" That client has had so many buggy issues, that it is now my first question when trying to troubleshoot. That said, here's what Google AI has to say:

"The "Unregistered Torrent" error combined with a working transfer is a common phenomenon in qBittorrent that typically points to a temporary timing sync issue or the localized use of decentralized networking."

Suggestions/Solutions: Wait for qBittorent to roll out yet another probably bugged update, or change clients.

Kevin4fm

@Dracula975 Understood, though personally I've not encountered any siginifcant bugs with qB, and I much prefer it over uTorrent.

But if it was a bug with my client, I'd expect that bug to be consistent across all of my torrents. This is happening on only eight out of nearly five hundred seeding torrents. I've just checked, and whilst I'm not using the latest version of qB, I am using the latest recommended one for Linux, my OS. I've had a few issues with getting my client to play nicely with my VPN, so I don't think upgrading beyond the version recommended by Linux is a risk worth taking for now, for what is only a minor annoyance rather than a significant problem.

It's also happening only on torrents from this site. I don't now have a lot from elsewhere, especially since the takedown of "the-site-that-should-probably-not-be-named". There are only a dozen seeding, and they've been doing so for a long time. I mainly just download from the three other sites I use, because I'm hugely in credit, but haven't noticed any error / warning message when I've been doing so.

Dracula975

@Kevin4fm Oh, believe me, I understand your logic. Why just these files, why just this site, why...

You would be surprised to know how often I hear those same questions when it comes to qBittorrent. Unfortunately that's the problem with bugs. They can be near impossible to pin down, without full knowledge of what actually causes them and what programming was done to create them. Not to mention the coding for different trackers handling different errors differently. Different .torrent creators creating torrent files differently, etc.

Is it possible it's not qB? Sure. But my bet is, it's qB. Wait for a new stable update for your system, and see if that fixes it. There may also be a setting somewhere in the client that can be switched on/off that could also affect just those few files. I'm no expert on clients, so I wouldn't know where to start looking.

Hopefully it won't be too frustrating for you either way. At least knowing it might just be a glitch, and it's really not affecting your uploading/downloading, will provide enough solace.

Kevin4fm

@Dracula975 Maybe the best temporary solution for me is to always view qB on the same monitor, full screen, and physically put a bit of masking tape over the "Warning" line in the panel. If I can't see it, it won't scream at me every time I glance at it!

ianfontinell

@Kevin4fm what is your qbt version? Consider downgrading to a more stable release.

Kevin4fm

@ianfontinell I'm on 4.6.3. That's considerably below the most recent qB release already, but it's the latest that Linux offers directly.

I'm reluctant to downgrade for the same reason as I am to upgrade. Other than this problem, I've had no issues with the version I'm using. And, to be honest, I feel it more likely to be a site-side issue than a client issue, given the available information.

That it's showing any sort of error bugs me, and I may be losing a bit of upload credit, but that won't be a lot. Five of the torrents are old, niche ones, which have uploaded less than 10gb between them since they were added. Three are short term, so if they start taking up bandwidth at the expense of other seeding torrents, I can just delete them.

ianfontinell

@Kevin4fm said:

@ianfontinell I'm on 4.6.3. That's considerably below the most recent qB release already, but it's the latest that Linux offers directly.

Isn't your disto compatible with AppImages? Qbt is always built for Linux in that format, there are many releases after 4.6.3 already.

Joker

@Kevin4fm Dug into this properly, using "#helix" as the test case — nothing is broken on your end or ours; the message is literally true.

A torrent is identified by a fingerprint of its contents, not by its name. The "#helix" you're seeding carries the fingerprint of an earlier upload of that release which was later removed from the site (duplicate cleanups, re-uploads and the like happen all the time). The page you linked is a newer upload of the same release from June 2 — same name, different fingerprint. Your client keeps announcing the old fingerprint, the tracker honestly answers "unregistered torrent" — meanwhile the current version seeds happily (54 peers on it right now), and your client announces your other ~500 torrents just fine. With that many active seeds, every now and then one of them turns out to be a version that later got replaced or removed — that's why the number slowly grows.

The fix, per affected torrent: remove the old entry in qBittorrent (keep your data), download the .torrent fresh from the live details page, add it pointing at your existing files and let it recheck — it joins the current version and counts again. Important: redownloading without removing the old entry just adds a second entry — the old one keeps warning forever, which may be what you saw after your redownload round.

Where there's no live page anymore (the release is simply gone from the site), the warning is permanent — that entry can safely go, it isn't earning you anything.

No database hot-sticks needed this time

Kevin4fm

@Joker Thanks for investigating. The process you describe for fixing it is exactly the process I've tried on several of these multiple times already.

I've just tried again on "Doctor's Mine" - https://www.gaytor.rent/details.php?id=RTSvW-CydK9lh7zCqXtYsw - and "OF-Shane Hall" - https://www.gaytor.rent/details.php?id=uo_NNanxkhEEygcvuqCI5A.

qBittorrent won't allow you to have the same torrent listed twice. If it already exists, it just displays a warning, asking if you'd like to merge the trackers. Of course, if they're not exactly the same torrent - but maybe sharing the same name and files as an existing one - it probably would allow it. But I've double checked this isn't the case. I have a very structured naming syntax, so I'm confident it would leap out if that were the case.

I checked both torrents were exactly those I thought they were, by pausing the original before deleting it then checking that both my total seeded torrents and seeders of that torrent both dropped by one after I'd done so. After readding then restarting each torrent, both numbers rose by one.

In both cases, after I'd carefully gone through the process to readd them, those torrents immediately flagged the same warning as before as soon as they were started.

"Doctor's Mine" is a torrent I'm the creator of. I have it set up so that the torrent points to a folder with symlinks rather than the actual files. I doubt this is a contributing factor though, as I have 323 torrents set up this way, 318 of which are working with no problems. I did repeat the process, pointing to the real file locations, just in case. The result was the same.

"Shane Hall" is one I simply snatched and the torrent points to the real file location, though this isn't the original download location. It was moved using qBittorrent's facility for this. Again, I have 177 other torrents moved in the same way that have no problems, so I feel it's safe to discount this as a factor.

Having said all that, I appreciate that you have 1001 other things to do and that this is trivial in the scheme of things. If it's an issue other members also start to report, that likely makes it worthwhile investigating further. If not, I'll just get over myself (or stick masking tape over the line that annoys me) so please don't feel the need to put in further effort.

My gratitude for those efforts thus far!

ianfontinell

@Joker said:

@Kevin4fm Dug into this properly, using "#helix" as the test case — nothing is broken on your end or ours; the message is literally true.

A torrent is identified by a fingerprint of its contents, not by its name. The "#helix" you're seeding carries the fingerprint of an earlier upload of that release which was later removed from the site (duplicate cleanups, re-uploads and the like happen all the time). The page you linked is a newer upload of the same release from June 2 — same name, different fingerprint.

Please, I have a few questions:

This fingerprint you mentioned, how does it differ from the torrent infohash?

I understand that you cannot rely solely on the infohash, otherwise a torrent that is removed and then reuploaded would already inherit the data from the previous... But in what scenario, or should I ask how, two torrents with the same infohash could be treated differently by the tracker?

If kevin has a torrent already added that's giving unregistered but have peers connecting and transferring bytes... Redownloading the newly added torrent and getting the same infohash means it is for all purposes a bytesize copy of the previous file.

You said that there's nothing broken on his side nor the tracker's, but where else could it be?

I have a different version of the same client, I don't get any error, so the logical first step would be for Kevin to try a different client to see if the outcome is the same.