-
Notifications
You must be signed in to change notification settings - Fork 30
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[BUG] Not scrobbling when letting episode run until the end #202
Comments
I have a plain MPV setup, and this case works just fine (scrobbles stop at 100%). I'll try to set up syncplay to see if it is doing something weird. |
I'm getting this more and more often, can trakt-scrobbler gain option to scrobble after playing media to certain percentage, like 85%? |
@soredake what media player are you using? |
@iamkroot mpv.net |
Maybe some issue with Windows? Would be difficult for me to reproduce. |
I don't think so, this happens only when playing with syncplay. |
This happened again, I've noticed that before changing the playlist item to next syncplay sets time to 00:00:00, that must be the reason why trakt-scrobbler is not sent finished state to trakt. Pinging the syncplay expert @Et0h |
That's a useful insight. The way Syncplay changes files at the end of the shared Syncplay playlist is a bit hacky as it was a feature added in later and designed to work using general commands supported by a variety of media players and with both the user and other users being able to trigger it, sometimes simultaneously. My recollection is that for legacy reasons the protocol treats setting playback position and changing playlist item as two separate events and I think the current code is the way it is to minimise the chance of the playlist being advanced twice due to advancement being double triggered (and to prevent playback position not being reset, but some still report problems with that when they manually change files). I can try to rework it when I have time but it will probably need a bit of testing to ensure it doesn't create new problems elsewhere (i.e. as it needs to maintain backwards and cross player compatibility). |
Maybe as a workaround here, we can add logic that a But I'm assuming |
I've made the changes here. Give it a shot
|
@iamkroot unfortunately, nothing changed for me, log:
|
That's a bit weird. I've pushed another fix for it, could you give it a try @soredake ? Same installation instructions as before. Would like to see the logs in case it doesn't work. |
@iamkroot even after this commit, I still got this:
This time, syncplay jumped to 00:00:00 at ~99.77%, so 100% might not work all the time. |
Wait, we don't even see the 99.97% event in our monitor. It directly goes from 0.16% back to 0% from our viewpoint. That's a big problem. We need to somehow keep polling the player for updates (I believe we already do that) and detect such big jumps. Gonna be harder than I thought, since we need to differentiate between syncplay initiated jumps and a user manually jumping to 0%. |
Describe the bug
When watching an episode using MPV and Syncplay it doesn't mark episodes as complete if the episode runs to 100% and automatically skips to the next episode. It only works if manually skipped.
Desktop (please complete the following information):
To Reproduce
Steps to reproduce the behavior:
--input-ipc-server=\\.\mpvsocket
in syncplay as "additional player argmuents", while I useipc_path: \\.\pipe\mpvsocket
in config.yaml from trakt-scrobblerLog file
Log from an example of where it DOES NOT work (automatic advance to next episode)
Log from an example of where it DOES work (manual advance to next episode)
The text was updated successfully, but these errors were encountered: