Audio and video not downloading/working properly

[flleeppyy]

Audio and video not downloading/working properly

[BobbyWibowo]

You may want to consider starting lolisafe with SERVE_STATIC_QUICK=0 environment variable as well, to disable the implementation of establishing Readable stream for static assets of the front-end pages (JS/CSS files, logos, etc. - lolisafe will then instead pre-cache the files into memory)

It didn't seem like any front-end assets went wrong on your end, despite the implementation being identical with how it serves uploaded files

But you should probably do it anyways just in case

---

Do please let me know if you find out anything else of interest

Just leave this issue open

[samstarnes]

Hello @flleeppyy, it's me, the owner of 0x0. I have noticed this on my end. I'll be honest, I haven't updated my safe in quite some time but I'll be sure to try to upgrade soon and see if this fixes the problem. Currently on git commit 08db3e5 so it's rather old.

To replicate this I've noticed if I attempt to download a file and close the tab quickly but upon reopening the tab the download begins. Same error with "0 bytes/sec." Not sure what's causing it but haven't looked further into it. As for you, @BobbyWibowo, I'll try to pinpoint what's the deal is as well when I have the time.

[flleeppyy]

Yeah I am using cloudflare, but again it still happens without it, such as directly accessing it on the server via local host, or directly via ip

[BobbyWibowo]

Are you currently serving files with node? (i.e. serveFilesWithNode: true in config)

[flleeppyy]

Yes

[BobbyWibowo]

I have a linode server in Dallas, TX on their base tier (1GB Ram, 20gb storage), and some additional storage (80gb).

Is that additional storage some type of network storage? Only relevant if you configure your safe to store the uploaded files into it however

[flleeppyy]

Nope. Everything is stored on the windows server (The windows server is just a computer that sits in my closet).

[flleeppyy]

Files on the server seem to be intact, (Windows server on left, local copy of what i uploaded on the right)

[flleeppyy]

The linode server is only used for reverse proxying safe.fleepy.tv, to my windows server on the vpn

[flleeppyy]

I gotta head to bed, will respond later on this topic c:

[BobbyWibowo]

The only likely point of suspicion is the fact that if you serve uploaded files with node, the safe will establish a Readable stream to the physical file upon download

And it sounds like something in your setup is causing that to hiccup, somehow

Unfortunately, issue relating to this specific part of the code is very hard to debug, so I can't really say why it behaves that way on your end

You should probably consider serving uploaded files directly with Nginx or the likes instead

[flleeppyy]

I'm not sure what options are available to me...

[flleeppyy]

Well, it's something with lolisafe since I get the same issue when fetching the file from the server locally.

[BobbyWibowo]

The only likely point of suspicion is the fact that if you serve uploaded files with node, the safe will establish a Readable stream to the physical file upon download

And it sounds like something in your setup is causing that to hiccup, somehow

I wasn't pointing at your network setup by this, but the actual machine itself, as in how Node.js interacts with your physical disk

It doesn't surprise me that it behaves the same when fetching the files locally

[flleeppyy]

Alright well I figured out how IIS works, and now it's serving through https://safe.fleepy.tv/files

It seems to work fine for now.

[flleeppyy]

Later in the future I want to figure out why its serving like that incorrectly

[samstarnes]

Updated from 08db3e5 to 7f7f218.

The issue still exists under 7f7f218 if you save a file (something large to recreate this bug) then close the tab immediately. I chose something not too big but something I could download slow enough to quickly close the tab. Still got 0 bytes/sec but then eventually the file did download. I also re-encoded the video with the -movflags +faststart flags as well to place the MOOV atom file to the front of the video to see if that helped as well. Using Firefox 103.0.2 and tried Chrome 104.0.5112.102. This only happened in Firefox. In Chrome, the file downloaded file but gave no estimated time. The video continued to download and the size only increased as it continued to download more chunks.

I'm not sure if you're using CloudFlare,, @flleeppyy, but since I am the files are being transferred using chunked transfer encoding so the size can't be determined and a time can't be estimated. It finishes when it receives a terminating chunk message.

Now why this happens when you click the link, leave it open and it still chooses to stay at 0 bytes/sec in Firefox? Dunno. The only way to start the download seemed to be either a) reopen the link or b) skip through the video so it's past the point that's been loaded. Obviously won't work with things like archives other than reopening the links. This does not happen in Chrome at all so this appears to be a Firefox issue with chunked files.