Content marked watched for auto-logoff

[adam1010 19]

Android TV -- this bug report comes from a discussion started here.

 

Scenario:

- I have the 30min auto-logoff feature enabled (to allow my TV to go to sleep if content was left paused)

- I'm watching a movie/TV show and have it paused near the end (say 96%)

- When the auto-logoff feature kicks in it will stop playback which will trigger Emby server to erroneously mark it as watched

 

The only available solution to this bug currently is to disable Emby from marking content as watched unless it's played through to 100%  (which is undesirable).

 

Proposed Solution:

Whenever playback is stopped, the event sent to the server should indicate if playback was stopped by the user or not (ie "user initiated"). If this value/flag is missing the server can treat the event as user-initiated (so that this feature can slowly be rolled out to all clients).

 

When the server receives a playback stopped event that was NOT user-initiated (such as due to the auto-logoff feature, or an idle timeout feature), the server will save the progress exactly as reported and not make any changes to the watched status (ie the server will only apply the automatic mark-as-watched feature when playback was stopped by the user).

 

 

 

[ebr 14902]

Hi.  As noted in that discussion, this is not a bug.  Everything is working as it is designed.

 

This is basically a feature request so I will move it there.

 

However, I do feel that your usage pattern is so rare that doing what you suggest is likely to create more complexity/problems than it solves.

[adam1010 19]

@@ebr You'll need elaborate on how this is not a bug.

 

I paused an episode at a spot X. I was not finished watching it. When I came back to my TV, there was no bookmark at spot X and the episode was marked as watched. How you could not see this as unintended behavior?

 

This use case does not only apply to auto-logoff, and will become even more frequent if a shorter auto-logoff period (or screensaver or idle timeout) is allowed. I'm sure you could see how a 5min setting would make this bug rear its ugly head more often.

[ebr 14902]

Because deciding if something is watched or not is subject to settings on the server and the current behavior is consistent with those settings.

[adam1010 19]

Yes, I agree the server is doing what it was programmed to do --- the problem is that the server is given bad/incomplete information: "hey server, the user just stopped playback a couple minutes from the end". That event causes the server to take an action that is not appropriate. Had the event said "hey server, playback stopped due to an idle timeout", the server would know not to mark the episode watched.

 

If you want to look at this another way, the "Resume Settings" on the server say "Titles are assumed fully played if stopped after this time". In this scenario, the user doesn't stop the title!! I understand that technically playback is being stopped under the hood when the client is idle, but as the user, I did NOT stop the title, and thus I do not expect the server to mark it as watched.

 

This isn't a bug in the sense that the software is doing something you didn't program it to do -- the programming is solid. It's a bug in the sense that the user is experiencing an undesirable outcome in certain situations. So I think the programming is just incomplete, and needs a little extra logic to handle this edge case.

[ebr 14902]

Had the event said "hey server, playback stopped due to an idle timeout", the server would know not to mark the episode watched.

 

I understand that is your opinion but I don't agree that the fact that the person didn't stop it themselves means it should always be treated differently.  The same amount of the item was watched either way and some people have a habit of never stopping playback manually.  They simply shut down the app or actually pause and turn off the TV.

 

But, that's why I moved this to a feature request.  You are requesting some new behavior so we will leave this  here and see what kind of community support it gets.

 

Thanks.

[adam1010 19]

Okay, so in the situations you mentioned, how would those users be adversely affected by this change (fix)?

 

A) User pauses playback and turns off their TV

User closes the app during playback

 

In both cases, how bad would it be if when the user returned to the app, the title was bookmarked at the place they left it? In my opinion it's much worse to mark a title Watched incorrectly than it is to sometimes start the show and realize you last paused it during the credits (which is easily remedied by skipping forward to advance to the next episode).  And if your argument is that it's not common for users to pause near the end then this won't adversely affect many users, it will just help power users like myself have confidence that they did in fact finish watching a title that the Emby says is watched... that's the whole point of recording the watch status --- it's what separates us from the animals :-)

[ebr 14902]

They would feel just as strongly as you do about the fact that they finished watching that item and it should not be cluttering up their "Continue Watching" list.

[adam1010 19]

Makes sense. I guess I'm more in the camp of: Better safe than sorry.

 

Let me re-frame the problem one last time and then I'll stop debating -- maybe @@Luke has an opinion since he's on the server side.

 

If you (the server) knew for a fact that a Playback Stopped event occurring near the end was NOT triggered by the user pressing the stop/exit button, would you still mark it as watched?

 

I think that's the fundamental question that decides if this is a default behavior or gets put behind a server configuration option. It's currently implemented in the code as "YES" and I obviously believe "NO" is more appropriate given the consequences.

[mastrmind11 717]

