[kdeconnect] [Bug 469617] MPRIS receivers/controllers are ignoring playback rate to extrapolate current play position
https://bugs.kde.org/show_bug.cgi?id=469617 Double Jumper changed: What|Removed |Added CC||doubjumper+...@gmail.com -- You are receiving this mail because: You are watching all bug changes.
[kdeconnect] [Bug 469617] MPRIS receivers/controllers are ignoring playback rate to extrapolate current play position
https://bugs.kde.org/show_bug.cgi?id=469617 --- Comment #3 from Andy Holmes --- Fair enough, I don't do a lot of podcasting so I hadn't considered that. In that case I would suggest a slightly simplified way of communicating this, in the form of a triplet like `[rate, min, max]`. If the field is missing (older clients), it can be assumed `[1.0, 1.0, 1.0]`. The min/max would be required since if this is a useful feature, we will certainly want to be able to control it as well. If the value is, or falls back to `[1.0, 1.0, 1.0]` we can assume it's unsupported or not controllable and hide any UI in remote controls. -- You are receiving this mail because: You are watching all bug changes.
[kdeconnect] [Bug 469617] MPRIS receivers/controllers are ignoring playback rate to extrapolate current play position
https://bugs.kde.org/show_bug.cgi?id=469617 --- Comment #2 from b...@mogwai.be --- (In reply to Andy Holmes from comment #1) > ... > It would very much preferable to just have clients update the position > property more frequently in this case, rather than try to support more of > the MPRIS interface explicitly. Playback rates other than 1.0 are pretty > uncommon, usually only occur for short periods of time (i.e. seeking), and > re-using the `pos` field would be backwards compatible. Well, I'm the developer of Kasts, and non-standard playback rate is among the top 5 requirements for podcast players. That's also why I noticed this problem and started investigating this. So far, Kasts was simply relaying the position-changed signals coming from the audio backend, which leads to such signals being sent 1 to 4 times per second, depending on the backend. However, that approach will make kdeconnect drain the battery at 10% per hour on my android device: see https://bugs.kde.org/show_bug.cgi?id=442782 . Then, while re-implementing MPRIS position properly, I ran into this playback rate bug. So, while I recognize that many players do not implement MPRIS properly (including Kasts up to now), that doesn't mean that kdeconnect should not do so. As a matter of fact, these kinds of bugs are actually holding back players implementing the intended standard properly. Anyway, I was looking at the kdeconnect source code, and it doesn't look very complicated(*) to implement. It's just a matter of sending the rate reported through DBus and using it in the one line of code that does the extrapolated play position. I was actually planning on making MRs for this. (*) Not very complicated in the sense that the basic principle is very simple, but it does seem to require a lot of boilerplate code to send/receive and store the value. And I would also need to figure out how to build the android app locally. -- You are receiving this mail because: You are watching all bug changes.
[kdeconnect] [Bug 469617] MPRIS receivers/controllers are ignoring playback rate to extrapolate current play position
https://bugs.kde.org/show_bug.cgi?id=469617 --- Comment #1 from Andy Holmes --- I'd like to put in my two cents here, having struggled with many players claiming MPRIS compliance. The reality is that there 1-2 players at any given time that correctly implement the full interface, especially when it comes to the playback position. It would very much preferable to just have clients update the position property more frequently in this case, rather than try to support more of the MPRIS interface explicitly. Playback rates other than 1.0 are pretty uncommon, usually only occur for short periods of time (i.e. seeking), and re-using the `pos` field would be backwards compatible. -- You are receiving this mail because: You are watching all bug changes.
