AudioFormatReader from URL InputStream has no samples?

I’m trying to access a wav file on a server and create the appropriate AudioFormatReader from it. The reader is stored as a std::unique_ptr and it gets set up like so:

reader.reset (manager.createReaderFor (resourceUrl.createInputStream (juce::URL::InputStreamOptions
        .withConnectionTimeoutMs (1000)
        .withNumRedirectsToFollow (1))));

Checking the data members of the reader object confirms that the sample rate, channel layout, and number of samples all match the file as expected. But, calling read() to fill a buffer from the reader returns all zeroes, and calling readMaxLevels() shows that the max and min sample values are both zero.
Trying to locate the issue, I loaded the same file from a local disk into the reader like this:

reader.reset (manager.createReaderFor (localFile));

The reader’s metadata is again all correct, but with this the actual sample data can be read into a buffer without issue. Based on that I’m guessing that the issue is something to do with the InputStream being created from the URL. I’ve tried changing the arguments in withConnectionTimeoutMs and withNumRedirectsToFollow to no avail. Is there some other detail in the InputStreamOptions object that could be causing this? Otherwise, are there special considerations for accessing server audio files that I’ve overlooked? Any experience/insight much appreciated!

IIRC the AudioFormatReaders need seekable streams, which is not the case for a WebInputStream.
I’m afraid you have to download the file first and use it afterwards.

I checked the source, only the writer needs to seek backwards, but seeking forward when the file is not yet downloaded might also be a problem when reading, e.g.

The writer asserts in that case, but the reader silently ignores it (and seems to fail).

Thanks. Sure enough downloading the file locally and creating a reader for that file works fine. Does JUCE have any mechanism for creating seekable streams over network? I would think that streaming audio from a server is something people would run into fairly often.

Agreed, it was requested a few times, but it’s not there unfortunately.

I could see how to implement it with a normal download in the background, but proper RTP protocol would be the right thing to do.