Photo download button doesn't respect library path.

[bryanlyon]

Describe the bug
Download fails to account correctly for correct library path.

To Reproduce
Steps to reproduce the behavior:

1. Create a library called "Photos" with a data path of /data/photos2
2. View a photo through the UI
3. Click the "download" button
4. File path given fails to download since it tries to download from path of 127.0.0.1:8000/photos/path instead of 127.0.0.1:8000/photos2/path

Expected behavior
File should be downloaded

Server (please complete the following information):

• QNAP NAS
• OS: QNAP QTS 5.0
• Architecture: X86

I'm not sure if this is because the library itself is called "Photos" (instead of "Photos2") or if it's looking to a hardcoded /data/photos location.

[cilynx]

I could be wrong as I'm just starting to explore this project, but it looks to be hard coded in settings.py. Those may be defaults that should be overridden by user settings, but that's a good place to start debugging.

[sammy-assistant]

Hi! I've looked into this and can confirm the issue.

The download_url property in the Photo model (photonix/photos/models.py) falls back to hardcoded values when the library's path store doesn't have a url set:

• library_url → /photos/
• library_path → /data/photos/

It then does base_file.path.replace(library_path, library_url) — but if your library uses a different path like /data/photos2, the replace doesn't match and the URL breaks.

As @cilynx noted, PHOTO_OUTPUT_DIRS in settings.py also hardcodes /data/photos. The proper fix would need to:

1. Derive the URL dynamically from the actual library path rather than using hardcoded fallbacks
2. Ensure the web server (Nginx) is configured to serve files from custom library paths

We're tracking this for a future fix. In the meantime, a workaround is to keep the default /data/photos path when creating libraries.