Problem with seeding after verifying data

Ask for help and report issues not specific to either the Mac OS X or GTK+ versions of Transmission
Post Reply
milenkovyua
Posts: 3
Joined: Wed Jan 04, 2017 10:06 pm

Problem with seeding after verifying data

Post by milenkovyua »

Hi there.

So I searched at the forum and in internet, but I never found an issue like mine.

Here is the situation.

I am using transmission-daemon to build a network of servers who are sharing files via the BitTorrent protocol. I decided to use transmission because it was the only program capable of seeding hundreds of files without problem. To be more clear on the system, a user is adding a file in the system to be shared with other users. At first the file is contained at only one server. a torrent is created and if other servers want to take the file, they will get the magnet link for downloading from the previous server. ( Every server run on CentOS 7 and uses transmission-daemon v 2.92-1.el7) After that they will add the link to their transmission-daemon client and the file will be downloaded on the other server too, where the user will be able to download it. (all of this because there are very poor connection conditions between the servers, and we want to make sure the file will be delivered even if the connection broke at some time). Everything work perfect until you try to verify the data at the first server (who created the torrent file and who keep the original file). The transmission-daemon do the verification and after that it seem to keep seeding the file (at least that's the status shown during the web interface), but if you try to add the file for downloading to another client, it just won't download anything until restart of the server. Of course we may hope that there are other clients to seed the file, but this is not necessary. On the other client I used uTorrent for testing (it show "connecting to peers"). it seems like transmission-daemon just stop seeding the file.

If you need more information, please ask and I will tell you what you want.

Thanks in advance
milenkovyua
Posts: 3
Joined: Wed Jan 04, 2017 10:06 pm

Re: Problem with seeding after verifying data

Post by milenkovyua »

Does it connect to the IP address of the server?
In uTorrent it doesn't connect with any IP address of any available peer. Not sure if the problem is in the tracker (which is a custom tracker btw), but I don't get any messages for any events in the tracker. The tracker is based on node.js and the module "bittorrent-tracker". All possible events are filled in with console.log to notify the event appeared, but nothing is called.
Does the problem persist over several announce cycles?
No, it appear after doing verification of the seeding torrent at the first client. I have tested to add the magnet link to uTorrent several times, 1, 2, 3 and so on, uTorrent always downloaded the file without any problems. Once a verification is done on the transmission-daemon at the main client who have the file and created the torrent, all other downloads are impossible. It seems to just stop seeding the file. It won't seed the file, at least until I restart the transmission-daemon.
milenkovyua
Posts: 3
Joined: Wed Jan 04, 2017 10:06 pm

Re: Problem with seeding after verifying data

Post by milenkovyua »

DHT and PEX are enabled. Both LPD and blocklists are disabled. The current test is on a local network, but the production environment is a WAN network, so LPD won't help a lot there.

DHT is enabled on the tracker too.

Encryption in settings.json is set to 1, but it is by default.

Right now everything work just fine. No problems at all. No matter how many times I do the verification of the local data, it seed the torrent to the other client without any problems. So I just can't answer some of your questions. But I hope this situation won't happen in production environment. It will cause a lot of problems and many systems depending on these files will stop working.

Could you please tell me how I can turn on the log files permanently when starting the service via "systemctl", so I can come with more information if the problem appear again, or at least try to solve it manually?
Post Reply