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.
