V1.7.16, local station. After exactly 2 minutes, my photos disappear from the view and I get this in the console (see below). This is valid for Cordova and Web.
I cannot confirm the behavior in my production deployment since I cannot deploy to Heroku.

@paulincai
Happens in a browser as well as Cordova (installed App)
I am not sure if this is what you are asking, the error was shown from Chrome dev console
No server errors. This just looks like a disconnection from files not from the server. The server shows me if a client gets disconnected but I am not disconnected, I just loose touch with the files.
Below, first is IOS, then Android then Chrome Web on the same station
In IOS you can see out of 4 images, the second (in black not red) is with Cached on Yes. That is the one that remains on the screen "forever" as expected.


@dr-dimitru something worth mentioning, I haven't done the changes to code, as mentioned in your comments of the last version. This is my code that was working in 1.7.14 with the package update at 1.7.16.
I am catching up now with the changes you suggested and will test again.
debug, to check if request for image(s) reached Server?Btw,
1.7.15 first time Npm.require changed to require1.7.16 require changed back to Npm.require, due to #4171.7.14 and 1.7.16 should be the same in terms of file upload and file servingDon't really know what was in my mind when I sent you files with no meaning :). Here we go:
The first screen shows failure after 2 minutes

the next 3 shots with specific names shows the same browser, just refreshed with a different behavior, at time will just bring only 2 files instead of 4. First 2 files are pending for almost 2 minutes then they show and the other 2 files are disconnected. After another almost 2 minutes those 2 files get disconnected too.



Lastly, the server console shows the following on refresh ( download of images) and nothing else when they disappear.

I would like to see headers of any failed file.
Speaking of error - it's obvious, somewhy size of the file differs from what mentioned in headers.
integrityCheck: true on FilesCollection ConstructorOther thought - somewhy middleware didn't catch the request and returns HTML as in #418 and #412
Ok, sorry for Are files stored on FS locally or at AWS:S3? question, so if requests is piped to AWS:S3 and Content-Length is mismatch - S3 somehow changed the files.
Could you post your interceptDownload? If you're using code from this tutorial compare file size in this.httpResponse.headers and fileRef.versions[version], does it differs?
Testing now with the config in the tutorial. Get back to you in 2 min
While re-writing this area of the code I understood the parts in the 'new' intercept which are closely related to my disconnection. What I suspected, but with no scientific reasons was that my preview file is being replaced by my original file. DB records show good, no issues to suspect in that area. However, as I am writing, it's been 5 minute and the "streaming" is going on. I think we are perfectly fine now. Will give it 10 more minutes and then we can close the matter.
Incredibly fast, no words to describe... love and thanks for looking all day over all these useless screen shots I've been sending to you ...
I'll be focusing on Heroku now
Great, see you at #420
Most helpful comment
While re-writing this area of the code I understood the parts in the 'new' intercept which are closely related to my disconnection. What I suspected, but with no scientific reasons was that my preview file is being replaced by my original file. DB records show good, no issues to suspect in that area. However, as I am writing, it's been 5 minute and the "streaming" is going on. I think we are perfectly fine now. Will give it 10 more minutes and then we can close the matter.