Feature Request - Is there an easy way to migrate whole torrent collections?

[1DudeBud]

Hello friends,
I bring you a tale of n00b-ism.
First-off thank you for all of your great work, really appreciate the community, great times.

So my issue first happened when I was trying to migrate all of my seeding torrents from an old build to a newer faster server build.
I have hundreds of torrents seeding to the various communities. I was looking for an easy way to migrate the torrent file data. So thinking I was smart, I copied the .session data folder from the old directory tree to the new fresh install. This seems to work at first, all of my old torrents repopulated, however all of the trackers HATED me...
By doing this it created duplicate peer entries, which cause duplication errors on the trackers. The client freaked out by getting bad info from the tracker, crashed, and restarted and thus spraying even more bad data...
So yeah - an easy migration tool would be nice.
I'm currently passing all my torrents back to rutorrent/rtorrent a few at a time, a slow process however...
Thanks for your future support. :)

[kannibalox]

So thinking I was smart, I copied the .session data folder from the old directory tree to the new fresh install.

This is the correct way to migrate (assuming you shut down the old instance first), nothing wrong there. From rTorrent's point of view, it doesn't even know it's been migrated, it'll just immediately start using the data from whatever the session directory is set to.

By doing this it created duplicate peer entries, which cause duplication errors on the trackers.

There would need to be more details for a proper investigation, but if a tracker can't handle either a) ghost peers or b) announces from the same IP/port but different peer IDs, that's not something rTorrent can fix.

The client freaked out by getting bad info from the tracker, crashed, and restarted and thus spraying even more bad data...

I don't know of any way that a tracker's response can cause rTorrent to crash, but if so more details would be greatly appreciated. What exactly constitutes "bad info"?

[1DudeBud]

Some reason after the migrate my torrent client was continually re-announcing to the tracker, could it maybe have been a copy/duplication error? All of the trackers shut off my privilege's as it was detected that I had too many duplicate peer entries. I was shutoff from the trackers to protect the systems. Was told this was due to the client crashing or being killed, and restarting repeatedly and frequently. Each relaunch causes a new set of peer entries, which causes the duplication of the entries. I was up into the teens for each torrent! All I could see on my end was each torrent was rechecking.
The last few lines of the error log is below. - I'm just taking a guess, but it almost seems like it ran out of memory?

Caught SIGBUS, dumping stack:
rtorrent(+0x4195b) [0x563b80f4295b]
/lib/x86_64-linux-gnu/libc.so.6(+0x42520) [0x7f84e3253520]
/lib/x86_64-linux-gnu/libcrypto.so.3(+0x2fafad) [0x7f84e2f36fad]
/lib/x86_64-linux-gnu/libcrypto.so.3(SHA1_Update+0x128) [0x7f84e2e3ee08]
/usr/local/lib/libtorrent.so.22(+0x8d8aa) [0x7f84e37448aa]
/usr/local/lib/libtorrent.so.22(+0x8cc8c) [0x7f84e3743c8c]
/usr/local/lib/libtorrent.so.22(_ZN7torrent11thread_base10event_loopEPS0_+0x171) [0x7f84e372c551]
/lib/x86_64-linux-gnu/libc.so.6(+0x94ac3) [0x7f84e32a5ac3]
/lib/x86_64-linux-gnu/libc.so.6(+0x126850) [0x7f84e3337850]

Error: Success
Signal code '2': Non-existent physical address.
Fault address: 0x7f84d512f000
The fault address is not part of any chunk.

It dumped this info into a log, then restarted, continuing the cycle.

[1DudeBud]

Anyways, thought I should bring this issue forward...
The workaround seems to be to delete all of the .session data files and pass all of the .torrent back manually.
Seems to be stable doing it this way.

[rakshasa]

Should be possible to selectively delete session files, they are split up into multiple.

[1DudeBud]

Hello Raksahsa, maybe it is possible, however I have no idea what I should be looking for exactly. Seems there are hundreds of .torrent.rtorrent files and not knowing I just copied everything.
You did a great job building this tool - I've been using it for years, thank you. Seems that I hit my first major snag with rtorrent while trying to migrate. Therefore I suppose I am putting forth a feature request; an export file. Something simple that can be dropped into a new installation supporting a healthy migration from a previous build.

[kannibalox]

The session directory is that export you're looking for, I've used that method with thousands of torrents just fine. The problem you've encountered here is separate from export/import: your client kept crashing (as you mentioned, possibly from a storage error during rechecking) and announcing new peers to the tracker. That can happen even on instances where there was no migration.

The session file uses a simple format. Each torrent has three associated files, each starting with the torrent's info hash. .torrent is the original byte-for-byte torrent file, and .torrent.rtorrent and .torrent.libtorrent_resume contain all the data rTorrent needs to start the torrent back up again. It's probably a specific torrent causing this issue, so like rakshasa is saying you can restore/delete swaths of that at a time. For narrowing down issues like this, I find it's easiest to start with an empty session directory, and first move all the session files starting with 0 back in. If the issue doesn't occur, you can stop rtorrent and then move all the files start with 1 back in, etc, to track down the bad torrent more easily.