Audio and video not downloading/working properly
flleeppyy opened this issue · 17 comments
Hiya, I'm currently running my own instance of lolisafe, under a fork called Chensafe. No changes have been made to the codebase besides some api endpoints (ability to add bcrypt hash instead of setting password).
I'm having an issue with audio and video not properly downloading, where downloading it gets to a certain point, then stops, and just keeps trying to download but then fails.
Another issue is that audio playback is not in order. It'll basically skip back and forth when playing it in firefox.
C:\Users\Chen\Downloads>curl -o highlevel.mp3 https://safe.fleepy.tv/v0dNm0HZ.mp3
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
70 7989k 70 5619k 0 0 92711 0 0:01:28 0:01:02 0:00:26 10604
curl: (56) Failure when receiving data from the peer
Any ideas to what's happening here?
My current setup is a little... unusual than most people would set up their server.
I have a linode server in Dallas, TX on their base tier (1GB Ram, 20gb storage), and some additional storage (80gb). That runs a Wireguard VPN, of which I have quite a few devices on, and that includes my windows server (Windows Server 2022), which runs chensafe.
On the linode server, I have nginx to reverse proxy chensafe on port 8000 on the windows server.
Yes, very complicated i know. I can draw a diagram if needed.
My version of node is 16.16.0
My safe is hosted at https://safe.fleepy.tv
Also forgot to note that I uploaded my files through sharex but i still get the same problem with the files if i upload it through the web interface.
Are you currently serving files with node? (i.e. serveFilesWithNode: true in config)
Yes
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
Nope. Everything is stored on the windows server (The windows server is just a computer that sits in my closet).
Files on the server seem to be intact, (Windows server on left, local copy of what i uploaded on the right)
The linode server is only used for reverse proxying safe.fleepy.tv, to my windows server on the vpn
I gotta head to bed, will respond later on this topic c:
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
I'm not sure what options are available to me...
Well, it's something with lolisafe since I get the same issue when fetching the file from the server locally.
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
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.
Later in the future I want to figure out why its serving like that incorrectly
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
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.
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.
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