Downloaded Video Won't Seek on Your TV? The Fix
The video plays when you cast it, but dragging the timeline fails or restarts it from the beginning. Here is the container problem behind that, and the fix.
To jump to a timestamp, a player has to read the file's index — and in many downloaded MP4s that index, the moov atom, sits at the end of the file rather than the front. A cast receiver streaming the file over your Wi-Fi cannot seek until it has read all the way to that index, so the scrubber drags and snaps back or the video restarts at 0:00; rewriting the container fixes that without touching the picture.
Convertlix for Android does that rewrite on the phone. The file is opened through Android's own file picker, processed by the phone and written back to Downloads, so nothing is uploaded and there is no server copy. It needs Android 8.0 or later and one sign-in — there is no guest mode — after which the tools work with the network off. On the free tier a video has to be 100 MB or smaller; Premium takes files up to 2 GB.
You are not imagining this, and the TV is not being fussy
Playing and seeking are two different capabilities, which is why "but it plays fine" does not settle the argument. Playback needs only the next few seconds of data; seeking needs to know which byte holds the frame at 27:14, and that answer lives in the index. Without it the receiver can only refuse the jump or start again from the beginning.
The fixable half is the file's structure: how the container is laid out, and which one it is. The unfixable half is the receiver — if it has no decoder for the codec inside, or the file is DRM-protected, or you are casting a live stream, no rewrite helps.
What is actually going on inside the file
An MP4 is a series of boxes, or atoms. Two matter here: mdat, holding the compressed audio and video, and moov, the index of track descriptions, timestamps and byte offsets. A muxer that does not know the final media size until it finishes writing puts mdat first and moov last. Locally that is harmless — a player jumps to the end and reads the index instantly. Over a cast it is not: the receiver has fetched only the first stretch of bytes, and the map it needs is 300 million bytes away.
"Fast start" is the name for the fixed version: the same media, rewritten so moov comes before mdat. That changes the byte order, not the pictures — the video and audio streams are copied across unchanged.
Several other things produce the same symptom:
- The receiver is pulling the file over Wi-Fi. The phone serves the file while the receiver fetches ranges of it over HTTP, so seeking needs byte-range requests working end to end.
- Fragmented MP4. Some downloads are fMP4, with the index split into per-fragment headers; many receivers handle that only inside a DASH or HLS manifest.
- The container is not MP4 at all. Google's published list of media supported by Cast devices covers MP4 and WebM; MKV and AVI are not on it (checked September 2026). AVI keeps its index (
idx1) at the end too. - Variable frame rate. Screen recordings and many phone captures are VFR, so timestamps are not evenly spaced and a player estimating the frame at 12:30 from an average frame rate lands in the wrong place.
- Long gaps between keyframes, HEVC and 10-bit HDR. Decoding can only begin at a keyframe, so keyframes 10 seconds apart make skips imprecise — and a receiver can play HEVC or 10-bit HDR steadily yet handle the decoder flush a seek demands badly.
Containers are also where the audio track lives, which is the anatomy behind Extract the Audio From a Video on Android.
| Symptom | Likely cause | Fix | What you lose |
|---|---|---|---|
| Plays, but the timeline will not move | Index (moov) at the end of the file | Rewrite the container, index first | Nothing — the media data is copied, not re-encoded |
| Dragging the scrubber restarts it at 0:00 | Receiver cannot resume mid-file | Rewrite it, or play from a USB stick | Nothing on a rewrite; convenience if you move the file |
| MKV or AVI plays on the phone, not the TV | Container the receiver rejects | Convert to MP4 | Time, and a possible re-encode |
| Skips land seconds off the mark | Keyframes far apart in the source | Re-encode with more keyframes | Time and a generation of quality |
| Stalls or blacks out when scrubbing | Codec it decodes but cannot seek (HEVC, HDR) | Re-encode to 8-bit H.264 | Time, quality, and HDR |
How to fix a downloaded video that won't seek when cast
- Confirm it is the file, not the television. Play the video locally on the phone and drag the timeline. If it seeks there but not on the TV, the media is fine and the structure is the problem.
- Look at the extension and the size. An
.mp4or.movthat plays but will not scrub is usually a layout problem; an.mkvor.avineeds a real conversion. Over 100 MB is above the free per-video ceiling. - Rewrite the file so a cast receiver can seek it. In Convertlix that is Fix for TV — make downloaded video skip and seek when you cast it. It runs on the phone, nothing is uploaded, and the new file lands in Downloads beside the original.
- Convert the container if the receiver never accepted it. Video Converter takes MP4, MKV, MOV or AVI and writes MP4, MKV or MOV — the move for an MKV or AVI download a receiver will not open.
- Cast the new file and test the middle, not the start. Jump to halfway, then 90%, then back a third of the way in. Seeks near the start succeed even on broken files, because the data is buffered.
- If it still will not scrub, change the delivery. A USB stick in the television, or a media server such as Plex or Jellyfin, takes seeking out of the receiver's hands.
When this will not work
If the receiver has no decoder for the codec, the video will not play at all however the container is arranged — that needs a genuine re-encode to H.264, and for a very large file a computer is the better tool. DRM-protected downloads from a streaming service are encrypted, and nothing converts or rewrites those. Live channels and HLS or DASH streams are not single files at all: a .m3u8 is a playlist of segments. A download that is really a folder of numbered fragments has to be joined first. And some smart-TV apps ship a player with no working scrub bar, in which case the file was never the problem.
FAQ
Why does the video play but not skip?
Playback only needs the next few seconds of data, while seeking needs a map of the whole file — in an MP4 that map is the moov atom. When it sits at the end of the file, a receiver streaming the video over your network has not read it yet, so it cannot turn "27:14" into a byte position, and it either refuses the jump or starts over. Rewriting the file so the index comes first is what makes seeking possible.
Does fixing it change the video quality?
Reordering a container is a byte-level operation: the compressed audio and video streams are copied across as they are, so the picture is identical and the file size barely moves. Quality only changes when the codec itself has to change — HEVC to H.264, or fixing a variable frame rate — because that means decoding and encoding again, which costs a generation. If seeking is your one complaint, you should not need that.
Will this work on a Fire TV or a Samsung TV?
It depends on the receiver's player, and behaviour varies between devices and firmware versions. Putting the index at the front removes the most common structural reason a receiver cannot seek, so it helps broadly — but a device with no decoder for the codec, or a TV app whose player has no working scrub bar, will not be rescued by a better-arranged file. The quick test is one file, cast, jump to the middle.
Can I fix it on a computer instead?
Yes, and these are the standard tools. ffmpeg does it in one line without re-encoding — ffmpeg -i in.mp4 -c copy -movflags +faststart out.mp4 — HandBrake has a "Web Optimized" checkbox that does the same thing as part of an encode, and VLC will remux through Media then Convert/Save. For a 2 GB download, a desktop running ffmpeg is faster and less fiddly than any phone.
Does Convertlix upload my video?
No. The file is opened through Android's file picker, rewritten by the phone itself and saved to the Downloads folder, so it never leaves the device and there is no server copy to retain. The app's network calls carry identity, licence, quota, remote configuration and payment data only — never media. Turn on airplane mode after signing in and the job still finishes.
If the picture is fine and only the scrubber is broken, Fix for TV rewrites the file on the phone and leaves the original download untouched.