inputStream->isExhausted() never true

Hello,

I’m trying to be certain data from an input stream is completely loaded before passing it to a formatReader. The issue is that occasionally the reader will either, validate and pass back an only partially loaded file, or b, return false before the stream is completed. I have a relatively simple background thread which is handling the io, this causes the loop to jump back to the top and restart the download, even though it is 95% finished.

Perhaps I’m doing something wrong, but is it true that isExhausted() should definitely be true when the input stream is finished reading? Should the inputStream only be moving to the next block of code after it’s 100% complete?

I assume you are talking about a WebInputStream? You can easily check the source code in juce_core/native/juce_*_Network.cpp (where * is your platform mac, win,…) and see when isExhausted becomes true. For example, on mac this will only happen when finished is true - which in turn is only set if the stream has finished or an error has occured.

1 Like

Ahh I see now how the URL creates a WebInputStream and then returns it as an inputStream, but isExhausted() is a virtual function within the InputStream class.

Yes but isExhausted is overriden in the native code. You can find the overrides here:

OS X: Line 639 in JUCE/modules/juce_core/native/juce_mac_Network.mm
Win: Line 132 in JUCE/modules/juce_core/native/juce_win32_Network.cpp
Linux: Line 62 in JUCE/modules/juce_core/juce_curl_Network.cpp

It’s well possible that there may be an edge case with this implementation. As I said in my previous post, you’ll need to figure out why the isExhausted condition evaluates to true in your case. If you look at the OS X code above, for example, you’ll see it simply returns finished. If you search the same file for the variable finished you will find that it is only set to true if it has finished or if an error occurred. To find out more you could set a debugger breakpoint at the locations where finished is set to true. For example, on Mac OS X, it’s on lines 278, 506 and 655. Try setting a breakpoint at those lines.

1 Like

Hey Fabian,

Thanks for the tips, I saw the code you’re speaking of in the of the WebInputStream on Mac.

I’ve realized that what i believed to be my code re-downloading from the WebInputStream is actually from the AudioFormatReader->read() function.

It appears as though once that function is called it takes the same amount of time as the actual download to complete, seems similar to this post:

anyways, I’ve just been poking around with this as I can, will continue to work on it : ) Lemme know if that’s something you’ve run into before, otherwise thanks for the help!