Por favor, forneça as seguintes informações
v4.1.6 oficial, Win-32
### Se estiver no linux, versão libtorrent e Qt
-
Alguns .torrents fornecem URLs para leeching.
O problema é: 'Remover semente da Web' não está funcionando em 'Fontes HTTP' desse torrent.
A URL desaparece da IU e do arquivo .fastresume, mas não é removida do arquivo .torrent. Portanto, o qbt tenta fazer o download dessa URL novamente após reiniciar o qbt.
Histórico: Se a URL do .torrent não estiver acessível, essas mensagens inundam o LOG, em até duas vezes por segundo. Se o LOG estiver habilitado na IU (para exibição), isso eventualmente bloqueará o qbt por 2 minutos no meu sistema.
Exclua o URL do arquivo .torrent.
Desculpe, atualmente não é possível fornecer um arquivo .torrent.
uma. Faça backport para 4.1.x, se possível.
b. Não foi possível encontrar nenhum outro problema como este no github, rastreando 13 páginas. Desculpe, se for um idiota.
Confirmo isso na libtorrent RC_1_2 bd0d01153641ffb1913f531b68c860b90efe0735
E também RC_1_1 84f10d05caff0d20213280951752797d166e1759
@arvidn
Suspeito que seja um bug no libtorrent.
Atualmente usamos read_resume_data()
para ler o fastresume e parece que o fastresume não está recebendo prioridade aqui, ou seja, se não houver um campo url-list
no fastresume, então não deve haver semente da web para o torrent.
não há campo de lista de url em fastresume, então não deve haver semente da web para o torrent.
É o comportamento esperado, IMO.
Será corrigido na próxima v4.2.0. (PR # 11104)
Comentários muito úteis
Confirmo isso na libtorrent RC_1_2 bd0d01153641ffb1913f531b68c860b90efe0735
E também RC_1_1 84f10d05caff0d20213280951752797d166e1759
@arvidn
Suspeito que seja um bug no libtorrent.
Atualmente usamos
read_resume_data()
para ler o fastresume e parece que o fastresume não está recebendo prioridade aqui, ou seja, se não houver um campourl-list
no fastresume, então não deve haver semente da web para o torrent.