Aperture - AI-Powered Recommendations for Emby

[graytinc 1]

That is my Emby library structure, but I did not create an access folder path in the Emby dashboard.

Thats my docker settings

[TheGru 164]

53 minutes ago, DaMoekster said:

Is anyone having the text field loose focus in the playlist section? The last couple of versions I have to click the textfield after every letter I type. I tested on multiple pc’s, phones and browsers. 

i know what you are experiencing, but can you provide a screenshot of the exact input to help me target a fix?

[TheGru 164]

Just now, TheGru said:

i know what you are experiencing, but can you provide a screenshot of the exact input to help me target a fix?

I found it!

[DaMoekster 5]

Just to be sure, it's every text field when creating a playlist. Thanks!

[TheGru 164]

1 minute ago, DaMoekster said:

Just to be sure, it's every text field when creating a playlist. Thanks!

yep its a debounce issue

[TheGru 164]

Aperture v0.6.4 Release Notes

Quick patch release to fix an annoying input bug in the New Playlist modal. Thank you @DaMoekster

---

Bug Fixes

Fixed: Input Fields Losing Focus in New Playlist Modal

When creating or editing a playlist, typing in any input field (Preferences, Playlist Name, Description) would cause the cursor to jump out of the field after each character. This made it impossible to type normally.

Root cause: The Section and AIButton helper components were defined inside the parent component, causing React to treat them as new components on every keystroke and unmount/remount the inputs.

Fix: Moved these components outside the parent function so they maintain stable references across renders.

---

Update Instructions

For Docker Users

# Pull the latest image
docker compose pull

# Restart with new version
docker compose up -d

---

Full Changelog

Bug Fixes:

• fix: input fields losing focus in playlist modal due to inline component definitions

[DaMoekster 5]

Yes, working!
Thanksfor the quick response @TheGru

[akacharos 35]

Can we decouple the Aperture <-> Emby server connection URL from the public facing Emby URL?
In my setup for example, Aperture connects to Emby locally via http://host.docker.internal:8096. But that breaking the "Open in Emby" links.

Edited January 21 by akacharos

[TheGru 164]

1 minute ago, akacharos said:

Can we decouple the Aperture <-> Emby server connection URL from the public facing Emby URL?
In my setup for example, Aperture connects to Emby locally via http://host.docker.internal:8096. But that breaking the "Open in Emby" links.

Use the actual IP address of your Emby server instead. It should work

[akacharos 35]

Maybe a few points for clarification. My Emby instance is currently publicly accessible via an HTTPS domain managed by a Caddy reverse proxy. When I enter this domain URL into the "Server URL" field in Aperture, everything works fine, including the "Open in Emby" links.

However, this configuration forces all communication between Aperture and Emby to travel over the internet—traveling from Aperture to the router, through my ISP, to a DNS resolver, and back through the router to Caddy. Ideally, Aperture and Emby should communicate locally to avoid the unnecessary overhead and latency of this NAT hairpinning/round trip.
That's why I suggested adding an optional "External Server URL"  field to be used specifically for constructing the "Open in Emby" links, while allowing the primary connection to remain local.

[TheGru 164]

2 hours ago, akacharos said:

Maybe a few points for clarification. My Emby instance is currently publicly accessible via an HTTPS domain managed by a Caddy reverse proxy. When I enter this domain URL into the "Server URL" field in Aperture, everything works fine, including the "Open in Emby" links.

However, this configuration forces all communication between Aperture and Emby to travel over the internet—traveling from Aperture to the router, through my ISP, to a DNS resolver, and back through the router to Caddy. Ideally, Aperture and Emby should communicate locally to avoid the unnecessary overhead and latency of this NAT hairpinning/round trip.
That's why I suggested adding an optional "External Server URL"  field to be used specifically for constructing the "Open in Emby" links, while allowing the primary connection to remain local.

Ahh now I understand the request

[graytinc 1]

I need help with folders, I have attached my current setup.

 

[GoldSpacer 11]

I ran into a maybe rare bug? I have an Emby user account that 2 users used, I split them up and renamed the original user from D to C, then named the new one D, this is because C mainly used the original account and I wanted to preserve their watch history. Syncing the users from the admin > users page shows the new names correctly, but the generate recommendations job and the build aperture libraries job show both users as D, and the library folders are both built as D. 

