Aperture - AI-Powered Recommendations for Emby

[TheGru 164]

My Wild Idea For Preventing Duplicate "Continue Watching" Entries

Hey everyone,

I want to get your feedback on a proposed solution to a common annoyance before I build it.

The Problem

When you watch a movie or show from an Aperture recommendation library, you might see duplicate entries in "Continue Watching" - one for the original item in your library, and one for the Aperture copy.

Why this happens

This happens because Emby links items together by their IMDB/TMDB IDs. When both the original and the Aperture STRM file share the same IDs, the media server treats them as related and syncs playback state between them.

The ideal fix would be for Emby to add a "Hide from Continue Watching" option per-library, so we could exclude Aperture libraries from that home row entirely. But until the devs add that feature, we need a workaround.

The Proposed Workaround (It's Workarounds All The Way Down)

Part 1: Fix the duplicates with prefixed IDs

Instead of using real provider IDs:

IMDB: tt1234567
TMDB: 12345

Aperture would write "prefixed" IDs in NFO files:

IMDB: aperture-tt1234567
TMDB: aperture-12345

Why this fixes duplicates:

• Emby sees aperture-tt1234567 and won't link it to the original tt1234567
• No more duplicate Continue Watching entries

But this creates a NEW problem: Now when you watch something from an Aperture library, the watch history doesn't track back to the original. The original item in your real library won't show as "watched" because Emby can't match the prefixed ID to anything.

---

Part 2: Fix the watch history problem with attribution sync

So we need a workaround for the workaround.

During the watch history sync job, Aperture would:

• Detect items with aperture- prefixed IDs that were played
• Strip the prefix to get the real IMDB/TMDB ID
• Find the original item in your library by that ID
• Mark the original as watched in Emby via API
• Record the watch history in Aperture's database

This way, your original library stays accurate - items you watch via Aperture recommendations still show as "watched" in your real Movies/TV library. It just happens on a delay (every 30 minutes) rather than instantly.

---

Alternative: Webhooks (real-time, but more setup)

I could make the watch history attribution happen in real-time using Emby webhooks. When playback ends, the media server would immediately notify Aperture, which could then mark the original as watched right away.

But this would require server admins to:

• Install the webhooks plugin (Emby)
• Set up the webhook URL pointing to Aperture
• Configure which events to send

That's a lot of extra work and configuration for users, and more stuff I do not want to provide support for, so I'm leaning toward the polling approach (30-minute sync) that works out of the box with zero additional setup.

Trade-offs

• ~30 minute delay before originals get marked as watched (sync runs every 30 min, you can adjust to your liking but this is what I would make my default)
• Requires Aperture library resync to Emby after enabling/disabling
• It's a workaround for a workaround - not elegant, but functional
• Would be an opt-in toggle in Admin Settings (disabled by default, labeled as "Experimental")

Questions for You

• Is duplicate Continue Watching actually bothering you? Or is this a non-issue for most people?

• Would you enable this feature? Even knowing it's a stack of workarounds with trade-offs?

• Any concerns or edge cases I'm not thinking of?

• Better ideas? If you know of a cleaner approach, I'm all ears.

---

Looking forward to your thoughts. If there's enough interest and no major red flags, I'll build it as an optional feature in an upcoming release.

[Jdiesel 1442]

18 minutes ago, TheGru said:

• Is duplicate Continue Watching actually bothering you? It bothers me but I'm a bit OCD. It also slightly bothers me that the Aperture library shows the filename instead of the "clean" name.

• Would you enable this feature? I would possibly setup a webhook to sync this but I don't mind mucking around with a more complex setup. I imagine most users won't.

• Any concerns or edge cases Nothing jumps out

• Better ideas? This is really a case of adding unneeded complexity for something that could (should) be addressed as a core Emby function. Not just for this app but for other uses cases like you previously mentions. Example: Having a separate HD and a 4K library where there are duplicate entries

IMO this is an excellent opportunity for Emby devs to demonstrate that they are 3rd party Dev friendly. We all know this won't be an issue on Jellyfin and it will be yet another reason to switch over to Jellyfin. 

Edited January 17 by Jdiesel

[TheGru 164]

8 minutes ago, Jdiesel said:

Is duplicate Continue Watching actually bothering you? It bothers me but I'm a bit OCD. It also slightly bothers me that the Aperture library shows the filename instead of the "clean" name.

What do you mean about FILENAME? can you send a screenshot? I am not experiencing that, nor should you be. I am literally ingesting 100% of the original metadata and outputting it in to the NFO files created by aperture. 

[Jdiesel 1442]

4 minutes ago, TheGru said:

What do you mean about FILENAME? can you send a screenshot? I am not experiencing that, nor should you be. I am literally ingesting 100% of the original metadata and outputting it in to the NFO files created by aperture. 

Aperture library

 

Emby library

 

[TheGru 164]

Got it... let me figure that one out.... but for the time being I am in mad scientist mode!!!

Testing: Prevent Duplicate "Continue Watching" Entries

I've pushed a test build that addresses the duplicate "Continue Watching" problem. Looking for feedback before merging to main.

The Problem

When you partially watch a movie from your Aperture recommendations library, it can appear twice in your "Continue Watching" row—once for the original and once for the Aperture copy. This happens because both items share the same IMDB/TMDB IDs, and Emby/Jellyfin links them together.

The Solution

This build adds an optional toggle in Settings → AI Recommendations → Output called "Prevent Duplicate Continue Watching". When enabled:

• Aperture prefixes provider IDs in NFO files (e.g., tt1234567 → aperture-tt1234567)
• This breaks the link between Aperture items and originals—no more duplicates
• A background job runs every 30 minutes to sync watch history back to your original library items

Trade-offs

• Up to 30-minute delay before the original is marked as watched
• You must rebuild your AI recommendation libraries after enabling/disabling
• This is a workaround, not a perfect solution

How to Test

image: ghcr.io/dgruhin-hrizn/aperture:continuewatching

After updating:

• Go to Settings → AI Recommendations → Output
• Enable "Prevent Duplicate Continue Watching"
• Rebuild your movie/series recommendation libraries
• Watch something partially and check your Continue Watching row

Feedback Wanted

• Does it solve the duplicate issue for you?
• Any unexpected behavior?
• Is 30 minutes acceptable, or should it be configurable?

This will remain experimental until we get broader testing. Thanks!

 

---

Edited January 17 by TheGru

[Jdiesel 1442]

I'm not seeing the option to rebuild the TV recommendations library 

[Jdiesel 1442]

11 minutes ago, TheGru said:

Got it... let me figure that one out.... but for the time being I am in mad scientist mode!!!

Testing: Prevent Duplicate "Continue Watching" Entries

I've pushed a test build that addresses the duplicate "Continue Watching" problem. Looking for feedback before merging to main.

The Problem

When you partially watch a movie from your Aperture recommendations library, it can appear twice in your "Continue Watching" row—once for the original and once for the Aperture copy. This happens because both items share the same IMDB/TMDB IDs, and Emby/Jellyfin links them together.

The Solution

This build adds an optional toggle in Settings → AI Recommendations → Output called "Prevent Duplicate Continue Watching". When enabled:

• Aperture prefixes provider IDs in NFO files (e.g., tt1234567 → aperture-tt1234567)
• This breaks the link between Aperture items and originals—no more duplicates
• A background job runs every 30 minutes to sync watch history back to your original library items

Trade-offs

• Up to 30-minute delay before the original is marked as watched
• You must rebuild your AI recommendation libraries after enabling/disabling
• This is a workaround, not a perfect solution

How to Test

image: ghcr.io/dgruhin-hrizn/aperture:continuewatching

After updating:

• Go to Settings → AI Recommendations → Output
• Enable "Prevent Duplicate Continue Watching"
• Rebuild your movie/series recommendation libraries
• Watch something partially and check your Continue Watching row

Feedback Wanted

• Does it solve the duplicate issue for you?
• Any unexpected behavior?
• Is 30 minutes acceptable, or should it be configurable?

This will remain experimental until we get broader testing. Thanks!

---

I'm now seeing three entries after playing a movie from the recommendations list. I'll wait 30 minutes and see what happens

 

[GoldSpacer 11]

I'll give this a try, configurable sync time would be cool, if it's not resource intensive I'd set mine to around 5 minutes. 

[GoldSpacer 11]

My experience so far with the continue watching is the AI movie picks don't have duplicates, but the AI show picks and top picks do have duplicates. This is after manually deleting all the movies and shows in the ApertureLibrary folder, regenerating the movie and show recommendations, and writing them back to the empty folders. Is the expected behavior for the Aperture library movie/show to be the only thing in continue watching until it is fully watched, then sync the fully watched status over to the emby library movie/show?

 

Also, custom models are sticking now but the custom embedding model isn't working still. The recommendation generation is working good though now with the custom model (qwen3:30b). This is the error I'm getting for the embedding generation:

6:42:27 PM Job failed: No embedding model configured or dimensions unknown

I'm attempting to use qwen3-embedding:8b and qwen3-embedding:4b for reference.

 

One other thing I noticed is the chapters and video preview thumbnails don't work on the aperture movies and shows. I have the video preview thumbnails set to not save in the media folders.

[TheGru 164]

What embedding size does it create? The issue I didn’t think of when I built that is to have you enter an embedding size to know which table to store the vectors in or it will fail. 

[TheGru 164]

2 hours ago, Jdiesel said:

I'm now seeing three entries after playing a movie from the recommendations list. I'll wait 30 minutes and see what happens

 

I built it fast and had to leave for an event. I’ll actually test things when I get home and see what’s what. Like I said super workaround attempt to make this work. 
 

if no good switch batch to :latest and rerun the jobs to sync the ai libraries to Emby and the top picks

[TeamB 2440]

2 hours ago, TheGru said:

The Problem

When you watch a movie or show from an Aperture recommendation library, you might see duplicate entries in "Continue Watching" - one for the original item in your library, and one for the Aperture copy.

This has always been a problem, if you add duplicate items in new "special" libraries (we have seen a few plugins that try to do this) then you will have duplicates.

The solution here is use playlists and have playlists better integrated into the dashboards of the clients so a playlist can be shown on home pages etc

[TheGru 164]

1 minute ago, TeamB said:

This has always been a problem, if you add duplicate items in new "special" libraries (we have seen a few plugins that try to do this) then you will have duplicates.

The solution here is use playlists and have playlists better integrated into the dashboards of the clients so a playlist can be shown on home pages etc

The answer is for the Emby devs to do the same thing they did to exclude libraries from global search, exclude from continue watching. 

[GoldSpacer 11]

9 minutes ago, TheGru said:

What embedding size does it create? The issue I didn’t think of when I built that is to have you enter an embedding size to know which table to store the vectors in or it will fail. 

Ollama library info says "Embedding Dimension: Up to 4096, supports user-defined output dimensions ranging from 32 to 4096". This is what I found on their blog here: https://qwenlm.github.io/blog/qwen3-embedding/

[TheGru 164]

1 minute ago, GoldSpacer said:

Ollama library info says "Embedding Dimension: Up to 4096, supports user-defined output dimensions ranging from 32 to 4096". This is what I found on their blog here: https://qwenlm.github.io/blog/qwen3-embedding/

I will add a dropdown selector to text embeddings custom model dialog with set sizes aperture supports. I will have to do a DB migration to support 4096 vectors. 

[Jdiesel 1442]

20 minutes ago, TeamB said:

This has always been a problem, if you add duplicate items in new "special" libraries (we have seen a few plugins that try to do this) then you will have duplicates.

The solution here is use playlists and have playlists better integrated into the dashboards of the clients so a playlist can be shown on home pages etc

This is maybe coming with the Smart Playlist feature? We can only speculate because it hasn't been communicated.

[TheGru 164]

49 minutes ago, TheGru said:

I will add a dropdown selector to text embeddings custom model dialog with set sizes aperture supports. I will have to do a DB migration to support 4096 vectors. 

When I implement this users will have to match the exact model to its exact embedding size in the table you provided. If it doesn’t match it won’t work. 

[TeamB 2440]

6 hours ago, TheGru said:

The answer is for the Emby devs to do the same thing they did to exclude libraries from global search, exclude from continue watching. 

I disagree, I don't think you should ever have to add a duplicate item to the system just so you can have it appear in a location or in a list you want.

the correct way would be to allow smart playlists, dynamic playlists or collections that can be added to home pages of client app to allow you to build a very dynamic customizable client platforms.

this has been talked about for literally years.

Edited January 18 by TeamB

[TheGru 164]

4 hours ago, TeamB said:

I disagree, I don't think you should ever have to add a duplicate item to the system just so you can have it appear in a location or in a list you want.

the correct way would be to allow smart playlists, dynamic playlists or collections that can be added to home pages of client app to allow you to build a very dynamic customizable client platforms.

this has been talked about for literally years.

Now I understand what you mean. Yes I agree. If this was something they would build out, I’d be more than happy to adapt Aperture to it!

Edited January 18 by TheGru

[ebr 16421]

15 hours ago, TheGru said:

• Aperture prefixes provider IDs in NFO files (e.g., tt1234567 → aperture-tt1234567)
• This breaks the link between Aperture items and originals—no more duplicates
• A background job runs every 30 minutes to sync watch history back to your original library items

IMO this is not really very useful unless it is in real time.  Also, this isn't just "watched".  The entire user-data object is involved (which includes resume points, watch count, favorite, etc.).  Have you covered that?

12 hours ago, TheGru said:

The answer is for the Emby devs to do the same thing they did to exclude libraries from global search, exclude from continue watching. 

We actually already have it but it is combined with "Latest" which is how you are getting your main lists onto the home page.

[TheGru 164]

22 minutes ago, ebr said:

IMO this is not really very useful unless it is in real time.  Also, this isn't just "watched".  The entire user-data object is involved (which includes resume points, watch count, favorite, etc.).  Have you covered that?

We actually already have it but it is combined with "Latest" which is how you are getting your main lists onto the home page.

I haven’t yet but I could, like I said I’m just trying to work around the current limitation of continue watching being tied to latest currently 

Edited January 18 by TheGru

[TheGru 164]

1 hour ago, ebr said:

IMO this is not really very useful unless it is in real time.

I could make it realtime using webhooks, but the question I have about the Webhooks plugin is it seems to add a notifications section but it is tied to a user, it does not seem to be a server wide configuration. I am just not understanding that correctly?

[TheGru 164]

@GoldSpacer @ebr @TeamB @JdieselI've decided to stop worrying about trying to manage deduplication. The juice just isn't worth the squeeze and tech debt I pick up trying to solve for it is not something I want to deal with long term. 

I am hopeful that the Emby devs may decide to decouple continue watching from latest on the home screen in a near term beta release which solves not just this but other related configurations that create duplicates in continue watching. 

Please switch back to :latest tagged builds as nothing new will be added to :continuewatching.

Thank you

[ebr 16421]

1 minute ago, TheGru said:

I've decided to stop worrying about trying to manage deduplication

I think that is prudent.

2 minutes ago, TheGru said:

I am hopeful that the Emby devs may decide to decouple continue watching from latest on the home screen in a near term beta release which solves not just this but other related configurations that create duplicates in continue watching.

I think it is more likely that future features will make it unnecessary for integrations like Aperture to create duplicates.  IOW - use proper constructs like playlists once we have the ability to show these on the home screen.

[Jdiesel 1442]

2 minutes ago, TheGru said:

@GoldSpacer @ebr @TeamB @JdieselI've decided to stop worrying about trying to manage deduplication. The juice just isn't worth the squeeze and tech debt I pick up trying to solve for it is not something I want to deal with long term. 

I am hopeful that the Emby devs may decide to decouple continue watching from latest on the home screen in a near term beta release which solves not just this but other related configurations that create duplicates in continue watching. 

Please switch back to :latest tagged builds as nothing new will be added to :continuewatching.

Thank you

That's understandable and from a maintenance standpoint, much easier for you in the long term. As @TeamB mentioned the true solution is to have the ability to "pin" playlists to the home row. Aperture would be able to create playlists rather that libraries with symlinks or strm files.