-
Notifications
You must be signed in to change notification settings - Fork 215
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
Sometimes before changing playlist item to next, time is set to 00:00:00 #683
Comments
It'd be useful to see Syncplay --debug logs showing the moment when Syncplay sends a command to mpv to set the position to 0 prematurely. This is because what is stated in the notification window might not reflect what is happening under the hood, and it is what is happening in the communication with mpv which is important to your issue. Specifically I am interested in if the problem that it resets to 0:00 before changing the file or that it pauses just before getting to EOF. |
I've added |
@Et0h here is the logs |
@soredake Thanks for sharing this. Is the relevant part of the log the following:
If so, what initiated the change of playlist. Was it because the other party manually changed the item, or was it auto-advancement? Also, any idea why there was such a 7 second gap between the seek at 14:44:47 and the change of file at 14:44:54? |
Yes, it is auto-advancement.
Maybe we loaded a youtube video, which takes some time to load. |
I just checked and it was a local mkv file. When at 14:44:47 it says that position was set to 0 by a specific user, was that the user whose log this is or a different user? On this person's computer, do seeks take sometimes take a long time? |
According to logs, it was my friend.
Loading files are definitely slower on my friend's side as he uses mpv.net which takes 1–3 seconds more to load files, at least on my machine, I'll advise him to switch to plain mpv. |
That's really helpful information - thanks. I think the issue might be that the way it works is that when you advance the first thing the client does is send a message saying the position should be 0 and the next thing it does it advance the playlist: |
I've made a lot of changes to how playlist advancement and switching works on my test branch. Please let me know if this fixes your issue and/or if it introduces new bugs. https://github.com/Syncplay/syncplay/actions/runs/9612802702 |
Testing this for 4 days, so far this problem is gone, will continue testing. |
Unfortunately, this problem is not yet fully gone, it still happens, thought not as frequent as before. Will post logs later. |
The test branch has now been updated to also merge in other unrelated changes to Syncplay. See: |
@Et0h with this build and month of testing, I don't experience this problem anymore. |
Describe the bug
Sometimes before changing playlist item to next, time is set to 00:00:00, which is breaks trakt-scrobbler because stop event is not happening on >=80% due to changed time
To Reproduce
Steps to reproduce the behavior:
Expected behavior
This should not happen ideally to not break trakt-scrobbler.
Screenshots
Not really needed.
Version and platform:
Additional context
iamkroot/trakt-scrobbler#202 (comment)
The text was updated successfully, but these errors were encountered: