Seeking during playback triggers pause notification

[ledge74]

Hello guys,

I have noticed a strange behaviour introduced with OpenPHT & Rasplex 1.6.0

I use my plugin HelloHue to trigger light actions based on a Plex client playback status (starting new playback, playback paused, playback resumed, playback stopped). The plugins gets real time playback status from the server websocket notifications, ex: ws://127.0.0.1:32400/:/websockets/notifications

Since the release of OpenPHT/Rasplex 1.6.0, when seeking through a video, the clients triggers a paused notification and a playing notification on the server (you can see this notifications in the websockets).

On previous versions of OpenPHT/Rasplex, the server did not send any notification when seeking through the video.

This causes abnormal behaviour for my channel and every other plex app that uses websocket notification has a trigger point.

I reproduced this on Rasplex 1.6.0 RPI 1 B+ and OpenPHT 1.6.0 on mac

Regards

[Kwiboo]

When we added support for adaptive seeking and seek preview thumbnails it included a change to pause the video while seeking. This could have had an unwanted affect on the timeline reporting. Would buffering be a better state or should we keep reporting playing with the same time until seeking is done?

From https://github.com/plexinc/plex-media-player/wiki/Remote-control-API: Valid values are stopped, paused, playing, buffering and error.

[ledge74]

Indeed, buffering would be a more appropriate state to return when seeking through a media IMO

[NedtheNerd]

Happy to go with 'buffering'.

[ledge74]

Every other Plex clients I have tested (iOS, Xbox, chromecast) are not triggering paused events when seeking, why should this be different with OpenPHT/Raspex?

EDIT : just verified with iOS, it is triggering the buffering event when seeking

[atomjack]

I'm not sure if this is related, but ever since OpenPHT 1.6.0 (including 1.6.1 and 1.6.2) on Windows, seeking now causes a noticeable pause/delay (of about one second). My Windows client is connected to my gigabit LAN (which my PMS is also on) via ethernet, not wifi, and I have it set to direct play, so the transcoder is not being used (which would cause a delay like this). I just tested by downgrading back to 1.5.2, and like it used to do, seeking was instantaneous, while on 1.6.x, there is a good one second delay before playback resumes. This is definitely undesirable behavior in my opinion.

Also, I could previously mash one of my seek buttons and seek multiple steps very quickly, and see each step in the time readout update instantaneously, yet with 1.6.x the time readout doesn't update until about one second after the last seek (although it does appear to seek the correct amount of time depending on the number of button presses).

[Kwiboo]

OpenPHT defaults to use adaptive seeking starting with 1.6.0, when skip forward/backward is pressed within the default 750 ms seek delay (preference option) the seek position will progress in steps of 30s 1m 2m 3m 5m+. You can change back to previous instant seek behavior by changing the seek delay in preferences to 0 ms. You can also change the seek steps in advancedsettings.xml (see #92).

[atomjack]

@Kwiboo Ahhh I see! Thanks!

[ledge74]

@Kwiboo any chance to get this implemented in the next release?

Happy to go with 'buffering'.

[hstamas]

Has this been fixed/implemented? I was thinking of switching back to using OPHT but this issue would keep me from doing so.