Every Recording is played as live broadcast

[yeppie]

Did anybody of those experiencing this problem try using firefox as alternative browser? I would be interested if the problem still occurred.

[Olaf155]

I have the same problem. The problem unfortunately occurs with all browsers, also with firefox.

[yeppie]

I have the same problem. The problem unfortunately occurs with all browsers, also with firefox.

That´s an interesting reply, as you are the first one to report this happening on firefox. Would you tell us the rest of your configuration, device, os, ...?

[Olaf155]

I use an iPhone, iOS 26.2.1 - I‘ve just noticed there‘s a software update availiable. If it sorts out the problem, I‘ll let you know.

[Ilovesexsound]

Android here.
Still same issue with google Chrome.
But Mozilla works perfectly fine.

[Muffe2003]

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

[yeppie]

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

Hello Muffe2003, thanks for your report.
No changes made on the plugin. I moved your post to the topic where we already discuss the problem.

[reissl]

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.

[yeppie]

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.

Thanks reissl!
Wouldn´t that necessarily mean that all users would encounter the problem? For me it doesn´t happen (firefox on windows and android). And the archives (on the same server) seem not to be affected.

[reissl]

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)

[yeppie]

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)

Thanks a lot ... although I struggle to fully understand what you did

It helped me to find a few potential changes that have been made recently (like a phpbb update). The phpbb setting was necessary for security reasons but I will test some plesk settings when I got some time on my hands ...

[yeppie]

If anybody experiencing this problem could check if something in playing the sounds has changed, that would be great to know. I can´t test fully because I don´t experience the live broadcast problem. It does work for me not only with firefox but also with vivaldi and chrome.

[reissl]

Uh.. technically, you can right-click in any browser on any page with a sound player, open developer tools, go to network panel, clear all requests so it will be easy to find the right one, hit play, check headers/status code in that request's server response (should be HTTP 206 "here is part of the file", not HTTP 200 "I will send you entire file", I think).
If you want to give possibility to reproduce that request to your coding agent instead of giving it login/password, you can "copy as curl", and in clipboard there will be command line command to do request similar to what browser sends (can also show server's answer).

[yeppie]

Thank you again. What I get is a number of HTTP 200 codes. Will try more later.

[Madame Wu]

Madame Wu has same problem on Chrome. Sound is good, but no way to fast-forward.