1. 18 Jul, 2021 1 commit
  2. 10 Jul, 2021 1 commit
  3. 26 Jun, 2021 2 commits
  4. 24 Jun, 2021 1 commit
    • Matt Whitlock's avatar
      respect file priority when selecting preview chunks · 852b0b4b
      Matt Whitlock authored
      Previously, ChunkSelector would select preview chunks ahead of all
      other chunks, regardless of file priority. This meant that files
      prioritized as "Last" would nevertheless have all of their preview
      chunks downloaded before all files prioritized as "First" or "Normal"
      had finished downloading. This contradicts user expectation, which is
      that scarce download bandwidth should not be devoted to files marked
      "Last" until all files prioritized as "First" and "Normal" have been
      completely downloaded.
      
      This commit splits the existing PREVIEW_PRIORITY level into three
      priority levels: FIRST_PREVIEW_PRIORITY, NORMAL_PREVIEW_PRIORITY, and
      LAST_PREVIEW_PRIORITY. Chunks that ChunkManager determines to be
      preview chunks have their priority levels boosted to the preview
      priority level corresponding to their respective base priority level.
      
      ChunkSelector's algorithm receives an overhaul that eliminates the
      temporary std::list objects in favor of remembering the best (highest
      priority, least number of downloaders) chunk during the iteration and
      selecting that chunk if no chunk at the same priority level but with
      no downloaders is found. The logic is ultimately equivalent to that
      implemented in leastPeers(…) but will run faster since it requires no
      heap allocations. Also, the new algorithm will not fail to select a
      chunk that already has downloaders if there are no chunks that have no
      downloaders. This should keep PieceDownloaders busier.
      852b0b4b
  5. 05 Jun, 2021 1 commit
  6. 18 May, 2021 2 commits
  7. 17 May, 2021 3 commits
  8. 13 Mar, 2021 1 commit
  9. 28 Jan, 2021 7 commits
  10. 04 Dec, 2020 1 commit
    • Melvin Vermeeren's avatar
      raise peer max metasize (torrent file) size to 100mib · ef43ebc8
      Melvin Vermeeren authored
      Perhaps the 4MiB metadata limit made sense when it was introduced years
      ago, but with modern storage devices easily being over 10TB more and
      more 1TB+ torrents can be found in the wild. These torrent files
      (metadata) are easily over 4MiB.
      
      This patch raises the limit to 100MiB. Raising the limit in the end only
      delays the problem for a few decades or so, as storage density only
      keeps increasing and files keep growing in size. A more permanent
      solution without arbitrary limits would be ideal.
      
      Fixes https://bugs.kde.org/show_bug.cgi?id=392202, where the reporter
      mentions Touhou Lossless Music Collection, which is a ~9MiB torrent for
      version 19 of the main part of the collection.
      
      Check initially introduced in c743f5e1.
      ef43ebc8
  11. 09 Nov, 2020 1 commit
  12. 08 Nov, 2020 4 commits
  13. 06 Nov, 2020 1 commit
  14. 03 Nov, 2020 4 commits
  15. 02 Nov, 2020 3 commits
  16. 01 Nov, 2020 7 commits