pmtiles-swarm 0.32.2 → 0.33.0

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
Files changed (2) hide show
  1. package/CHANGELOG.md +28 -0
  2. package/package.json +2 -2
package/CHANGELOG.md CHANGED
@@ -7,6 +7,34 @@
7
7
  ### 🐞 Bug fixes
8
8
  - _...Add new stuff here..._
9
9
 
10
+ ## 0.33.0
11
+ ### ✨ Features and improvements
12
+ - **Requires pmtiles-torrent 0.6.1, which is what finally makes a downloading archive servable.**
13
+ Two fixes there, both about the few kilobytes at the front of a PMTiles archive that say where
14
+ every other section begins. A read used to ask for its piece with a deadline and then raise on
15
+ libtorrent's immediate "I do not have that yet" — abandoning the very fetch it had just
16
+ requested, so each attempt gave up within milliseconds and left nothing behind to hurry the
17
+ piece. And the head was only ever asked for by a reader, so an archive nothing happened to read
18
+ was never prioritised at all. Reads now wait out their own timeout, and the head is prioritised
19
+ when the archive is added. On a 698 GiB mirror with two complete seeds connected this was the
20
+ difference between 200 GiB downloaded with no tile servable and a head that arrives in seconds.
21
+
22
+ ## 0.32.3
23
+ ### ✨ Features and improvements
24
+ - _...Add new stuff here..._
25
+
26
+ ### 🐞 Bug fixes
27
+ - **Requires pmtiles-torrent 0.5.2, which deletes a torrent's resume file with its data.** Resume
28
+ data was outliving the data it described: deleting an archive to re-fetch it left the record of
29
+ the old complete file behind, so the re-add handed libtorrent a description of a finished archive
30
+ against a path holding a fresh partial one. It answered `fastresume_rejected` and rechecked, and
31
+ until that settled nothing was verified — bytes arriving at full speed against a verified-piece
32
+ count stuck at 1, and every tile read told the piece it wanted was not in the slot list. Only when
33
+ the data goes too: a removal that keeps the files is how a pause is expressed for an engine with
34
+ no pause of its own, and discarding resume data there would turn every pause into a full re-hash.
35
+
36
+ - _...Add new stuff here..._
37
+
10
38
  ## 0.32.2
11
39
  ### ✨ Features and improvements
12
40
  - _...Add new stuff here..._
package/package.json CHANGED
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "pmtiles-swarm",
3
- "version": "0.32.2",
3
+ "version": "0.33.0",
4
4
  "description": "BitTorrent distribution for PMTiles map archives: create torrents, watch folders, publish and subscribe to RSS feeds, and seed through qBittorrent or an embedded client",
5
5
  "type": "module",
6
6
  "main": "src/index.js",
@@ -46,7 +46,7 @@
46
46
  "maplibre-gl": "^6.2.0",
47
47
  "parse-torrent": "^11.0.24",
48
48
  "pmtiles": "^4.4.1",
49
- "pmtiles-torrent": "^0.5.1",
49
+ "pmtiles-torrent": "^0.6.1",
50
50
  "webtorrent": "^3.0.21"
51
51
  },
52
52
  "engines": {