Fix: parsing of SeekToCommand json with negative position values

[schwubdiwub]

Fixed problem description:

When listening to a podcast episode the desktop and mobile applications offer buttons for skipping 15s forwards and backwards. The forward skipping button gets correctly handled but the backwards skipping comes back with an error message.

Cause and fix of the problem:

The SeekToCommand struct expects a non-negative integer, but the Request-JSON contains a negative number when using the "-15s" buttons. Thus, I changed the type to allow for negative numbers, so the Request-JSON gets correctly parsed and afterwards successfully handled by the player. The player does not interpret the position field at all, so another option to fix this would be to simply remove the position field. It only uses the value field with seems to contain the absolute position to seek to.

websocket request: Object {
    "command": Object {
        "endpoint": String("seek_to"),
        "logging_params": Object {
            "device_identifier": String("<....>"),
        },
        "position": Number(-15000),
        "relative": String("current"),
        "value": Number(567682),
    },
    "message_id": Number(1334681861),
    "sent_by_device_id": String("<....>"),
    "target_alias_id": Null,
}

[simias]

I was just investigating this same issue and found the same fix, although I also want to point out that es_seek_to.proto defines position as a 64bit signed integer, not 32bits, so maybe it would be better to use i64 here?

librespot/protocol/proto/es_seek_to.proto

Lines 14 to 25 in 33bf3a7

	message SeekToRequest {
	enum Relative {
	BEGINNING = 0;
	END = 1;
	CURRENT = 2;
	}
	CommandOptions options = 1;
	LoggingParams logging_params = 2;
	int64 position = 3;
	Relative relative = 4;
	}

Also I believe that this is technically a breaking change, since this is a public type. I could be wrong.