Does the database need to update the user names if the name changes via user sync?

[graytinc 1]

@TheGruAperture uses Linux container paths (/mnt/...) when talking to Emby, but Windows Emby cannot access these paths, causing library sync failures.

 

error from Emby on Windows

2026-01-21 20:15:00.069 Info LibraryStructureService-0HNINOE5FF6UA:00000002: http/1.1 POST http://10.10.10.3:8096/Library/VirtualFolders?name=Shows Admin Watches&collectionType=tvshows&paths=/mnt/ApertureLibraries/aperture-watching/Admin_9dce44c8e806446d9a982217b0d229d8&refreshLibrary=true. Source Ip: host10, UserAgent: node 
2026-01-21 20:15:00.070 Error LibraryStructureService-0HNINOE5FF6UA:00000002: Error processing request

 

[Raichi 4]

Just an update for easy installation in Unraid. 

Both applications are available now in the CA store. 

Aperture & Pgvector.

[FlameRed 2]

I hesitate to report this, but during the last day or so, I now see duplicates of two TV Series under Continue Watching. It is very strange as I have not seen duplicates under Continue Watching before. I am thinking it possibly a coincident with the installation of the latest release of Aperture but I am not sure. 

Just reporting it in-case others see it.

Very strange.

[TheGru 164]

3 hours ago, Raichi said:

Just an update for easy installation in Unraid. 

Both applications are available now in the CA store. 

Aperture & Pgvector.

WOW Awesome and thank you!

[TheGru 164]

12 hours ago, graytinc said:

@TheGruAperture uses Linux container paths (/mnt/...) when talking to Emby, but Windows Emby cannot access these paths, causing library sync failures.

 

error from Emby on Windows

2026-01-21 20:15:00.069 Info LibraryStructureService-0HNINOE5FF6UA:00000002: http/1.1 POST http://10.10.10.3:8096/Library/VirtualFolders?name=Shows Admin Watches&collectionType=tvshows&paths=/mnt/ApertureLibraries/aperture-watching/Admin_9dce44c8e806446d9a982217b0d229d8&refreshLibrary=true. Source Ip: host10, UserAgent: node 
2026-01-21 20:15:00.070 Error LibraryStructureService-0HNINOE5FF6UA:00000002: Error processing request

 

Can another Windows user who got up and running help out here? I am now bogged down on a work project but do not want to leave anyone hanging.

[TheGru 164]

12 hours ago, graytinc said:

@TheGruAperture uses Linux container paths (/mnt/...) when talking to Emby, but Windows Emby cannot access these paths, causing library sync failures.

 

error from Emby on Windows

2026-01-21 20:15:00.069 Info LibraryStructureService-0HNINOE5FF6UA:00000002: http/1.1 POST http://10.10.10.3:8096/Library/VirtualFolders?name=Shows Admin Watches&collectionType=tvshows&paths=/mnt/ApertureLibraries/aperture-watching/Admin_9dce44c8e806446d9a982217b0d229d8&refreshLibrary=true. Source Ip: host10, UserAgent: node 
2026-01-21 20:15:00.070 Error LibraryStructureService-0HNINOE5FF6UA:00000002: Error processing request

 

There is a really detailed Docker Compose file for Windows users. I know it works as I have gotten 2 other people and it was created as a result of those conversations. Have you reviewed it?

[DaMoekster 5]

13 hours ago, graytinc said:

@TheGruAperture uses Linux container paths (/mnt/...) when talking to Emby, but Windows Emby cannot access these paths, causing library sync failures.

 

error from Emby on Windows

2026-01-21 20:15:00.069 Info LibraryStructureService-0HNINOE5FF6UA:00000002: http/1.1 POST http://10.10.10.3:8096/Library/VirtualFolders?name=Shows Admin Watches&collectionType=tvshows&paths=/mnt/ApertureLibraries/aperture-watching/Admin_9dce44c8e806446d9a982217b0d229d8&refreshLibrary=true. Source Ip: host10, UserAgent: node 
2026-01-21 20:15:00.070 Error LibraryStructureService-0HNINOE5FF6UA:00000002: Error processing request

 

