Arvid Norberg
Arvid Norberg
if you set the priority of file A to 0, that partial piece will be saved in the partfile, so I wouldn't expect that to be a problem on FAT32
libtorrent 2.0 defaults to using memory mapped files for disk I/O. This turned out to be sub-optimal in a lot of common cases (perhaps most cases). My top priority is...
> It would be better to do DHT development patches are welcome
I recognize that this is a problem. In fact, it's a problem in the libtorrent API as well. The `file_storage` class uses pad files internally to align files, even for...
It would also be simple to fix it for just the magnet link case, to make those indices disregard pad files, unconditionally. It would be a change in behaviour though
I'm not sure it's a good idea though. It makes it more complicated to predict the behaviour. Perhaps the specification for what &so= mean need to be updated.
the most reasonable way to address this, as far as I can see, would be to introduce a new index domain, along side the existing file index. So, in addition...
magnet links are more complicated. just because you have a v2 info-hash in the magnet link doesn't mean it's not a hybrid torrent. Likewise, just because you have a v1...
do you know which function you call from python that triggers this? It looks like something on an `alert` object that returns a string. Alerts don't behave like objects usually...
I don't think `alerts` will ever be `None`. It may be an empty list. That code looks correct, as long as: 1. the `log the alert`-part never saves an alert...