Community of Sexsoundlovers

Olaf155 wrote: 03 Jul 2026 16:21 I have the same problem. The problem unfortunately occurs with all browsers, also with firefox.

Muffe2003 wrote: 05 Jul 2026 15:40 Hello Admins,
Did you change something on the webpage? The behaviour of the embedded player changed?

I use iPad Safari to visit forum, and usually, when i listened to the embedded/Attached sounds I could adjust to which min of the sound I want to jump (adjustable slide).
Now I only get this life broadcast - and cannot properly listen without downloading the file first.

Did you change something?
80495155969__6AF18D9F-B2B2-45AC-845A-1242C7D65915.MOV

reissl wrote: 07 Jul 2026 14:27 I might be entirely wrong but I feel like file server of the forum stopped supporting partial file download or something in that area (maybe not sending some header), this might or might not be configurable. Some coding agent might take a look and tell.

reissl wrote: 07 Jul 2026 16:00 It does also reproduce in brave/linux (in addition to ipad/iphone).

GPT guesses when it works, it downloads file entirely, then seeks it (saw it worked on a very short file on iOS as well, switching from streaming mode to seekable content).

It thinks it is missing "HTTP 206 Partial Content" mode for files to become seekable in browser:

Spoiler

I tested Range requests against that URL. For Range: bytes=0-1, Range: bytes=1000000-1000001, Range: bytes=-2, and even an impossible range, the server always replied:

HTTP/1.1 200 OK
Content-Type: audio/mpeg
Transfer-Encoding: chunked
Content-Disposition: attachment; filename*=UTF-8''20190728090719-062.mp3

and sent the entire 36,298,989 byte file.

For browser seeking, it should reply something like:

HTTP/1.1 206 Partial Content
Accept-Ranges: bytes
Content-Range: bytes 1000000-1000001/36298989
Content-Length: 2
Content-Type: audio/mpeg

It does not send 206, Accept-Ranges, Content-Range, or a fixed Content-Length. It also streams through PHP/nginx as chunked output. That is exactly the kind of response that makes
Firefox/Linux and iOS treat audio as non-seekable.

I also checked the file locally with ffprobe: it parses as MP3, has duration about 4037.472s, size 36,298,989, and starts with a Xing VBR header. So this is not primarily a broken VBR-
duration/index issue.

Likely cause: the forum/download endpoint was changed or upgraded so PHP now streams the attachment directly and ignores Range. Headers show PHP/8.3.32, nginx, Plesk. A previous setup
may have let Apache/nginx serve the file directly, or used X-Sendfile / X-Accel-Redirect, which would have preserved range support.

Why Windows may “work”: it may fully download/cache the file first, or that player stack is more willing to fake seeking after enough data is buffered. It is not evidence that the HTTP
response is correct.

Server-side fix: make download/file.php support byte ranges, or better, hand the file off to nginx/Apache using X-Accel-Redirect / X-Sendfile so the web server handles ranges. For
mode=view, Content-Disposition: inline would also be more appropriate, but the range bug is the main reason seeking is broken.


---

• the exact 5-week change needs server-side logs/config/package history.

• I’m sure about the observed failure, not the exact cause of the server-side change.

What we proved:

Range: bytes=0-1

gets:

HTTP/1.1 200 OK
Transfer-Encoding: chunked
Content-Type: audio/mpeg

with the entire 36 MB file.

That is enough to explain non-seekable playback. A seekable browser audio response needs 206 Partial Content plus Content-Range/Content-Length.

phpBB does add useful context: this URL is not a static MP3 URL. It is phpBB’s attachment endpoint:

/ssl-forum/download/file.php?id=36061&mode=view

So nginx is not serving the MP3 directly. phpBB/PHP is authorizing the attachment and streaming it. That path currently ignores Range, including invalid ranges. That may be phpBB core
behavior, a lost local patch, an extension change, or a webserver/PHP change that moved delivery away from nginx/Apache static-file handling.

Most likely changes from 5 weeks ago:

1. phpBB was upgraded or patched, replacing a custom/range-aware attachment downloader.
2. PHP was upgraded or its handler changed, especially since the response shows PHP/8.3.32.
3. Plesk/nginx config changed and attachments are now PHP-streamed instead of webserver-offloaded.
4. A caching/proxy layer changed; response says X-Cache-Status: BYPASS, so this is not being served from a byte-range-capable cache.
5. Forum “secure downloads” / attachment protection was enabled or changed, forcing all attachment reads through PHP.

Preferred fix: after phpBB authorizes the attachment, hand the actual file to nginx/Apache with X-Accel-Redirect or X-Sendfile. Then the web server handles byte ranges correctly.

For nginx, conceptually:

location /_phpbb_files/ {
internal;
alias /path/to/phpbb/files/;
}

Then phpBB/custom attachment code sends:

header('Content-Type: audio/mpeg');
header('Content-Disposition: inline; filename*=UTF-8\'\''.rawurlencode($real_filename));
header('X-Accel-Redirect: /_phpbb_files/'.$physical_filename);
exit;

For Apache, use mod_xsendfile:

XSendFile On
XSendFilePath /path/to/phpbb/files

and PHP emits:

header('X-Sendfile: /path/to/phpbb/files/'.$physical_filename);

Alternative fix: implement HTTP range support in the PHP attachment streaming code. Minimum behavior:

header('Accept-Ranges: bytes');

$size = filesize($path);
$start = 0;
$end = $size - 1;
$status = 200;

if (isset($_SERVER['HTTP_RANGE']) &&
preg_match('/bytes=(\d*)-(\d*)/', $_SERVER['HTTP_RANGE'], $m)) {
if ($m[1] === '' && $m[2] !== '') {
$start = max(0, $size - (int) $m[2]);
} else {
$start = (int) $m[1];
if ($m[2] !== '') {
$end = min($end, (int) $m[2]);
}
}

if ($start > $end || $start >= $size) {
http_response_code(416);
header("Content-Range: bytes */$size");
exit;
}

$status = 206;
}

$length = $end - $start + 1;

http_response_code($status);
header('Content-Type: audio/mpeg');
header("Content-Length: $length");

if ($status === 206) {
header("Content-Range: bytes $start-$end/$size");
}

while (ob_get_level()) {
ob_end_clean();
}

$fp = fopen($path, 'rb');
fseek($fp, $start);

$remaining = $length;
while ($remaining > 0 && !feof($fp)) {
$chunk = fread($fp, min(8192, $remaining));
echo $chunk;
$remaining -= strlen($chunk);
flush();
}
exit;

But I’d prefer webserver offload over patching PHP streaming. It is faster, less fragile, and naturally supports ranges.

To find what changed, check these on the server:

grep -R "Content-Disposition" -n /path/to/phpbb | grep -i download
grep -R "X-Accel\\|X-Sendfile\\|Accept-Ranges\\|HTTP_RANGE" -n /path/to/phpbb
stat /path/to/phpbb/download/file.php

Also check package/config history around 5 weeks ago:

grep -i "php\\|nginx\\|plesk\\|phpbb" /var/log/apt/history.log*
grep -i "php\\|nginx\\|plesk\\|phpbb" /var/log/dpkg.log*

The key regression is not “browser removed MP3 seeking.” The endpoint no longer behaves like a byte-addressable media resource. Restoring 206 Partial Content handling should restore
seeking in Firefox/Linux and iOS.

(disclaimer - coding agents are good at diagnosing but average at fixing)