Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

bpd plugin should return integer times for status command #2394

Closed
arcresu opened this issue Jan 17, 2017 · 1 comment
Closed

bpd plugin should return integer times for status command #2394

arcresu opened this issue Jan 17, 2017 · 1 comment

Comments

@arcresu
Copy link
Member

arcresu commented Jan 17, 2017

Beets' bpd plugin should return integer values for the time field of the status command, and indeed this is what the code comments claim it is doing (from gstplayer.py#L170-L188):

    def time(self):
        """Returns a tuple containing (position, length) where both
        values are integers in seconds. If no stream is available,
        returns (0, 0).
        """
        fmt = Gst.Format(Gst.Format.TIME)
        try:
            posq = self.player.query_position(fmt)
            if not posq[0]:
                raise QueryError("query_position failed")
            pos = posq[1] / (10 ** 9)

            lengthq = self.player.query_duration(fmt)
            if not lengthq[0]:
                raise QueryError("query_duration failed")
            length = lengthq[1] / (10 ** 9)

            self.cached_time = (pos, length)
            return (pos, length)
    # ...

However this file has from __future__ import division, and both pos and length are the result of division operations, and so neither are integers. Any clients connecting to bpd's mpd server are getting values for status.time like 71.165973:97.893333333.

It turns out that most clients can cope with this just fine, but at least one crashes since it expects an integer. The mpd protocol does seem to require integers, at least that's what the reference implementation does.

@sampsyo
Copy link
Member

sampsyo commented Jan 17, 2017

Thank you for pointing this out! Looks like we forgot to update the operators when we added from __future__ import division. Just pushed a fix in 958ad43.

@sampsyo sampsyo closed this as completed Jan 17, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants