Paul Webster wrote: > Comment from the RFC that I think is applicable - not that it will help > much since the world is as it is > https://www.rfc-editor.org/rfc/inline-errata/rfc8216.html > > "Compression: this media type does not employ compression." > > but the text says: > 6.2.1. General Server Responsibilities > ... > "HTTP servers SHOULD transfer text files -- such as Playlists and > WebVTT segments -- using the "gzip" Content-Encoding if the client > indicates that it is prepared to accept it." > > Edit: > and this seems to be relevant > https://www.martin-riedl.de/2018/09/12/gzip-compression-for-hls-playlists/
The real behaviour doesn't match the "standards" or comments. The real stupidity is (i) the savings (even with large m3u files) is v. small compared to audio and HTTP headers and (ii) why not compress every response. In this case it's not a hard hack to fix. Plugin expects first line to be "#EXTM3U" - if it is not then an error. The hack is , now if no "#EXTM3U" found, then unzip and then see if first line is "#EXTM3U". ------------------------------------------------------------------------ bpa's Profile: http://forums.slimdevices.com/member.php?userid=1806 View this thread: http://forums.slimdevices.com/showthread.php?t=103158 _______________________________________________ plugins mailing list plugins@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/plugins
