Open florensie opened 2 years ago
Could you paste a backtrace of where exactly the crash happens? Also, if you're dual-booting with Linux, it'd be interesting to know if the same thing happens with the Linux version.
Any pointers on how I would get a backtrace?
Was there meant to be a stack trace logged by default? There wasn't, the program just exited after a good while. The log I posted is the entire thing.
Maybe interesting to note is that when I tried with SHA256 it got a bit further, but I haven't let it try to finish yet.
On Linux it also fails on 43, but it actually gives an error. I've redacted the file path:
\Videos\Some\Path\Recording.mp4: std::bad_alloc
Pretty sure it's running out of memory here. That file is just over 25 GB, and it looks like ntfs2btrfs is trying to load in the entire thing. I added a 30 GB swapfile and that seemed to work, but that's not really a good solution.
That's what it looks like to me... but it should only be reading in the file if it's compressed, and even then not the whole thing at once. Did it do it correctly? As in, if you do md5sum Recording.mp4
on btrfs then revert it and do the same for NTFS, do you get the same value?
Also, it'd help if you could install sleuthkit on Linux and paste the output of istat /dev/sdaX 43
, once you've reverted it. It might not be exactly 43, it might be a small number above that... whatever corresponds to Recording.mp4, anyway.
I haven't been able to complete it yet, because I'm hitting the issue described in #13.
Experiencing the same thing on raspberrypi 4 on bookworm. pi becomes unresponsive after memory and CPU shoot to 100%. For me it stops at 1.7%. Pi needs a hard reset when that happens.
I have tried mutiple times and it always crashes at 43. Also I have very high memory usage in this step, it's using all 16GB of RAM and a lot in the pagefile as well.