search

majestrate / XD

meme bittorrent client
https://xd-torrent.github.io/
MIT License
233 stars 25 forks source link

XD takes a long time to start and its web UI looks broken during that time #99

Closed Elcoid closed 10 months ago

Elcoid commented 1 year ago

Info

git revision / version: commit 9c5fe43ad47ca9890680fbd02767fbfdfb6fa73c, Tue Mar 15 12:14:46 2022 -0400

OS: OpenBSD 7.2

Architecture: amd64

Problem

This version of XD used to work well before, but now it takes a very long time to start (but it's probably because I'm seeding more Linux ISOs than before). The main problem with this is that the web UI looks broken during the startup.

When XD is executed, the list of torrents seeding is visible in the web UI, but then disappears as soon as the I2P session is opened. I.e. from the beginning up to opening i2p session in the log, I can see my torrents in the web UI. But as soon as i2p session made, we are [...] appears, the web UI shows an empty list.

Then the hard drive becomes under heavy load while the log says checking local data for [...]. After a long time, I can see local data check done for [...], announcing to http://[...], and [...] is seeding appearing for one torrent at a time.

However, even when it says there are torrents seeding, the web UI shows an empty list. Only after 30 minutes, the list reappears and the hard drive is released from its torture.

Suggestions

  1. I think it would be clearer for the users if the torrents were still listed in the web UI, but showed as "checking local data" or something similar, to distinguish them from "downloading" and "seeding". The way things are right now, it looks like there is a problem with XD when it is starting.

  2. The sound made by the hard drive when the data is checked makes me think the program is reading several big files at the same time, because it sounds like the magnetic head is going back and forth very fast. I'm not a spinning disk expert, but it sounds like it's a kind of strain I would spare my disk from if I could. I think an option to check the files sequentially instead of concurrently would be useful. It would probably not hurt the performance that much because the CPU is always way faster than the disk anyway.

Elcoid commented 1 year ago

Hello! I learned Go and tried to implement my second suggestion above. By adding a mutex in lib/storage/fs.go and locking it during the execution of fsTorrent.VerifyAll, the data integrity check before seeding takes about 5 minutes instead of 30 minutes on my setup, and the hard drive is quiet. I will open a pull request for you to check it out!

majestrate commented 10 months ago

fixed by #100