MindAR “RangeError: Extra N byte(s) found at buffer[1]” + “AR target element not found”
Problem
MindAR throws RangeError: Extra XXXX byte(s) found at buffer[1] when loading a .mind marker file. Additional logs show AR target element not found and a browser extension message-channel warning.
Environment
- A‑Frame: 1.4.0
- three.js: ^0.147.0
- mindar-image-aframe
- Marker path:
/media/markers/baby121/baby121.mind
Observed Logs (trimmed)
Valid MIND format detected: 88919 byte payload
Received 88927 bytes, Content-Type: application/octet-stream
Uncaught (in promise) RangeError: Extra 4167 of 4168 byte(s) found at buffer[1]
AR target element not found
Root Cause
MindAR validates the marker file length against its header. The served file contains extra bytes compared to the header (e.g., expected 88919, received 88927). This typically happens when:
- An edge/proxy (Cloudflare/Tunnel, etc.) compresses or rewrites binary files (gzip/brotli) or appends bytes.
- The file was uploaded in text mode (CRLF/BOM) or otherwise corrupted.
- The URL returns HTML or a partial/concatenated response instead of the raw binary.
AR target element not found is a separate DOM timing/selector issue: tracking starts before the <a-entity mindar-image-target> exists.
The message-channel warning usually comes from a browser extension and is unrelated.
Fixes
A) Serve .mind files as raw, uncompressed binary
Headers:
Content-Type: application/octet-stream- No
Content-Encoding (disable gzip/brotli)
- Avoid any response transformations.
Nginx
location /media/markers/ {
types { application/octet-stream mind; }
default_type application/octet-stream;
gzip off; # ensure no compression
add_header Cache-Control "public, max-age=31536000, immutable";
}
Apache
AddType application/octet-stream .mind
SetEnvIfNoCase Request_URI ".mind$" no-gzip=1
Header set Cache-Control "public, max-age=31536000, immutable"
Cloudflare/Proxy
Add a rule to bypass cache/transforms for *.mind or enforce Content-Encoding: identity at origin. Disable minify/compression for that path.
B) Verify served bytes match the source
Node quick check
const fs = require('fs');
const https = require('https');
const crypto = require('crypto');
// local file
const a = fs.readFileSync('./baby121.mind');
console.log('local', a.length, crypto.createHash('sha256').update(a).digest('hex'));
// remote file
https.get('https://your-domain/media/markers/baby121/baby121.mind', res => {
const chunks = [];
res.on('data', d => chunks.push(d));
res.on('end', () => {
const b = Buffer.concat(chunks);
console.log('remote', b.length, crypto.createHash('sha256').update(b).digest('hex'));
});
});
If lengths/hashes differ, the server/proxy is modifying the file. Fix config and/or re‑upload in binary mode.
C) If manually fetching, read as arrayBuffer()
const res = await fetch('/media/markers/baby121/baby121.mind', { cache: 'no-cache' });
const buf = await res.arrayBuffer(); // ✅ not res.text()
const blob = new Blob([buf], { type: 'application/octet-stream' });
const url = URL.createObjectURL(blob);
// Use `url` in MindAR config
D) Ensure the AR target exists before tracking
HTML skeleton
<a-scene mindar-image="imageTargetSrc: /media/markers/baby121/baby121.mind;"
vr-mode-ui="enabled: false"
device-orientation-permission-ui="enabled: true"
embedded>
<a-camera position="0 0 0" look-controls="enabled: false"></a-camera>
<a-entity id="ar-target" mindar-image-target="targetIndex: 0">
<a-entity gltf-model="#model" position="0 0 0" scale="0.2 0.2 0.2"></a-entity>
</a-entity>
</a-scene>
JS timing guard
const sceneEl = document.querySelector('a-scene');
sceneEl.addEventListener('loaded', () => {
const target = document.querySelector('#ar-target');
if (!target) {
console.warn('AR target element not found');
// Optionally create/append the target here
}
});
E) Re‑export marker if corrupted
If the on‑disk .mind already has the wrong size, regenerate it with MindAR CLI/Editor and upload again (binary mode). Avoid editing it in text editors.
What I tried
I set up an A-Frame (v1.4.0) + MindAR scene and served my marker file (baby121.mind) from /media/markers/baby121/. I also confirmed that the file was being fetched correctly by the browser and that it returned with Content-Type: application/octet-stream.
What I expected
I expected MindAR to load the .mind marker normally, initialize tracking, and then detect the target so I could attach my 3D model to it.
What actually happened
Instead, the console shows that the .mind file is detected but with mismatched byte sizes (e.g., “88927 bytes received” vs. “88919 payload”). This leads to RangeError: Extra XXXX byte(s) found at buffer[1]. At the same time, I also get AR target element not found. As a result, the AR experience never starts properly.
