I've identified what appears to be a bug in the NextPVR web player's elapsed-time display when seeking within a recording using transcoded HLS playback.
Environment
Issue
After seeking within a recording, the elapsed-time indicator on the left side of the timeline shows a position significantly ahead of the actual playback position.
For example, seeking to approximately 10 minutes can result in the elapsed-time indicator showing approximately 20 minutes, even though playback is occurring at the correct location.
Steps to reproduce
Suspected cause
In /app/wwwroot/player.html, around line 1593, the playback position is calculated as:
var time = player.currentTime + startSeconds;
However, the displayed position is subsequently calculated using:
var position = display(time + startSeconds);
Since time already includes startSeconds, the seek offset is effectively added twice when formatting the elapsed-time label.
The internal lastPosition value uses time directly, which appears to be correct.
Tested fix
Changing:
var position = display(time + startSeconds);
to:
var position = display(time);
corrected the elapsed-time display in my local testing.
After applying this change, I sought to approximately 10 minutes and captured the following values from Firefox DevTools:
player.currentTime = 1.923291
startSeconds = 601.414791
lastPosition = 603
displayedTime = 00:10:03
This is consistent with the actual playback position:
1.923291 + 601.414791 = 603.338082 seconds
With the original expression, these same values would produce 1204.75 seconds (20:05) instead of 10:03.
Verification
After applying the one-line correction and refreshing the web player, the elapsed-time indicator correctly reflected the recording position during seeking. I also compared commercial boundaries against recording-relative timestamps, which were consistent after the correction.
The modification was made directly inside the running Docker container and is not a persistent fix.
I've confirmed this behavior with Firefox and transcoded HLS playback. I haven't tested other browsers or playback methods.
It appears the display calculation simply needs to use display(time) rather than adding startSeconds again.
Environment
- NextPVR 7.1.1.260616
- Docker: nextpvr/nextpvr_amd64:stable
- Firefox on Windows
- MPEG-2 TS recording, approximately 58 minutes
- Playback through recording.transcode.m3u8
Issue
After seeking within a recording, the elapsed-time indicator on the left side of the timeline shows a position significantly ahead of the actual playback position.
For example, seeking to approximately 10 minutes can result in the elapsed-time indicator showing approximately 20 minutes, even though playback is occurring at the correct location.
Steps to reproduce
- Open a recorded .ts program in the NextPVR web player.
- Seek to approximately 10 minutes into the recording.
- Allow transcoded playback to resume.
- Observe that the elapsed-time label is ahead of the actual recording position.
Suspected cause
In /app/wwwroot/player.html, around line 1593, the playback position is calculated as:
var time = player.currentTime + startSeconds;
However, the displayed position is subsequently calculated using:
var position = display(time + startSeconds);
Since time already includes startSeconds, the seek offset is effectively added twice when formatting the elapsed-time label.
The internal lastPosition value uses time directly, which appears to be correct.
Tested fix
Changing:
var position = display(time + startSeconds);
to:
var position = display(time);
corrected the elapsed-time display in my local testing.
After applying this change, I sought to approximately 10 minutes and captured the following values from Firefox DevTools:
player.currentTime = 1.923291
startSeconds = 601.414791
lastPosition = 603
displayedTime = 00:10:03
This is consistent with the actual playback position:
1.923291 + 601.414791 = 603.338082 seconds
With the original expression, these same values would produce 1204.75 seconds (20:05) instead of 10:03.
Verification
After applying the one-line correction and refreshing the web player, the elapsed-time indicator correctly reflected the recording position during seeking. I also compared commercial boundaries against recording-relative timestamps, which were consistent after the correction.
The modification was made directly inside the running Docker container and is not a persistent fix.
I've confirmed this behavior with Firefox and transcoded HLS playback. I haven't tested other browsers or playback methods.
It appears the display calculation simply needs to use display(time) rather than adding startSeconds again.
