Design for "Remove From Continue Watching"

[OccamsChainsaw42]

Here is the write up of the current design we have for implementing this feature.

1. Add an entry to the item context menu for "Remove from Continue Watching"
2. Create a new boolean flag "ExcludedFromContinueWatching"
3. The command in the context menu will set the flag to true and save it to the database
4. Modify the query that sources Continue Watching to exclude entries with this flag.
5. When a user starts playing an object set the flag to false so the item can show again in Continue Watching

This seems pretty straight forward.

We have looked into how to implement this feature and have a few concerns:

• The flag needs to be store per user similar to lastPlayedDate, playbackPosition etc.
• So we would likely need a new column in the "UserDatas" table.
• Would this require the creation of a migration script?

It seems we would need to modify the "InternalItemsQuery" object to be able to include this flag.
I assume we would also need to modify the SqliteItemReposity class to modify the generation of the query.

An alternative to modifying InteralItemsQuery would be to separately get a list of guids that have the exclude flag for the current user
and include them in the "ExcludeItemIds" property of the query. This might be more straight forward if there is a way to do a more manual sql query to get the list of guids?

An alternative to the flag design as a whole would be to instead offer the user the option to reset the watch time.
This would remove the need to make any modifications to the database or query generation.
The advantage of the flag would be to keep the users current watch position but still exclude it.

[nathangur]

This path is a bit different from my implementation. I've gone down the route of simply removing the item from Continue Watching without resetting the user's position in the piece of media.

[nathangur]

I'm currently struggling with making the connection between the server and the web client as I'm getting some api errors.

[OccamsChainsaw42]

So the main method we've proposed of using a flag wouldn't affect the users position. Resetting the users position is an alternative method of removing it from continue watching since only items with some play time will be considered

[nathangur]

I see. If you are fine with it, I'd like to help you guy's with continuing your implementation. I don't think I can get mine to work in it's current state without some major changes

[BrennanWoodbury]

Sure thing, DM'd you on element.

[neopc10]

I'd love to see this extended to "Remove from Next Up" if there's an appetite for that.

[OccamsChainsaw42]

We went ahead and added this feature as well in a separate PR.

[nathangur]

@cvium Why did you reopen this discussion? Was there something you'd like to add?

[thornbill]

As I commented on one of the open PRs related to this:

Sorry if the process hasn't been clear. The Jellyfin team needs to be involved in the discussion to make sure the implementation aligns with best practices, etc. That is the main reason a discussion is needed first for changes of a larger scope or fundamental nature.

[nathangur]

Ah I see!

[JPVenson]

What is the benefit of this over just marking the item as played via the check icon?

[thornbill]

Now I'm second guessing if just resetting the watch status is "good enough". I tested some streaming services and they have the ability to remove items without losing the watch status. 🤷‍♂️

[JPVenson]

Well i would prefer not to build that much logic into the current system but maybe rethink it. The reset of the watch status would be easy to implement, get the job done and does not introduce more code then absolutely necessary.

[nathangur]

Another reason why we added a DB field is for having a timer to automatically remove items from continue watching after a certain period of time without changing the watch status. This is pretty highly requested, and people like to keep things clean without wiping where they left off. And, when you click the watched button, it adds it to next up, cluttering that when you are really just trying to clean up your library.

Little things like this that are just assumed to be good enough for the user just adds a little extra edge to the Jellyfin experience. At least in my opinion :)

[nathangur]

Back again to talk about this implementation. I've had a bunch of items that I want to exclude from continue watching or next up and have had to mark the whole thing as watched. It's genuinely quite annoying to deal with.

[JPVenson]

Well the server team discussed the current PR and the general idea. We like the idea and are overall very dissatisfied how the current next-up system works. We decided that any change to the current system just adds code to a complex system that needs a complete overhaul anyway. The idea is worthwhile but we dont want to change the existing code for now.

[spooksbit]

An alternative to the flag design as a whole would be to instead offer the user the option to reset the watch time.

This appears to be achievable right now by making a POST request to /Users/{userId}/Items/{itemId}/UserData with {"PlaybackPositionTicks": 0}. From my own testing, I am finding that items are being removed after making the request, but other fields appear to be retained (ie last played, play count, etc).

Would this be an acceptable solution?

[spooksbit]

My apologies if this has already been discussed, but what is the value proposition in retaining playback position after removing items from this list? This action seems to carry an explicit intent to forget where one has stopped playback, rather than an intent to retain playback position.

Comments from the feature request do not indicate this as a requirement either. To the contrary. resetting the playback position has been noted as "acceptable" behavior by some users and even desired by others. Maybe I'm the minority here, but it feels more like an anti-feature to retain playback position.

