Takes 4 minutes to skip forward 30 minutes in a video.

[turleym 0]

And, 12 minutes to skip forward an additional 1:20 minutes. 

I was watching Guardians of the Galaxy 2 on Roku, and at about the 1:30 mark, stopped watching.  When I came back later and resumed, it appeared that Emby was locked up as the video was not restarting  I played with it a bit on Roku, but then moved over to PC.  On PC I discovered that I could start the video from the beginning, it plays fine.  If I then move forward to the 30 min mark in the video, it will sit and spin for 4 minutes before it starts playing again.  If I move to 1:30 in the video, it will sit and spin for 12 minutes before it starts to play again. Other videos will restart very quickly, but I suspect if I looked around I could find others that do not (likely the larger Bluray rips).

I upgraded to server ver 4.10.2.0, and the issue is the same.  Server is running on a Synology DS218, and the issue exists on both PC and Roku.

Attached are 2 log files.  The first is a log of moving forward 30 min, then to 1:30 and waiting the 4 min, then the 12 minutes until the video resumed playing (embyserver.txt).  For the second file, I turned on Debug Logging and just did the 20 min advance (embyserver Debug Logging 20 min advance.txt). 

embyserver Debug Logging 20 min advance.txt embyserver.txt

 

Edited 10 hours ago by turleym
Screenshot of dashboard when playing.

[Abobader 3543]

Hello turleym,

** This is an auto reply **

Please wait for someone from staff support or our members to reply to you.

It's recommended to provide more info, as it explain in this thread:

Thank you.

Emby Team

[Luke 43524]

Hi, the short answer is the mp4 is probably not encoded properly and needs to be reencoded. 

[Luke 43524]

Here is the long answer…

[Luke 43524]

An MP4 that plays normally but cannot seek (fast-forward, rewind, or jump to a timestamp) usually has a problem with its container metadata, timestamps, or keyframe indexing.

There are several possible causes, depending on how the MP4 was created and how it’s being played.

Most common causes

1. Missing or improperly placed

moov

atom

The MP4 container has a moov atom containing metadata necessary to locate samples throughout the file.

• Missing moov: The file may be incomplete or corrupted. Most players won’t play it at all.
• moov at the end: Common with traditionally muxed MP4 files. Seeking may not work properly during progressive HTTP playback until the metadata is downloaded.
• Invalid sample tables: The moov atom exists, but its sample offsets, sizes, or timing information are incorrect.

For ordinary MP4 files, moving the moov atom to the beginning often fixes HTTP playback problems.

ffmpeg -i input.mp4 -map 0 -c copy -movflags +faststart output.mp4

This remuxes the file without re-encoding.

2. Missing or incorrect keyframes

Most video codecs, including H.264 and HEVC, use keyframes (IDR frames or other random-access points) to support seeking.

Problems include:

• Very long intervals between keyframes.
• Keyframes incorrectly identified in the MP4 sample tables.
• No valid random-access points after the beginning.
• Incorrect sync sample (stss) information.

For example, if an encoder generates only one keyframe at the beginning of a 30-minute video, seeking can be extremely slow or fail in some players.

3. Invalid timestamps

This is particularly common with programmatically generated or remuxed MP4 files.

Potential issues include:

• Non-monotonic DTS values.
• Incorrect PTS/DTS relationships.
• Invalid track durations.
• Incorrect timescales.
• Large timestamp discontinuities.
• Corrupted composition time offsets (ctts).

A player might decode the video sequentially but fail to map a requested timestamp to the correct sample.

4. Fragmented MP4 issues

If the MP4 is fragmented (fMP4), seeking behaves differently.

Fragmented files typically contain:

• moov — initialization metadata
• moof — fragment metadata
• mdat — media data
• Optionally sidx or mfra — indexing information

Some players require additional indexing or need to scan fragments before they can seek efficiently.

A fragmented MP4 without an appropriate index can play sequentially but have limited seeking support.

5. HTTP server problems

If the MP4 plays through a browser or streaming client, the file itself might be perfectly valid.

The server needs to support HTTP byte-range requests for efficient seeking.

For example:

HTTP/1.1 206 Partial Content

Accept-Ranges: bytes

Content-Range: bytes 1000000-1999999/50000000

Potential issues include:

• Server ignores Range requests.
• Server returns 200 OK instead of 206 Partial Content.
• Incorrect Content-Length.
• Reverse proxy strips range headers.
• Dynamic streaming responses don’t support random access.

This is a particularly important distinction when the file seeks correctly in VLC but not in a browser.

How I’d diagnose it

First, inspect the file with FFprobe:

ffprobe -v error \

  -show_entries format=duration,format_name,start_time \

  -show_entries stream=index,codec_name,codec_type,start_time,duration,nb_frames \

  -of json input.mp4

Then inspect keyframes:

ffprobe -v error \

  -select_streams v:0 \

  -skip_frame nokey \

  -show_entries frame=pts_time,key_frame,pict_type \

  -of csv input.mp4

Finally, try remuxing with FFmpeg using -c copy. If the resulting file seeks correctly, that strongly suggests a container-level issue rather than a fundamental encoding problem.

Three questions that would narrow this down

• Where does seeking fail? Browser, VLC, another media player, or a custom application?
• How was the MP4 generated? FFmpeg, another encoder, a custom muxer, or downloaded from somewhere?
• What happens when seeking? Is seeking completely disabled, does it jump to the wrong position, or does playback freeze?

The distinction matters because an MP4 that cannot seek at all is a different problem from one that seeks inaccurately or only seeks backward.

[Luke 43524]

As a result of this, the Roku has to download and decode the entire file in order to locate the file position to seek to, and this is why it takes so long. 

[softworkz 5592]

At least half of that AI response is not applicable to our playback.or can be quickly ruled out from viewing the log file.