Data inconsistency when sending files from Android to ESP32 over bluetooth

Question

I'm trying to send files (images) from an Android phone to a ESP32 board over bluetooth.

I'm using the ESP32-Bluetooth-FTP library which implements the OBEX protocol.

I added some lines of code in the part of the code where the file contents are received to save the contents to a local file, packet after packet:

            // Contains file contents
            else if (packet[i] == 0x48)
            {
                uint16_t head_len = packet[i + 1] * 256 + packet[i + 2];

                // MY OWN LINES
                if (out_file != NULL) {
                    fwrite(&packet[i+3], sizeof(char), head_len - 3, out_file);
                }
                // MY OWN LINES

                // printf("File contents : \n");
                // Just suming the file contents
                for (int j = i + 3; j < head_len + i; j++)
                {
                    file_sum += packet[j];
                    // printf("%c", packet[j]);
                }
                i += head_len;
            }

But unfortunately I always receive compromised data. To visualize this, I sent a blue bitmap file, and this is what the ESP32 received:

The glitch is very consistent. It's always green or red lines. Which indicates that the byte pattern has been shifted.

The lines are also exactly equal in length, which likely means that the data is always shifted from the beginning of a packet.

FF 00 FF 00 00 FF 00 00 FF 00 00 FF 00 00 FF 00 00 FF 00 00 FF 00 00 FF 00 00 FF 00 00 FF 00 00 FF 00 00 FF 00 00 FF 00 00 FF 00 00 FF 00 00 FF 00 00 FF 00 00 FF 00 00 FF 00 00 FF 00 00 FF 00 00 FF 00 00 FF 00 00 FF 00 00 FF 00 00 FF 00 00 FF 00 00 FF 00 00 FF 00 00 FF 00 00 FF 00 00 FF 00 00 FF 00 00 FF 00 00 FF 00 00 FF 00 00 FF 00 00 FF 00 00 FF 00 00 FF 00 00 FF 00 00 FF 00 00 FF 00 00 FF 00 00 FF 00 00 FF 00 00 FF 00 00 FF 00 00 FF 00 00 FF 00 00 FF 00 00 FF 00 00 FF 00 00 FF 00 00 FF 00 00 FF 00 00 FF 00 00 FF 00 00 FF 00 00 FF 00 00 FF 00 00 FF 00 00 FF 00 00 FF 00 00 FF 00 00 FF 00 00 FF 00 00 FF 00 00 FF 00 00 FF 00 00 FF 00 00 FF 00 00 FF 00 00 FF 00 00 FF 00 00 FF 00 00 FF 00 00 FF 00 00 FF 00 00 FF 00 00 FF 00 00 FF 00 00 FF 00 00 FF 00 00 FF 00 00 FF 00 00 FF 00 00 FF 00 00 FF 00 00 FF 00 00 FF 00 00 FF 00 00 FF 00 00 FF 00 00 FF 00 00 FF 00 00 FF 00 00 FF 00 00 FF 00 00 FF 00 00 FF 00 00 FF 00 00 FF 00 00 FF 00 00 FF 00 00 FF 00 00 FF 00 00 FF 00 00 FF 00 00 FF 00 00 FF 00 00 FF 00 00 FF 00 00 FF 00 00 FF 00 00 FF 00 00 FF 00 00 FF 00 00 FF 00 00 FF 00 00 FF 00 00 FF 00 00 FF 00 00 FF 00 00 FF 00 00 00 FF

Indeed, as can be seen, at one point the pattern breaks and there's one zero byte too few. And at the end of the glitch line there's an additional zero byte and the pattern recovers.

I have no idea where the error occurs, but it doesn't seem to be a data integrity issue, as all data consist of 0 bytes and FF bytes.

Maybe the error occurs at the receiving end. Is there a race condition? Could it be that writing the data delays interrupt service routines and then sometimes bytes are missed? fwrite is only called once per packet, so I would assume that the sender waits for confirmation before sending the next packet.

Or maybe there's a bug in the code that sometimes makes the index start at the wrong location. In some rare cases the corruption started in the bitmap header and then the file was unreadable.

I don't know if it could be related, but I was never able to send any file from my Windows 10 machine. But most likely Windows 10 uses different standards.

Any ideas where the cause of the problem is most likely to be found? What tests can I do?