MPRIS: seek calls only advance to next chapter

[grahamvh]

Bug/Feature description

Any call of the MPRIS seek function(https://github.com/geigi/cozy/blob/1b640d1f61aa8a610a91427567c0d7f2df4e86bd/cozy/control/mpris.py#L230) in cozy causes it to skip to the next chapter. This is most apparent when running cozy inside of phosh, as it has music controls that offer a skip ahead 30 seconds and go back 10 seconds.

Steps to reproduce

Use phosh or other mpris based media controller to try to skip ahead or behind, and it will always send you to the next chapter.

System Information

• Operating System: PureOS
• Installation source: flathub
• Version of cozy: 1.3.1

[grahamvh]

From what I can tell, inside the Seek function the self._player.position, seems to return a seemingly random large integer(not sure why) here

[grahamvh]

I've tested out the latest master branch (hash 1be8d73c740cd6dfca2a7192c8bc509de806cb14) which appears to have the mentioned merge request applied. I don't see any change in the behavior for this issue. This is not fixed.

Thanks for working on it though! It's likely closer.

[rdbende]

This is not fixed.

I'm not sure why then. It works correctly for me with ~GNOME Shell's built-in media controls~ (incorrect, since it only has forward and rewind buttons, not jump x seconds), and with any MPRIS control extension I've tried, and also by manually calling the MPRIS method on DBus.

[grahamvh]

Interesting, I'll try to run some experiments on it when I get a chance. I should have lots of time this weekend.

In the meantime this is what I was testing using: OS: Pureos 10 (byzantium) Arch: Arm64 Install: Flatpak (build from master branch with: flatpak-builder build-dir --force-clean -vvvv com.github.geigi.cozy.json && flatpak-builder --user --install build-dir --force-clean com.github.geigi.cozy.json) MPRIS handler: Phosh built-in, hitting the +30sec and -10sec buttons on the top dropdown.

I plan to capture the seek function inputs when pressing those buttons, and the self._player.position when just playing the audiobook. From what I recall from looking at this before, just capturing what was stored in self._player.position gave some really bizzare results when just listening to a chapter without trying to seek.

[rdbende]

self._player.position still returns insanely large numers (nanoseconds), but it's now properly divided in the MPRIS code. I didn't fix the position getter yet, as it requires some other, relatively big refactorings in the player code, but yeah, the MPRIS part should be fine.

[rdbende]

Can you please record what numbers are sent to the MPRIS seek method? If I'm not mistaken, they should be 10 and 30 million

[grahamvh]

Yep, 30,000,000 and -10,000,000 is that the seek function is receiving. It sounds like the getter needs to be fixed in order to stop this from just moving to the next chapter? Would you like a separate issue?

[rdbende]

I don't mind a separate issue, but you can also reopen this one (I can't), since the bug remains the same.

[grahamvh]

Sadly it won't let me rei=open it either. @geigi ?

[rdbende]

@grahamvh it works for me with Phosh 0.33.0 on an ASUS tablet.

[grahamvh]

Ok after more testing, I've found that the footprint of this is different after the MPRIS update. Before the MPRIS updates this occurred on every book, now there appears to be some specific criteria and circumstances.

Requirements to see the issue:

• Appears to only occur in books in the m4b format (Leviathan Wakes by James S. A. Corey from libro.fm for example). I've tested every book I have that's m4b format and they all see this issue(7 books in my library that are m4b), and a few that are just mp3 files that do not see the issue (I tried out 10 different books in that format).
• This only occurs past the first chapter. One appears to be able to get into Chapter 2 a bit before the issue presents itself. Every chapter past that sees it without fail. (By chapter I mean whatever each entry list presented for each book would be called)