Is there maybe a different feature that is being implemented by requiring this behavior?

[nathangur]

My apologies if this has already been discussed, but what is the value proposition in retaining playback position after removing items from this list? This action seems to carry an explicit intent to forget where one has stopped playback, rather than an intent to retain playback position.

Comments from the feature request do not indicate this as a requirement either. To the contrary. resetting the playback position has been noted as "acceptable" behavior by some users and even desired by others. Maybe I'm the minority here, but it feels more like an anti-feature to retain playback position.

Actually I think the opposite is true. Currently you can mark an item as watched and that resets the playback position and marks it as watched. Then you can just uncheck it again to have it completely reset. However, the feature request wanted to retain the watch position but remove the item from continue watching or next up. This is especially useful for admins who play media for testing and have a lot of items on their front page, and if the PR's relating to this discussion had been accepted then a timer setting would have been proposed to remove items from either category after a period of time, similar to a feature Plex has.

Is there maybe a different feature that is being implemented by requiring this behavior?

The only thing that was planned was the timer. I personally would have used this (and am currently using it on my dev server) to keep things clean and uncluttered. Which is essentially what this feature aimed to accomplish, cleaning up the list of 100+ items from my continue watching category but not erasing the playback position. Is this a necessary feature? By all means no, but I am a firm believer that the little things that may seem insignificant or not useful actually add to the user experience. Even if a user never uses it, having the ability to do something solidifies the user experience.

And thus concludes my long winded, unneeded essay :)

[spooksbit]

However, the feature request wanted to retain the watch position but remove the item from continue watching or next up

Here are some comment excerpts from the feature request which seem to contradict this sentiment:

It would definitely be fine for the watched progress to be reset when it's removed.

If it can help or give ideas, [X] offers an option on items that have been partly watched to "reset resume time". I use it fairly often and it is a nice way to avoid the problem around changing the item's watched status

The "Continue Watching" just gets anoying and in the way if you cant remove stuff. I also like [X]'s option to reset resume time.

At the very least, it sounds like an option to reset playback position could be submitted as a feature request in the future.

In the case of testing media, wouldn't the retained playback position be the time that was chosen for testing purposes? If it is (and please correct me if I'm wrong), I would think it's desirable to discard that position instead of retaining it. If I was testing a movie and skipped to the middle to validate subtitles worked and removed it from the list, I would not want to be returned to that spot when I go to actually watch it later. From the comments, it sounds like usually the first few minutes of an item is used for testing which is not significantly different from the playback position of 0. If anything, I could see the option of resetting playback to 0 being presented as an enhancement by users to better support that specific use case since otherwise each item would play from some arbitrary point near the start and it would make sense to just reset the position.

Maybe I am the minority here, but retaining playback position sounds more like an annoying side effect and I feel would take away from user experience rather than add to it. It also seems that the proposed changes are at an impasse for legitimate concerns, but it also seems like those concerns are based on an implementation that is unnecessarily too strict. Instead, I think resetting the playback position relaxes the implementation in a way that not only eliminates the maintenance concerns but is also more desirable by users. Win-Win.

[nathangur]

I think you misunderstood what this implementation is. This is for an extra button in the action menu for an item. It's not replacing marking an item as watched.

[spooksbit]

I would not expect it to replace marking an item as watched? Clearing the position does not mark an item as watched so that button would continue to exist.

See: spooksbit/jellyfin-web@9cc592d

[jcreek]

Hi everyone, I'm a software engineer who's just moving to Jellyfin after all the recent Plex changes. I'm looking to get involved in contributing, and this issue seemed a good one to look at seeing as there's high community demand and ongoing discussion for the last few years on the best way to implement it to minimise technical debt and unnecessary complexity.

I'm summarising some key information below, please do correct me if I've misunderstood or misrepresented something:

• @westonhowe98’s original design introduced a per-user ExcludedFromContinueWatching flag in UserDatas to hide an item while preserving playback position.
• Several people noted the extra column/migration and the need to touch InternalItemsQuery/SqliteItemRepository, raising worries about adding complexity to an already-hairy part of the codebase.
• The server team summarised the hesitation clearly: any tweak to the current Resume / Next-Up pipeline “just adds code to a complex system that needs a complete overhaul anyway.”
• Others suggested simply resetting PlaybackPositionTicks to 0 via the existing user-data API as a quick-win, although opinions differ on whether losing the resume point is desirable.

I'd like to propose a middle-ground approach, where we store CW as a separate table. Instead of a suppression flag or wiping the resume point, Continue Watching could be an explicit per-user list:

