Repeatedly pressing skip (30s) or back (10s) buttons causes the video to restart

Plex Players Mobile Devices
1

Server Version#: N/A (affects all versions)
Player Version#: 9.21.1.1169 (affects all versions)

When using Chromecast, pressing either the skip (30s) or back (10s) buttons causes the video timeline to temporarily reset to 0:00. If the skip/back button is pressed again immediately the video restarts from the 0:00 mark.

This issue has been present for at least 5 years (possibly longer).

Expected Behaviour
The expected behaviour is that the multiple presses of the skip (30s) are added together. For example, if a video is at the 5:00 mark, pressing skip x3 times should result in the video playing from 6:30. Instead it results in the video playing from 1:00 (video resets to 0:00 after the first press, then the subsequent two presses results in 0:30 then 1:00).

Steps to reproduce:

  1. Open the Plex for Android App or Plex Web Player (in Chrome or Edge).
  2. Connect to a Chromecast.
  3. Begin playing a video.
  4. Move the timeline slider to somewhere in the middle of the video and wait for it to begin playing.
  5. Double tap the skip button (with about a 0.5 - 1 second gap between taps).
  6. Observe that the video has restarted.
2

I did some more testing this afternoon and this issue is also present when using Chromecast from the Web player on a PC. Looking through the server logs, it seems that the offset is calculated in the player, so this bug must be in some shared code (or otherwise repeated across multiple platforms).

When playing a video at the 10:00 mark then pressing skip twice I got the following log output.

From the player logs (nothing useful):

{
    "type": "log:message",
    "level": 3,
    "message": "[Metrics] Updating session last interaction time",
    "time": "2023-05-02T09:35:10.483Z"
  },
  {
    "type": "log:message",
    "level": 4,
    "message": "[Cast] Sending custom message with type \"SEEK\"",
    "time": "2023-05-02T09:35:10.483Z"
  },
  {
    "type": "log:message",
    "level": 3,
    "message": "[Metrics] Updating session last interaction time",
    "time": "2023-05-02T09:35:11.272Z"
  },
  {
    "type": "log:message",
    "level": 4,
    "message": "[Cast] Sending custom message with type \"SEEK\"",
    "time": "2023-05-02T09:35:11.272Z"
  }

From the server logs we can see that the offset parameter is correct for the first request (offset=630), but incorrect for the second request (offset=30). The player is clearly calculating the offset incorrectly after the first skip request.

May 02, 2023 19:42:06.153 [0x149a76bf6b38] DEBUG - Completed after connection close: [192.168.1.9:35681] 200 GET /video/:/transcode/universal/start?hasMDE=1&path=%2Flibrary%2Fmetadata%2F28023&mediaIndex=0&partIndex=0&protocol=http&fastSeek=1&directPlay=0&directStream=1&subtitleSize=100&audioBoost=100&location=lan&directStreamAudio=1&mediaBufferSize=30720&session=xutdx53mc5qezvv7dr6hzvz9&offset=630&subtitles=burn&copyts=1 (8 live) #184 TLS 1280ms 3547622 bytes (range: bytes=0-) 
May 02, 2023 19:42:06.153 [0x149a71343b38] DEBUG - [TranscodeOutputStream] Input processing thread exited after writing 11993088 bytes, m_closed=1, m_endOfFileReached=0, session->isStopped()=0
May 02, 2023 19:42:06.219 [0x149a75b15b38] DEBUG - Request: [192.168.1.9:35683 (Allowed Network (Subnet))] GET /video/:/transcode/universal/start?hasMDE=1&path=%2Flibrary%2Fmetadata%2F28023&mediaIndex=0&partIndex=0&protocol=http&fastSeek=1&directPlay=0&directStream=1&subtitleSize=100&audioBoost=100&location=lan&directStreamAudio=1&mediaBufferSize=30720&session=xutdx53mc5qezvv7dr6hzvz9&offset=30&subtitles=burn&copyts=1 (8 live) #1a9 TLS Signed-in Token (pierowheelz) (Chrome) (range: bytes=0-)

Note that the player and server logs were taken from separate tests - this is why timestamps don’t line up.

3

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.