search

BobbyWibowo / lolisafe

Blazing fast file uploader and awesome bunker written in node! 🚀
MIT License
317 stars 56 forks source link

Audio and video not downloading/working properly #566

Open flleeppyy opened 1 year ago

flleeppyy commented 1 year ago

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.

image

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.

BobbyWibowo commented 1 year ago

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

flleeppyy commented 1 year ago

Yes

BobbyWibowo commented 1 year ago

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 commented 1 year ago

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

flleeppyy commented 1 year ago

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

flleeppyy commented 1 year ago

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

flleeppyy commented 1 year ago

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

BobbyWibowo commented 1 year ago

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 commented 1 year ago

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

flleeppyy commented 1 year ago

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

BobbyWibowo commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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

BobbyWibowo commented 1 year ago

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 commented 1 year ago

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 08db3e55a82d1496ec1a1ed631c55318212ab7bf 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.

samstarnes commented 1 year ago

Updated from 08db3e55a82d1496ec1a1ed631c55318212ab7bf to 7f7f21862d8cf5a0e92ec78c6d9341b9cf9f835a.

The issue still exists under 7f7f21862d8cf5a0e92ec78c6d9341b9cf9f835a 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.

flleeppyy commented 1 year ago

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