Event	Action	Effect on CW
Playback passes MinResume%	UPSERT (UserId, ItemId) in UserContinueWatching	shows/bumps item
User hits “Remove from CW”	DELETE the row	disappears
Playback finishes (≥ MaxResume% or mark watched)	DELETE row	disappears
User starts item again	row auto-re-inserted	re-appears

This would address several of the concerns I've seen:

• Zero changes to UserDatas – this avoids the migration and wide-query edits flagged above. 
• No extra logic in InternalItemsQuery – ItemsController.GetResumeItems would become a simple SELECT from the new table, leaving the existing (admittedly gnarly) resume/next-up queries untouched.
• Keeps resume data intact for users who value it (per @nathangur’s point about admins/testing) while letting others still wipe progress by using the mark watched button if they prefer. 
• Aligns with the planned overhaul – moving CW into its own store is a clean first step toward decoupling all recommendation lists, something the team already wants to tackle, if I've understood the discussions correctly.

I anticipate this would have minimal impact on the server-side.

• Playback hooks (already fire in PlaybackManager) just call UpsertCW / RemoveCW.
  *A single new route POST /Users/{userId}/ContinueWatching/{itemId}/Remove deletes the row.
• Clients need only add one context-menu option; nothing else changes.

I’m happy to prototype this and open a draft PR so the team can see the diff size in real terms.

Does this feel like a worthwhile compromise, or are there blockers I’m overlooking? I'm also conscious that I've spent very little time in this codebase so I may be mis-interpreting or mis-remembering some of the current architecture or functionality.

Thanks for considering!

[barrelltitor]

Would be nice to just get the feature added already and not worry about adjacent issues. Jellyfin moves at a snails pace in general, more artificial waiting isn't good

[cvium]

I agree with your concerns but I think that discussing those changes would be better suited here for instance. My apologies if this sounds passive aggressive that isn't my intention

My concerns are with your implementation, not Ghost's design proposal.

It would be nice if you'd all stop piling on on something I never said.

[barrelltitor]

I didn't mean to add to the pile, its just that jf as a project moves very slowly. We've had 2 years of just CFcore. If the solution is not perfect but we never have a better one might as well go for the worse solution for now

[BrennanWoodbury]

Is it possible that we're letting perfect be the enemy of good? I don't mean to say we should push garbage, but this has been one of the most requested features for quite some time, and there's been no meaningful movement on this.

Nearly 3 years ago now, @OccamsChainsaw42 and I responded to this blog post by trying to do an initial implementation for this feature alongside @nathangur. It was ultimately shot down due to the implementation being too complicated, and the pending EF core migration. Migration is over and done with now, are we really going to continue to postpone this even further? There are people willing and able to do the work, but an imperfect implementation is yet again blocking progress to software that better serves the end user.

Again, this is one of the most requested features for Jellyfin to date.

This is not meant to be a personal attack on the maintainers, I have no doubt you all work very hard at a job that is almost entirely thankless -- but there seems to be a major disconnect here and something needs to change.

[cvium]

I do worry about the impact on the already-quite-poor Next Up query though. I'm also worried that people will remove a Series and forget and complain about CW/Next Up not working.

Instead of bemoaning the pace and accusing me of wanting a perfect implementation, you could respond to this in a non-handwavy way.

[goggybox]

Hi all, I wanted to return to this topic. I think @jcreek's proposal is reasonable, especially now that the rewrite to EFCore is done. I was hoping to get some feedback from @JPVenson or @thornbill on this approach, and whether you'd still prefer to hold off until more of the existing code is overhauled? This feature is pretty important to me personally (it's one of the reasons I'm still hesitant to fully migrate to Plex), so I'm happy to contribute wherever I can if you are open to draft PRs for this feature.

[JPVenson]

just as an FYI, we are currently pretty busy with the 12.0 release so feedback on this might not happen in the short term as its pretty involved

[jcreek]

I'm also still very happy to work on this 😄

[Soitora]

As a recent Plex migrant, this not being a feature already is honestly the one thing that keeps me from loving Jellyfin outright, happy to see that other people seem to agree. Now hopefully it can be closer to reality after v12 releases. 😊

The table posted by jcreek looks about right, it's an optimal way to handle the flags or db entries

[Shadowghost]

Just as a headsup #136 also includes a full implementation proposal for this feature alongside the rewritten watched tracking

[nathangur]

I see. I provided a implementation for this specific feature for CW and NU here: #50 (reply in thread)

I don't know if this implementation would fall in nicely with that proposed redesign so please take a look. Cheers