position plus/minus seems to ignore duration specified

[sona1111]

The player I am using is waterfox web browser on pop-os.

I'm generally able to control media in waterfox with playerctl. I can get the current time with $ playerctl position, I can set a specific time with $ playerctl position 100 , however it seems like when specifying a relative seek command like $ playerctl position 100+ (or any other number), the value is ignored and it just goes back/forward by ~3 seconds or so.

version is v2.4.1

[LurkAndLoiter]

Reproduced on brave and librewolf: limited to youtube's new player for me other players seek as expected.

[ferdnyc]

It's possible playerctl implements relative position changes as MPRIS Seek operations, and in my experience some players (especially web players) ignore the value of any argument to Seek and only respect the sign of the argument. So, a Seek(-100) and a Seek(-1) will skip backwards by the same predefined amount, corresponding to a tap of the skip forward/backwards keyboard key or a click/tap of a corresponding UI control.

Absolute position is probably implemented as MPRIS SetPosition, which is always absolute rather than relative, corresponding to a click or tap on that point in the playback position indicator.

If that's the case, there's probably nothing playerctl can do about it. playerctl is doing the right thing (sending a Seek message), it's the player that's choosing to ignore the distance value of the command.

It might be possible for playerctl to translate relative position changes into absolute ones, but that's not necessarily a great idea. It's using the protocol wrong (the Seek message is there for a reason), and there are a lot of corner cases in practice.

(For example, what if the current position is 100, and the user invokes playerctl position 200-? Sending a value of -100 with SetPosition isn't valid, so what should playerctl do? Should it be clamped to 0? Translated into a previous-track command? The correct message is Seek(-200), and the player's seek handling is supposed to deal with that however it normally would.)

The user could implement the same thing locally, though, with something like:

playerctl position $(( $(playerctl position) + [relative change] ))

# For example, this would always skip roughly 10 seconds backwards:
playerctl position $(( $(playerctl position) - 10 ))

Trying to go past the start or end of the track doesn't really seem to be a problem with that method, for various reasons:

• playerctl position doesn't understand negative values. It misinterprets a negative value like -200 as a command-line flag, and prints "Unknown option -200". So, any seeks past the start of the track will just fail.
• playerctl position with a value greater than the track length, at least when sent to VLC, causes it to seek to the current playback position, so it basically has no effect.(Though there is a brief stutter in the playback, as it clearly does still seek.)

[LurkAndLoiter]

it's the player

I believe this to be the case. youtube's new player issues are not limited to this issue.

• playerctl position doesn't understand negative values. It misinterprets a negative value like -200 as a command-line flag, and prints "Unknown option -200". So, any seeks past the start of the track will just fail.

the syntax would be playerctl position 200-

• playerctl position is a combination of mpris get position(not broken), set position(not broken), and seek(broken only for youtube player).
  • set: playerctl position 57 sets the player to playback at 57 seconds or nothing if 57 exceeds length
  • seek: playerctl position 57+ moves forward 57 seconds from current position or next track if length exceeded
  • seek: playerctl position 57- moves back 57 seconds from current position or 0 if less than
  • get : playerctl position returns current position

[!note] playerctl does not handle the out of bounds position issues you've brought up as it's all handled by the mpris methods seek and setposition (see prior links)

[ferdnyc]

• playerctl position doesn't understand negative values. It misinterprets a negative value like -200 as a command-line flag, and prints "Unknown option -200". So, any seeks past the start of the track will just fail.

the syntax would be playerctl position 200-

*nod* Understood, that was my point. I was illustrating that it would be bad for playerctl to internally translate playerctl position 200- into an absolute position change, because if the current position is 100 it now has to deal with the fact that it's just been asked to send a SetPosition(-100). And it's easier for playerctl to not deal with that scenario.

But it's fine for the user to implement a relative-to-absolute conversion themselves, via something like:

playerctl position $(( $(playerctl position) - 200 ))

Because in those cases, if the value returned by playerctl position is 100 the resulting command will be playerctl position -100, and that (luckily) fails to parse rather than doing something potentially wrong/stupid.