Concern 1 — positional index re-introduces infohash collisions

The infohash is derived entirely from v2-${swarmId}-${type}-${index} (getStreamSwarmId → getStreamId → getStreamHash), so index is load-bearing for peer matching.

Pre-#509 used a positional index (levels.entries() → 0,1,2), and #509 ("standardize P2P stream identification via advanced metadata identifiers") deliberately replaced it with a content-derived hash (generateStreamShortId) so a given physical rendition always maps to the same infohash regardless of its position in the list.

This PR reverts to a positional index (sorted by the hash, but still positional). That makes the index a function of which other streams are present, not of the stream itself, which brings back two failure modes whenever two clients see a different set of streams:

• Same physical stream → different infohash (different position) → those peers never find each other.
• Different physical streams → same infohash (main-1 on client A is a different rendition than main-1 on client B) → they join the same swarm and exchange segments that don't belong together.

Under the current main (hash-as-index), neither can happen: stream H always maps to main-<hash(H)> no matter what else is in the manifest. See Concern 2 for the concrete trigger.

Concern 2 — Shaka/hls.js stream sets differ by OS/browser, so sorting doesn't keep indices aligned

The PR's premise is that sorting by sortKey keeps index order consistent between hls.js and Shaka. That only holds when both players see the identical set of streams with pairwise-equal sort keys. It breaks whenever the set differs, which is common in practice:

• Shaka filters variants by platform playability (MediaCapabilities / MediaSource.isTypeSupported / DRM) — a HEVC or Dolby rendition present on Safari/iOS may be absent on Chrome.
• hls.js exposes all manifest levels at parse time; Shaka may not.
• Muxed vs. demuxed audio handling differs (Shaka dedups audio across variants; hls.js lists audioTracks separately).

Worked example — renditions sorted H1<H2<H3<H4<H5:

H3 gets main-1 on Chrome but main-2 on Safari (split swarm), and main-1 means H3 on Chrome but H2 on Safari (cross-rendition collision). Drop a single stream and every index after it shifts — exactly what content-hashing avoids, since the hash for stream H is independent of which other streams are present.

The PR's goal (predictable infohashes for a private tracker) is legitimate, but the content hash already gives determinism the backend can reproduce server-side from manifest metadata — without sacrificing cross-player/cross-platform stability. If sequential integers are genuinely required, they should be derived from a player-independent source (declared manifest order / DASH Representation@id / HLS playlist URI), not from the per-client filtered+sorted set.

Do you have another idea? Running a private tracker is very important for PeerTube, because the trackers were overloaded by classic bittorrent clients (that support websocket protocol).

It can be an option that enables predictable infohashes so they can be easily reproduced on the server.

Added such options in #571