hls.js: 10s -> 30s segment load cap (iPhone FragLoadTimeout)

The iPhone error 'Playback failed: FragLoadTimeout' + 74 all-200
segment requests = the phone's downlink can't deliver a ~700KB
segment within the 10s cap; hls.js measured the load client-side
while the server finished instantly. Raise maxLoadTimeMs to 30s
(first-byte 20s) so slow-but-alive phone links complete; retries
still bound the truly-dead case. assets v=11.

static/app.js

@@ -899,18 +899,19 @@ async function play(ep_id, ep_no) {
     // finish, and the proxy's retry path gets a chance
     // hls.js 1.5.x reads the retry budget from the errorRetry / timeoutRetry
     // sub-objects (a top-level maxNumRetry is ignored — that was the old bug).
-    //   maxTimeToFirstByteMs  first byte within 15s
+    //   maxTimeToFirstByteMs  first byte within 20s
-    //   maxLoadTimeMs         total load within 10s — finite cap, and LOWER than
+    //   maxLoadTimeMs         total load within 30s — covers SLOW CLIENT LINKS
-    //                         the first-byte cap, so a dribbling CDN segment is
+    //                         (a 700KB segment on a ~35KB/s phone link takes
-    //                         aborted at 10s and retried (timeoutRetry 6x) instead
+    //                         20s+; the old 10s cap made the iPhone FragLoadTime
-    //                         of the player staring at "Buffering…" for 30s
+    //                         out through all 6 retries even though every
+    //                         request 200'd server-side)
     //   timeoutRetry          retries for a load *timeout* (was default 1!)
     //   errorRetry            retries for HTTP errors like our proxy's 502
-    // Together: a slow/stalled CDN gets retried with backoff instead of one
+    // Together: a slow/stalled CDN or slow phone link gets retried with backoff
-    // shot -> fatal fragLoadTimeOut.
+    // instead of one shot -> fatal fragLoadTimeOut.
     hls = new Hls({ fragLoadPolicy: { default: {
-      maxTimeToFirstByteMs: 15000,
+      maxTimeToFirstByteMs: 20000,
-      maxLoadTimeMs: 10000,
+      maxLoadTimeMs: 30000,
       timeoutRetry: { maxNumRetry: 6, retryDelayMs: 1000, maxRetryDelayMs: 20000, backoff: "linear" },
       errorRetry:   { maxNumRetry: 8, retryDelayMs: 1000, maxRetryDelayMs: 20000, backoff: "linear" },
     } } });

static/index.html

@@ -6,7 +6,7 @@
 <title>ani-web</title>
 <link rel="icon" href="data:image/svg+xml,%3Csvg xmlns='http://www.w3.org/2000/svg' viewBox='0 0 64 64'%3E%3Crect width='64' height='64' rx='14' fill='%23f97316'/%3E%3Ctext x='32' y='45' font-family='sans-serif' font-size='42' font-weight='700' text-anchor='middle' fill='%230e0f13'%3Ea%3C/text%3E%3C/svg%3E">
 
-<link rel="stylesheet" href="style.css?v=10">
+<link rel="stylesheet" href="style.css?v=11">
 </head>
 <body>
 <header>
@@ -30,6 +30,6 @@
      max-age=300 in browser AND possibly in your HTTPS proxy, and a stale
      copy is exactly how users keep seeing an old UI after a deploy -->
 <script src="hls.min.js"></script>
-<script src="app.js?v=10"></script>
+<script src="app.js?v=11"></script>
 </body>
 </html>