setConfigurationValues causes long rebuffer on live HLS streams

[jaumecornado]

Description

When playing a live HLS stream with a timeshift buffer, setConfigurationValues unconditionally executes player.time = VLCTime(int: configuration.startTime.asTicks.asInt32). Since startTime defaults to .ticks(0), this forces a seek to position 0 (the beginning of the timeshift buffer) even though VLC has already started at the live edge.

For live streams, any call to player.time = X — even setting it to the current position — causes VLC to flush its buffers and re-acquire the HLS segments. This results in:

• 3+ minutes of rebuffering before playback resumes
• Playback starting hours behind real-time (at the start of the timeshift buffer)
• Increasing memory consumption during the rebuffer

Steps to Reproduce

1. Configure a VLCVideoPlayer with a live HLS stream URL that has a timeshift buffer (e.g., 2 hours)
2. Set autoPlay = true and leave startTime at the default .ticks(0)
3. Observe that VLC initially connects at the live edge (correct), but then setConfigurationValues seeks to 0

Expected Behavior

For live streams, the player should remain at the live edge without any explicit seek.

Proposed Fix

Add a skipInitialTimeSet property to Configuration (default false) that, when true, skips the player.time = assignment in setConfigurationValues. All other configuration (rate, subtitles, audio, aspect fill) still applies normally.

See PR #26 for the implementation.

Environment

• tvOS 18
• VLCUI 0.5.1
• TVVLCKit 3.6.0 (via vlckit-spm)