I was still able to reproduce the problem with the latest version of
"ample" in Debian sid/unstable (0.5.7-7), so I had a look at the problem.
It became obvious quickly that the problem was related to some stripping
of the mp3 files (removal of the ID3v1 from the end of the file and
ID3v2 from the beginning of the file) that was taken into account during
the streaming, but not during the preparation of the HTTP response
headers. Unfortunately, with the current function structure that
information was not available at the time of sending the HTTP response
headers. So some refactoring had to be done.
The good new is that the rewriting of the code fixes two more problems
that had not yet been reported to Debian so far: 1. The interpretation
of the positioning information in the HTTP "Range" header was not
consistent with the offsets (stripping ID3 info). 2. Regardless the
"Range" information, ample always sent the complete file, not only the
requested range (although its response header suggested partial content).
Find attached the proposed patch. It may need some further testing, I'm
not familiar with real-world use cases, so after the fix-up I only
tested it according to theoretical specifications (using general-purpose
tools like curl, wget etc.). This testing only covers the single-file
delivery methods, but the main switch in the program tells me that there
are several others. They are not likely to be affected by this patch,
but if maybe someone has a real-world use-case ready, testing might be
worth it anyway...
Cheers,
Martin