Links not rewritten when #EXTINF out of order

[cunei]

Hello, thank you for your program! I am currently fighting with an HLS server that serves m3u8 lists like this one:

#EXTM3U
#EXT-X-VERSION:6
#EXT-X-TARGETDURATION:6
#EXT-X-MEDIA-SEQUENCE:20934918
#EXTINF:6.0000,
#EXT-X-PROGRAM-DATE-TIME:2022-12-22T05:58:45.714499+00:00
https://some.site.com/abc/xyz/1671688725.ts

When hls-proxy encounters this file the link ends up not being rewritten, possibly because it does not directly follow the #EXTINF line. If I create a test m3u8 in which these two lines are swapped, all works:

#EXT-X-PROGRAM-DATE-TIME:2022-12-22T05:58:45.714499+00:00
#EXTINF:6.0000,
https://some.site.com/abc/xyz/1671688725.ts

This is unfortunately preventing me from using hls-proxy, since all of the links in the proxied list remain unchanged. Thanks!

[warren-bank]

thought:

• major versions 1 and 2 of HLS Proxy would work for you in this situation.. since it uses a "dumb" parser that doesn't actually require that the structure of the manifest be correct

question:

• is this manifest correct?
  • if so, then I need to fix the new parser in the proxy
  • if not, then it's not a bug.. and an older version of the app is a perfectly acceptable fallback

example:

  npm install --global "@warren-bank/hls-proxy@v2.0.3"

[warren-bank]

shoot.. the intro to the spec describes the general structure, and it looks like this manifest is valid.. and my new parser is making assumptions that it shouldn't.. which actually makes its job harder than it needs to be.

sigh.. well, at the moment.. I'm deep in the weeds on a different project. But once I finish that.. I'll circle back to this one, and fix the parser.

sorry for the bug. I was worried that my recent complete rewrite would break something.. sure enough, it did.

[cunei]

major versions 1 and 2 of HLS Proxy would work for you in this situation.. since it uses a "dumb" parser that doesn't actually require that the structure of the manifest be correct

That is true. However, my playlist is something like "https://site.com/allTheLists?id=xyz", with no ".m3u8" suffix. The version 2 of HLS Proxy is seemingly unable to identify the result as an m3u8 list, while version 3 can check the additional suffix, and it works (but then it does not rewrite the links).

is this manifest correct?

Difficult to say, there isn't a single source of truth for all the variations of the format. I browsed RFC-8216 briefly, and I saw no indication that the #EXTINF tag has to come last.

it looks like this manifest is valid..

It seems so. :slightly_smiling_face: Thanks!!! :+1:

[warren-bank]

as a temporary workaround.. with v2 of the proxy.. you can append a hint to the video manifest's URL to let the proxy know what it's dealing with.. ex: https://site.com/allTheLists?id=xyz#video.m3u8

the hash will allow the regex pattern to match.. but servers will ignore it.

[cunei]

Nice hack! Thanks!!

[warren-bank]

v3.2.5 should work a lot better.. as the parser now follows the spec as it was written.. and doesn't make any added assumptions about manifest structure (as it incorrectly had done)

please let me know how it works for you.

also, a big thank you.. for reporting the bug!

[cunei]

Yes, everything is working fine now, at least in my use case. Thanks a lot for the quick fix, and have a great new year!! :-)