During the setup you need to tell aperture where you created the ApertureLibrary folder the way Emby sees it.
For example: I created a folder on my E:drive. This folder is readable and writable for emby.
So during the setup I filled in E:|ApertureLibraries\ in the library parth.
If you choose for Apterure to create strm files for your ai recommendations and top picks you can ignore the "media serverpath prefix" during setup.
Make sure you select strm for tvshows because tvshows are defaulted to create symlinks.
 

[Neminem 1701]

1 hour ago, FlameRed said:

I hesitate to report this, but during the last day or so, I now see duplicates of two TV Series under Continue Watching. It is very strange as I have not seen duplicates under Continue Watching before. I am thinking it possibly a coincident with the installation of the latest release of Aperture but I am not sure. 

Just reporting it in-case others see it.

Very strange.

No it not strange, its a know issue.

And today no one has found the solution.

Scroll through this post, and see why, then search the forum, and find more info.

[ebr 16421]

35 minutes ago, Neminem said:

And today no one has found the solution.

There will be one forthcoming.

[graytinc 1]

@DaMoeksterMy structure is like this 

Architecture Overview

Server A – OpenMediaVault (Linux, Docker)

• Runs Aperture inside a Docker container

• Hosts the media storage and exposes it via SMB

• The media share is bind-mounted into the Aperture container (e.g. /mnt)

• Aperture generates STRM files inside /mnt/ApertureLibraries

Server B – Windows 10 (Emby)

• Runs Emby Server natively

• Accesses the same media via SMB at: \\10.10.10.X\shared\movies

• Emby reads STRM files and resolves them correctly to source media

---

Working Behavior

• STRM playback functions correctly

• Emby can read/write to the SMB share

• Aperture correctly scans media and creates necessary Dashboards etc

• Path translation for media reading is correct

---

Failure Scenario

When running “Build Aperture Movie Libraries”, Aperture issues an Emby API request:

POST /Library/VirtualFolders paths=/mnt/ApertureLibraries/...

This request fails because:

• /mnt/ApertureLibraries/... is a Linux container path

• Emby runs on Windows and only understands Windows filesystem paths

• Emby cannot resolve or create directories using Linux-style paths

• Resulting in:

  2026-01-21 20:15:00.069 Info LibraryStructureService-0HNINOE5FF6UA:00000002: http/1.1 POST http://10.10.10.3:8096/Library/VirtualFolders?name=Shows Admin Watches&collectionType=tvshows&paths=/mnt/ApertureLibraries/aperture-watching/Admin_9dce44c8e806446d9a982217b0d229d8&refreshLibrary=true. Source Ip: host10, UserAgent: node 
  2026-01-21 20:15:00.070 Error LibraryStructureService-0HNINOE5FF6UA:00000002: Error processing request
  

[DaMoekster 5]

My guess (i'm no expert either, certainly now that there's openmediavault involved  ) is the following: 

Create two folders:
\\10.10.10.X\shared\ArpetureLibraries\
\\10.10.10.X\shared\ArpetureBackups\

In the yml add:
- //10.10.10.x/shared/ArpetureLibraries:/aperture-libraries
- //10.10.10.x/shared/ArpetureBackups:/backups

During setup fill in  \\10.10.10.x\shared\ArpetureLibraries where it asks for the Apteture Library Path.

Please note I'm note sure about the mapping in the yml (forward or backward slashes etc) , I needed TheGru's help wiith that myself two weeks ago.

Edited January 22 by DaMoekster

[graytinc 1]

Thank you @DaMoekster

The required directories are already defined as bind mounts in the Docker Compose configuration, using the recommended path prefix. Aperture has read/write access to these locations; however, because Emby is running on Windows, Aperture passes Linux container paths when attempting to create libraries via the Emby API. Since these paths are not valid in a Windows environment, Emby fails to process the request and returns an error.

At this stage, it is unclear whether this issue can be fully resolved through adjustments to the Docker Compose (.yml) file alone, and guidance on the appropriate configuration would be appreciated.

PS: I am also evaluating a migration of Emby to Docker in order to simplify path consistency and improve overall integration.