[Bug] 6-second OSD timeline steps and high control latency during HLS playback on CoreELEC (Linux/Amlogic) #2139

Describe the problem

Issue description:
During HLS playback on CoreELEC platforms, the OSD timeline does not advance smoothly second by second. Instead, it ticks in strict 6-second increments. Furthermore, player responsiveness is heavily delayed – pressing pause, triggering OSD, or trying to seek takes exactly ~6 seconds to react to user input.

It behaves as if the demuxer loop is blocked by the HLS segment duration and waits for the entire 6s chunk to finish processing before responding.

Platform comparison (Important):

• On Kodi 21 (Windows/Android), the exact same HLS stream works perfectly fine (smooth timeline, instant pause/seek response).
• On CoreELEC, the issue is present in CoreELEC 21 and behaves exactly the same in CoreELEC 22 RC1.

CoreELEC developers directed me here, as they believe the underlying HLS blocking mechanism is shared with inputstream core logic.

Environment:

• OS: CoreELEC 22.0-RC1 and CoreELEC 21
• Addon version: inputstream.ffmpegdirect 22.2.11.1 / inputstream.adaptive
• Log link (anonymized): https://coreelec.org

From the log, the 6s chunk delta is clearly visible after opening the OSD timeline:
"Media sequence change reflected in first_timestamp: 59327826444 -> 59333826444" (exact 6-second delta).

Any insight into why this demuxer blocking mechanism occurs specifically on this platform would be greatly appreciated. Thanks!

Possible fix

No response

Steps to reproduce

No response

Debug log

https://paste.coreelec.org/3/NbSk3gtb

Stream manifest file(s)

No response

Additional info

No response

Operating system(s)

Linux

Operating system version(s)

No response

InputStream Adaptive version(s)

22.3.24.1

Kodi version(s)

coreelec 21 and 22