quietvoid

> I was mentioning it only because there are similar field names (but not positioned at the same place), I guess that some parts are common. BTW, if someone has...

There are issues with distributing binaries with `glibc`, such as different versions across distributions. For example, I couldn't reuse a build made on Arch on a Debian 10 machine. So...

Ah, I hadn't seen #26. I do think the byte-per-byte loop is the issue for performance. I'll comment more on the issue itself.

@casey I guess 0.1.8 fixes this? The performance difference is much lower. Unless tests are required first.

I've tried replacing the SHA1 loop and the performance improved a lot. >master 27,83s user 0,44s system 99% cpu 28,300 total Info Hash 88ea2b80ae3dba07ee1c1fa89a10f395809e612a Piece Size 4 MiB Piece Count...

I don't think overshooting is possible, you either read the entire buffer length or whatever's left until the EOF, which is necessarily lower than the piece length. I did edit...

I hadn't considered the multiple files situation, then you'd have to handle different buffer sizes depending on the previously read bytes (which seems to be what was done in #442)....

> > The hashing rate is always stuck to 953 MB/s (Arch machine) or 476 MB/s (Debian machine), I haven't looked further at the code but it's something worth fixing....

By the way, I have played with different ways to increment the progress bar but the result is always the same. Probably something upstream in `indicatif` that loses precision when...

> On an OLED display, the un-altered image would look too bright. Yes, but wouldn't it be intended to be that luminance as coded in the content? PQ is absolute...