I can see both sides, but honestly if you watch something where the end timestamp falls within your "watched" threshold, then it should get marked as watch.  I could be entertaining friends, watch something until 96%, pause for some reason and forget.  I'd be annoyed to have to mark it as watched because I didn't watch the credits and my tv turned off... which is the alternate to your argument.  End of the day, it's a request that fits the need of a fraction of the userbase.  Netflix doesn't even do it, though it will show a completed bar under things marked watched in the event you want to watch credits roll.  

[adam1010 19]

@mastrmind11  Good point, I've really only experienced this problem with TV shows (as they often have very short or no credits at the end).

 

If we limited this to TV shows only, would that change your position? TV shows often put plot twists near the end to get you to tune in next week -- and if you're entertaining friends you probably won't be pausing the show prematurely long enough for the auto-logoff to trigger.

 

Addressing this would give users that confidence that regardless of where they pause a TV show, if they come back 5min later or 2 days later, they can resume it where they had paused it and not be erroneously guided into the next episode  (which I contend is what users already believe anyways).

[adam1010 19]

I decided to check if Netflix and Amazon Video have this same "bug" on Android TV... You'll be surprised to learn that they do NOT.

 

1) Netflix -- I was watching Black Mirror (S4E1) and paused in the scene right before the credits (1:13:35 / 1:16:38). I waited 5 minutes for my screensaver to kick in. When I closed the screensaver Netflix had NOT marked S4E1 watched and allowed me to resume at the exact spot I had paused it... amazing.

 

2) Amazon Video -- I was watching Electric Dreams (S1E5) and paused in the scene right before the credits (52:44 / 54:18). I waited 5 minutes for my screensaver to kick in. When I closed the screensaver Amazon had NOT marked S1E5 watched and allowed me to resume at the exact spot I had paused it... amazing.

 

So now that it's apparent Emby is in the minority here, can we consider addressing this? We can limit it to only TV shows (not live TV or movies).

[ebr 14902]

Because neither of those has the settings for resume points that we do.

 

This feature request is here in the right place and, if enough other people support it, we will consider it.

[awoodward0830 0]

I agree it should be fixed so it works like Netflix and I can expect to come back to paused content and resume where I left off. Worst case, it should be a configurable option to account for different people's viewing patterns. 

[ebr 14902]

I agree it should be fixed so it works like Netflix and I can expect to come back to paused content and resume where I left off. Worst case, it should be a configurable option to account for different people's viewing patterns. 

 

What, exactly should be fixed?

 

We already have the ability for you to come back and start watching where you left off and we already have configuration for exactly how you want this handled.

 

Are you having a specific problem?

[awoodward0830 0]

What, exactly should be fixed?

 

We already have the ability for you to come back and start watching where you left off and we already have configuration for exactly how you want this handled.

 

Are you having a specific problem?

 

Yeah, I am experiencing the same problem as adam1010 and I want to be able to pause at any point in a TV show and not have auto-logoff (or screensaver) mark it as watched. 

[ebr 14902]

Yeah, I am experiencing the same problem as adam1010 and I want to be able to pause at any point in a TV show and not have auto-logoff (or screensaver) mark it as watched. 

 

Then you can set your resume settings to 0 and 100 and the system will do that for you.

[adam1010 19]

Using 0/100 to disable the feature altogether is just a hack that doesn't address the real problem.

 

@@ebr Since it seems like you're going to fight this regardless of people showing support, can you just add a flag/parameter to the stop event that is triggered by auto-logoff?  ie Just inform the server that the stop event wasn't user initiated?  Then I can work with Luke on the server side to decide if an optional checkbox can be added to use that flag when deciding whether to enforce the Resume Settings.

 

Adding that flag won't change any behavior, it just adds metadata to make it available to the server.

[Luke 36999]

We're not actually trying to fight you on this. Like all feature request, we are actively monitoring this for community feedback. We will consider any change if community feedback points us in that direction.

[adam1010 19]

@@Luke I'm happy to write the server side code for this. But since the Android TV app is closed source I need to get that flag added to the stop event before I can do anything. I'm assuming you would approve a pull request for an off-by-default option that adds flexibility to the Resume Settings?

 

There was one supporter that commented today -- how many more people do you need to hear from? If I'm handling the server side then I'll probably just create a new thread that has a more limited scope to just including extra meta data in server stop events --- that should be less controversial.

[adam1010 19]

I've got some time this weekend to start on the server side code to support this (an off-by-default option to disregard Resume Settings when playback is stopped without user interaction).

 

@ebr  Are you willing to just add the metadata to that stop event on Android TV? It won't change the experience in any way, it'll just allow me to make different decisions on the server side.

 

Something like user_initiated: false   is all I'd need on that stop event triggered by auto-log off.  You do NOT need to put user_initiated: true on the other events -- I'll assume that it's true unless explicitly set to false.