Custom Filename Schema not working

[mule632]

Hi again,

I just recreated my audiovault because I noticed my custom Filename Schema is not being applied however recreating it didn't work.

I can see the folder structure as my docker-compose-override.yml has these volumes (note the uid/gid setting doesn't work, it seems to ignore that and require the docker's running user permissions)...

volumes:
audiovault-cache:
driver: local
driver_opts:
type: none
o: bind,rw,uid=33,gid=33
device: /mnt/QNAP/Media/SharedMedia/Music_Audiovault/cache
audiovault-downloads:
driver: local
driver_opts:
type: none
o: bind,rw,uid=33,gid=33
device: /mnt/QNAP/Media/SharedMedia/Music_Audiovault/downloads

So in the folder, despite the Filename Schema setting, the title still containers {artist} - {title}

TBH I think it is just the file naming it's not happy about.

I tried to work around it by using picard to auto rename, but that confused audiovault which tried to redownload everything and ignored the renamed files.

[Bl4nk44]

Thanks for the detailed report confirmed, this is a real bug and a fix is on the way.

What happens: your schema is being applied (that's why the deezer/Magic Sword/ folders are correct), but the {title} tag was resolved by yt-dlp at download time. Since Deezer tracks are actually fetched through a YouTube fallback, {title} expanded to the raw YouTube video title e.g. Magic Sword A Dark Task (Official Audio) instead of the track title. That's also why some files (Hellfire.mp3) came out clean: those videos happened to be titled with just the song name.

Fix: schema tags ({artist}, {title}, {album}) now resolve from the track's own metadata (what you see in the app), with yt-dlp fields only as a fallback. Will land in the next release.

The uid=/gid= mount options are ignored by Docker for type: none bind mounts that's Docker behavior, not Audiovault.
Renaming files externally (Picard) breaks the link to the library DB, which is why Audiovault re-downloads them.

[Bl4nk44]

Fixed in v0.6.1 just released. Schema tags ({artist}, {title}, {album}) now resolve from the track's own metadata instead of the raw YouTube video title, so your {service}/{playlist}/{title} schema will work as expected. Please update to the latest image and let me know if anything still looks off.