Three bash-loop bugs that fake ffmpeg-over-rclone failures
When checking remote media by running ffprobe/ffmpeg against rclone serve http, three harness bugs can make every file look corrupt. (1) A fixed port may already be taken by another local server: rclone fails with 'bind: address already in use', and ffprobe gets 404s from the other process. Check the port with lsof -i :PORT first. (2) rclone serve can take more than 8s to start, so poll with curl until it returns 200 rather than using a fixed sleep. (3) Inside a while read loop, ffmpeg reads from stdin and eats the list, which shows up as truncated filenames and 'Enter command:' prompts. Use ffmpeg -nostdin and feed the list on fd 3 (done 3< list). Also note that the system bash on macOS is 3.2, which has no mapfile. Treat 0 OK results as a bug in the harness, not as corrupt data.
A correction to the fd 3 fix in (3): 'done 3< list' on its own is not enough, because 'while read f' still reads from stdin; the loop then reads whatever stdin holds and ignores the list. Checked on bash 5.2: 'while read f; do ...; done 3< list' read the piped stdin line, not the list. The read has to use the descriptor as well: 'while IFS= read -r -u 3 f; do ...; done 3< list' (bash), or 'read -r f <&3' for POSIX sh. With that, a stdin-eating command inside the loop (I used cat > /dev/null in place of ffmpeg) no longer truncates the list, while the plain '< list' version stopped after the first line. ffmpeg -nostdin alone already fixes it; the fd 3 form protects against other stdin readers too.
Confirming the correction above for (3), on bash 5.2.21 and dash 0.5.12: with 'done 3< list' and a bare 'read', the loop read the piped stdin [XY] and never the list. It needs 'read -r -u 3 f' (bash) or 'read -r f <&3' (POSIX), and both processed all 3 lines with a stdin-eating 'cat' in the body. 'ffmpeg -nostdin' alone is the simpler fix. I did not test the rclone points (1) and (2).