Skipping to later timeframes takes increasingly longer

[TheN00r]

• Add-on Version: v7.4.0+beta.2
• Kodi Version: 22.0 Piers
• Kodi GUI Language: English
• Operating System: CoreELEC - Linux kernel 5.15.170
• Operating System Language: English

---

Expected Behavior

Using remote to skip ahead 10s/30s/1m etc. should happen instantly, either to beginnning or end of video.

---

Current Behavior

Skipping to within a couple of minutes of the beginning of a long video happens within a couple of seconds, skipping to further in the video takes increasingly longer e.g. start 3h video, skip to 1 minute mark takes 3s before playback from this point, skip to 2h30m mark takes about 30s before playback from this point. All the while playback continues from the timeframe where skip button was pressed with the timeline indicator at the top of the screen.

---

Log

[REDACTED]

During the capture of this log I consecutively skipped 5m then waited, 40m then waited and 1h then waited.

---

Steps to Reproduce

Please provide detailed steps for reproducing the issue.

1. Start any, preferably, long video
2. Skip to end part of video
3. Wait

Additional Information

Tried rollback to earlier versions of plugin.video.youtube, but problem remains. Change on youtube's end?

[karlo2105]

You need to post full debug otherwise developer won't be able to investigate your issue.

[TheN00r]

Added log to 1st post

[nouman8]

i am also noticing similar problem for the past few days

[MoojMidge]

Works fine for me.

I suspect the problem is with recent versions of InputStream.Adaptive > v22.2.9 (which is the version I am using) where there have been some changes to seeking, but can't confirm unless other people who are experiencing this issue provide logs.

Possibly the correct segment is not being requested or rather all segments prior to the correct segment are being requested and downloaded before the correct segment data is being processed.

A full Kodi debug log leaks too much potentially PII, so for the moment don't provide that, instead do the following:

1. Download this test version: https://github.com/MoojMidge/plugin.video.youtube/archive/refs/heads/v7.4.zip
2. Disable Kodi debug logging and instead enable debug logging in the addon: YouTube > Add-on Settings > Advanced > Debug > Enable debug logging > Enabled
3. Restart Kodi
4. Open a long YouTube video
5. Seek towards the end of the video
6. Stop playback once seeking completes
7. Upload the resulting log.

@TheN00r - I can't seem to properly redact you original issue comment to remove the log you posted. Can you edit your original post, then select each previous edit you made, and delete them when they open for viewing?

[nouman8]

@MoojMidge i did the steps you mentioned above here's the log https://paste.libreelec.tv/loved-ibex.log Thanks :)

[MoojMidge]

@nouman8 ‐ thanks. That does seem to show that there is an issue with InputStream.Adaptive where it is requesting/downloading all preceding audio segments in series when seeking.

To confirm, see if the LibreElec addon repository, or your local addon package store, still has InputStream.Adaptive v22.2.9 available to reinstall. If so, check if the problem does not occur with this version of InputStream.Adaptive

[nouman8]

unfortunately the lowest InputStream.Adaptive version i can install from the LibreElec repo is 22.3.4.2 which still has this issue.

[TheN00r]

@MoojMidge Thank you for your concern, I edited the log before posting it though, but did as you requested anyway. Seems rolling back to earlier inputstream adaptive version creates a dependency mismatch domino effect that I tried to follow through on, but eventually gave up because of API mismatches. Eventually was able to manage a workaround by rolling back CoreELEC to version from Oct 14, 2025 which hadn't implemented the Kodi inputstream API update to version 3.4.0 yet. Then installed the attached inputstream addons manually and was able to initiate seek request normally again using the old API.

inputstream.ffmpegdirect-22.0.1.2.zip
inputstream.adaptive-22.1.10.2.zip
inputstream.rtmp-22.0.0.3.zip

[neo-neo1]

Same exact problem here.

Also using CoreELEC with 7.4.0+beta.2 I've noticed a similar issue when skipping forward. Going to try grabbing a log to confirm and then downgrading. I really need to learn to stop updating anything on Kodi.

[kuraikaze]

For what it's worth ... the issue is much more severe with AV1 than VP9, for some reason.

[MoojMidge]

For what it's worth ... the issue is much more severe with AV1 than VP9, for some reason.

That seems unusual as the logs provided, and the changes to InputStream.Adaptive, all seem to indicate the issue is associated with seeking of AAC audio.

Without a log couldn't see any reason why you may be seeing any difference.

[kuraikaze]

Possible that the VP9 ones that don't seem quite so problematic are using Opus audio.
There is a noticeable change in offered default video/audio codec depending how soon I watch something as it appears in my subscription feed.
Quickest is VP9/Opus then VP9/AAC then AV1/AAC (AV1 seems to be only ever offered with AAC as default).
Presumably dependent on YouTube's re-encode priority hierarchy.

I'll turn on logging and pay more attention, looking for exemplar situations.

[TheN00r]

I managed to identify the release where this issue appears first, which seems to be from v22.3.4 on, meaning v22.3.3 is the last version without it and the problem should have become apparent after one of these commits. I'll attach v22.3.3 for CoreELEC here which at least allows for updating nightlies again beyond Oct 14, 2025.

inputstream.adaptive-22.3.3.1.zip