Sometimes before changing playlist item to next, time is set to 00:00:00

[soredake]

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:

1. Add multiple playlist items
2. Play it to the end
3. Sometimes before changing playlist item to next, time is set to 00:00:00
4. trakt-scrobbler will not see stop event, due time changeed to 00:00:00

Expected behavior
This should not happen ideally to not break trakt-scrobbler.

Screenshots
Not really needed.

Version and platform:

• OS: Windows 11 Pro
• Syncplay version and build type: Syncplay 1.7.3
• Media player and version: mpv-git

Additional context
iamkroot/trakt-scrobbler#202 (comment)

[Et0h]

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.

[soredake]

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.

I've added --debug argument to syncplay, will send logs when this will happen again.

[soredake]

@Et0h here is the logs
syncplay_beginning_rewind.log

[Et0h]

@soredake Thanks for sharing this. Is the relevant part of the log the following:

[14:44:47] client/server << {"State": {"ping": {"latencyCalculation": 1718106278.1668386, "serverRtt": 0.04249072074890137, "clientLatencyCalculation": 1718106287.283412}, "playstate": {"position": 0, "paused": true, "doSeek": true, "setBy": "UserA"}, "ignoringOnTheFly": {"server": 1}}}
[14:44:47] Setting position to 0.0...
[14:44:54] client/server << {"Set": {"user": {"UserA": {"room": {"name": "***"}, "file": {"name": "***.mkv", "duration": ***, "size": ***}}}}}
[14:44:55] client/server << {"Set": {"playlistIndex": {"user": "***", "index": 3}}}
[14:44:57] client/server << {"Set": {"user": {"UserB": {"room": {"name": "***"}, "file": {"name": "***.mkv", "duration": 1420.132, "size": 1446057021}}}}}

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?

[soredake]

or was it auto-advancement

Yes, it is 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?

Maybe we loaded a youtube video, which takes some time to load.

[Et0h]

or was it auto-advancement

Yes, it is 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?

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?

[soredake]

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?

According to logs, it was my friend.

do seeks take sometimes take a long time?

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.

[Et0h]

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:

https://github.com/Syncplay/syncplay/blob/fix_missing_rewind/syncplay/client.py#L2074-L2076

https://github.com/Syncplay/syncplay/blob/fix_missing_rewind/syncplay/client.py#L256-L260

[Et0h]

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

[soredake]

Testing this for 4 days, so far this problem is gone, will continue testing.

[soredake]

Unfortunately, this problem is not yet fully gone, it still happens, thought not as frequent as before. Will post logs later.

[Et0h]

The test branch has now been updated to also merge in other unrelated changes to Syncplay. See:

• https://github.com/Syncplay/syncplay/tree/fix_missing_rewind
• Fix some rewind issues relating to file loads / playlist changes #698
• https://github.com/Syncplay/syncplay/actions/runs/11112391724?pr=698

[soredake]

@Et0h with this build and month of testing, I don't experience this problem anymore.