Scan error if there is a jpg/png file in the folder

[pinkfloydFR]

I have a lot of error of this type when scanning ( mstream v5.13.1 docker ) :

2025-02-16T22:28:52.665Z error: File scan error: Warning: failed to add file /music/** - ***/03.mp3 to database: ENOENT: no such file or directory, open 'd41d8cd98f00b204e9800998ecf8427e.jpg'

Doing a lot of test and finally found the problem :
That 's not a name file or permission problem, it's my 'folder.jpg' which contains the album cover.

What i have done :

TEST 1 :

create a sub folder to isolate my collection with a problematic folder
duplicate it
running scan -> both folder give me scan error

TEST 2 :
deleted the folder.jpg in the second folder
running scan -> first folder give me scan error, the second is perfectly added

TEST 3 :
create a txt file named "1.jpg" in the second folder
running scan -> both folder give me scan error

Expected Behavior
No error with folder with jpg file in

Steps To Reproduce
create a new mstream docker
map a folder containing mp3 AND a jpg file in it
start the docker/scan

Environment

• OS: Ubuntu 24.04 server
  CPU architecture
  x86-64

Docker creation

---
services:
  mstream:
    image: lscr.io/linuxserver/mstream:latest
    container_name: mstream
    privileged: true
    environment:
      - PUID=1015
      - PGID=1015
      - TZ=Europe/Paris
    volumes:
      - ./config:/config
      - /mnt/zic_pic/_MUSIQUES:/music
    restart: unless-stopped

Thanks !

EDIT :

I confirm, writted a script to rename all .jpg to .jpg1 and .png to png1 in my entire library, no single error during initial scan

[l0rddarkf0rce]

Looks like a year later we still do not have a fix for this issue. I was about to create an issue about it.

[aroundmyroom]

try not to use the compress the image (functionality in the admin area you can disable), it could result in a 0 byte file and your md5 hasH of that image is referring to it.
when there is an issue with the file it indeed stops scanning etc..
Only a small change on scanner.mjs could fix that. So first you can try not to compress the image again.

or ..

if (originalFileBuffer) {
try {
await compressAlbumArt(originalFileBuffer, songInfo.aaFile);
} catch (err) {
console.error(Warning: failed to compress album art for ${songInfo.filePath}: ${err.message});
}
}
}

the catch(err) is added..

dunno if @IrosTheBeggar thinks its the correct solution.

[IrosTheBeggar]

This issues has been fixed in the latest version