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

[Elcoid]

Info

git revision / version: commit 9c5fe43,
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]

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]

fixed by #100