Release v0.2.34

server/internal/trickplay/bif.go

@@ -9,9 +9,11 @@
 // on a television. Read the first few kilobytes and every frame's byte range is known, so
 // showing one thumbnail costs a ranged request of about seven kilobytes rather than a
 // five-megabyte download nobody would wait for mid-seek. Emby answers ranged requests on
-// this route correctly, which it does not advertise: the response carries
-// "Accept-Ranges: none" and a Content-Length borrowed from the media file. Trust the 206,
-// not the headers.
+// this route correctly — measured against 4.10.0.21, which returns a 206 with
+// "Accept-Ranges: bytes" and a Content-Range naming the BIF's own length. Earlier builds
+// were reported to answer the range while advertising "Accept-Ranges: none", so callers
+// still trust the 206 rather than the headers and cap the read at what was asked for:
+// being wrong about that must not turn a press of Right into a multi-megabyte download.
 package trickplay
 
 import (