search

Serranya / deadbeef-mpris2-plugin

A rewrite of the seemingly orphaned deadbeef-mpris-plugin originally written by HuangCongyu
GNU General Public License v2.0
65 stars 8 forks source link

Seek doesn't work #17

Closed kosivantsov closed 8 years ago

kosivantsov commented 8 years ago

running command dbus-send --print-reply --dest=org.mpris.MediaPlayer2.DeaDBeeF /org/mpris/MediaPlayer2 org.mpris.MediaPlayer2.Player.Seek int64:5000000 (or -5000000) makes deadbeef jump to next file instead of seeking forward (or backward). The same command with another player specified (VLC, for instance, among others) behaves as expected.

Serranya commented 8 years ago

I guess you seek past the current track. Do you know if this is the case?

In the case of the forward seek this is the behaviour MPRIS2 specifies. But the backward seek should just reset the current file to position 0 and not play the previous file.

What behaviour do you expect?

I will look into this.

kosivantsov commented 8 years ago

I guess you seek past the current track. Do you know if this is the case?

I know it's not the case, as the observed behaviour doesn't depend on the int64 value I submit. Even if I try to fast forward just one second, the player jumps to the next track. If I submit a negative value to rewind, it still jumps to the next track.

In other MPRIS2-compatible players the above mentioned command (with the appropriate instance name, not DeaDBeeF, of course) skips forward (positive value) and backward (negative value) by 5 seconds within the current track. This is exactly what is expected according to the linked MPRIS2 specifications.

But the backward seek should just reset the current file to position 0 and not play the previous file.

Reset should occur only if the negative offset is greater than the current position. Otherwise it should skip back in the current track by the identified offset, and not jump to the previous file, of course. But, as mentioned in the first post and here, jumping to the previous track actually never occurs, it's always the next track regardless the actual value or its positivity/negativity.

kosivantsov commented 8 years ago

It looks like the problem is here: if (newPositionInMilliseconds > durationInMilliseconds) { deadbeef->sendmessage(DB_EV_NEXT, 0, 0, 0); } (lines 372-374 in mprisServer.c). Seems like the result of the newPositionInMilliseconds calculation somehow is always greater than durationInMilliseconds, and therefore always jumps to the next track.

Just a thought, for what it's worth. If it's completely off-target, I'm sorry, I'm not a programmer

Serranya commented 8 years ago

I could reproduce the issue.

Serranya commented 8 years ago

The issue should be fixed on master. Can you test the current development version? I will release a fixed version after you can confirm that the bug is gone.

kosivantsov commented 8 years ago

I confirm that the bug is fixed now. Thank you very much for looking into it. The issue can be closed.