Watched data is cleared if a video that hasn't finished loading is closed.

[thecount 0]

Issue

If you're watching a video that has been partially watched, and you either close out by going back (let's say you clicked the wrong video and quickly go back to the home screen) or if the video fails to load (let's say the hdd the video is on has been disconnected), then the previous watch history will be cleared.

Steps to recreate

1) Find a video that has been watched and you're good with having its watch data cleared (or manually set some random video to a random watch position)

2) Play the video and quickly go back before the video loads (if you see a frame of the video before going back, it probably won't clear)

3) Notice that the video's watch data has been cleared. If you try this a few times, you'll probably see it clear.

Affected Clients that I've seen

-Web Client

-Android App

I found this in the web client, testing it in the android app causes the same issue (in that one, if you just spam the back button after loading the video, it'll do the same thing). I want to say I've seen this on the Apple TV app in the past, but I'm not positive.

Possible Underlying Issue

Messing around in dev tools on the web client, I found that the cause may be related to the /Playing and the /Playing/Stopped endpoints. When a video is first loaded in, I'm seeing that the values passed into PositionTicks is wrong. I've found that if it's wrong for either one, it'll cause the issue. Patching just one did not work for me. Oddly enough, I seemingly didn't need to patch the /Playing/Progress endpoint. May want to double check that, but I figured I'd toss that out there. 

For both endpoints, I've seen it randomly be 0.

For /Playing though, I've seen it be 0, some random small value (in one instance, I got 7400, which is impossibly small for ticks), and randomly it'll just be correct (for the logs I included, it has a correct value and and broken value, both obtained without my patch. Idk what causes the difference). My best guess is that the code is potentially grabbing the underlying video's currentTime, which is just 0 until the video is loaded in, and the difference may be a result of a race condition somehow. Examples of the endpoints getting 0

I intercepted these two calls using JS and updated the PositionTicks to be the correct value based on the metadata you guys fetch from the /Items endpoint before loading the video (It's made a bit before the video player loads).

And this seems to prevent this issue. Alternatively, you could make the two endpoints not update the watch data if the value is 0, although this won't fix the edge cases that I can't quite explain where the tick value is impossibly low. These would at least be fixes for the web client, I'm not sure what differences there are between the other clients.

 

embyserver.txt

[Abobader 3464]

Hello thecount,

** This is an auto reply **

Please wait for someone from staff support or our members to reply to you.

It's recommended to provide more info, as it explain in this thread:

Thank you.

Emby Team

[Luke 42078]

Hi, we're looking into this. Thanks for reporting.