[BUG]: Seeking is bugged in current dev branch

[Tomato6966]

NodeLink version

dev branch

Description

Whenever you seek it just starts from position 0

Client

lavalink-client but same for custom client

Steps to reproduce

just seek any track (tested with yt, soundcloud and deezer)

Example code

No response

Confirmations

• My environment meets the minimum requirements.
• I have verified that this is not a duplicate issue.

Code of Conduct

• I agree to follow this project's Code of Conduct

[Tomato6966]

The Problem

In the latest updates to src/connection/handler.js (or inputHandler.js depending on the exact version), the code that handles the incoming play packet extracts the seek position like this:
JavaScript

// From the incoming Lavalink/NodeLink packet
const position = data.startTime || 0;

However, in the recent refactor of the Player class in src/audio/player.js, the play() method was updated to look for a property called position (or vice-versa, depending on the specific commit), but the object being passed still uses the old key or a different naming convention.
Why it stays at 0

Property Shadowing: The play command in the handler passes an options object to the player. If the handler passes { startTime: 10000 } but the player's internal logic now expects options.position, the position variable inside the player defaults to 0.

SuddenlySeeking Logic: The suddenlySeeking flag is used to prevent race conditions when a seek is requested immediately after a track starts. In the dev branch, the logic that clears this flag was moved. If the flag is set but the stream hasn't initialized correctly, the offset is ignored, and the stream starts from the beginning of the buffer.

FFmpeg Argument Order: If your version of NodeLink is using FFmpeg for the stream, a recent change may have moved the -ss (seek) parameter. In FFmpeg, placing -ss after the input (-i) results in slower, less accurate seeking that can sometimes fail to trigger at all on certain stream types, defaulting the output to the start of the file.

How to Fix It

To resolve this, you need to ensure the play method in src/audio/player.js and the handler in src/connection/handler.js are aligned.

In src/connection/handler.js:
Ensure you are passing the correct key to the player:
JavaScript

// Ensure 'position' is explicitly passed if that's what the Player class expects
player.play(track, { position: data.startTime || 0, ...otherOptions });

In src/audio/player.js:
Check the play method signature. It should look something like this:
JavaScript

async play(track, options) {
const startTime = options.position ?? options.startTime ?? 0;
// ... logic to apply startTime to the decoder
}

Recommendation

Check the src/audio/player.js file. If you see that it's looking for this.position or options.position but the incoming packet from your client (like Lavalink.js or Erela.js) is sending startTime, that is the source of the reset. Aligning these two keys will restore the seeking functionality.

[Tomato6966]

Fixed with #200