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

Songs randomly play at wrong speed #1704

Open
raptor opened this issue Sep 22, 2018 · 11 comments

Comments

@raptor
Copy link

commented Sep 22, 2018

My setup:

  • Raspberry Pi 1B running latest Raspbian
  • Analog audio out to simple desktop speakers
  • Latest mopidy (see config and deps below)
    mopidy_config.txt
    mopidy_deps.txt
  • Using mopidy-file to browse to a network share and load songs in a queue
  • Control through Musicbox-Webclient

Songs will randomly play at the wrong speed, usually slow. So far I've noticed fast playback with .m4a (which I may have fixed with a different decoder) but more frequently slow play back with .mp3. I'll update here if other types show the same problem now that I'm aware.

It happens somewhat randomly and it frequently fixes itself if I reset the song. It can happen at any time: the first time I use mopidy for the day, or in the middle of a queue.

This seems very similar to the issue mentioned here:
https://discourse.mopidy.com/t/audio-playback-at-wrong-speed/1987

Thanks!

@kingosticks

This comment has been minimized.

Copy link
Member

commented Jan 30, 2019

This sounds like it might be fixed by #1735 that'll be in the v2.2.3 release. Are you still seeing this issue, can you test this fix?

@BrainStone

This comment has been minimized.

Copy link

commented Aug 21, 2019

I can confirm that on 2.2.3 this issue is still present.

For me it's mainly .m4a files playing too fast.

@kingosticks

This comment has been minimized.

Copy link
Member

commented Aug 21, 2019

Can you provide your mopidy deps please. This is likely to be a Gstreamer issue. If you could isolate which formats that would also help narrow it down to Gstreamer or not.

@kingosticks

This comment has been minimized.

Copy link
Member

commented Aug 21, 2019

It would also be interesting to know if its ever an issue for the first track you play, or only a problem for subsequent tracks. And if issuing a stop command has any effect.

@BrainStone

This comment has been minimized.

Copy link

commented Aug 21, 2019

mopidyctl stop:

Running "/usr/bin/mopidy --config /usr/share/mopidy/conf.d:/etc/mopidy/mopidy.conf deps" as user mopidy
/usr/lib/python2.7/dist-packages/mopidy/ext.py:202: PkgResourcesDeprecationWarning: Parameters to load are deprecated.  Call .resolve and .require separately.
  extension_class = entry_point.load(require=False)
Executable: /usr/bin/mopidy
Platform: Linux-4.19.58-v7+-armv7l-with-debian-10.0
Python: CPython 2.7.16 from /usr/lib/python2.7
Mopidy: 2.2.3 from /usr/lib/python2.7/dist-packages
Mopidy-ALSAMixer: 1.1.1 from /usr/lib/python2.7/dist-packages
Mopidy-Iris: 3.39.0 from /usr/local/lib/python2.7/dist-packages
  ConfigObj>=5.0.6: 5.0.6 from /usr/local/lib/python2.7/dist-packages
    six: 1.12.0 from /usr/lib/python2.7/dist-packages
  requests>=2.0.0: 2.21.0 from /usr/lib/python2.7/dist-packages
  Mopidy-Local-Images>=1.0: 1.0.0 from /usr/local/lib/python2.7/dist-packages
    setuptools: 40.8.0 from /usr/lib/python2.7/dist-packages
    Pykka>=1.1: 1.2.1 from /usr/lib/python2.7/dist-packages
    uritools>=1.0: 2.2.0 from /usr/lib/python2.7/dist-packages
      ipaddress: 1.0.17 from /usr/lib/python2.7/dist-packages
    Mopidy>=1.1: 2.2.3 from /usr/lib/python2.7/dist-packages
  tornado<5.0,>=3.2: 4.5.3 from /usr/local/lib/python2.7/dist-packages
    backports-abc>=0.4: 0.5 from /usr/lib/python2.7/dist-packages
    singledispatch: 3.4.0.3 from /usr/lib/python2.7/dist-packages
      six: 1.12.0 from /usr/lib/python2.7/dist-packages
    certifi: 2018.8.24 from /usr/lib/python2.7/dist-packages
  setuptools>=3.3: 40.8.0 from /usr/lib/python2.7/dist-packages
  Mopidy>=2.0: 2.2.3 from /usr/lib/python2.7/dist-packages
Mopidy-Local-SQLite: 1.0.0 from /usr/lib/python2.7/dist-packages
Mopidy-Youtube: 2.0.0 from /usr/lib/python2.7/dist-packages
  requests>=2.2.1: 2.21.0 from /usr/lib/python2.7/dist-packages
  pafy>=0.3.35: 0.5.4 from /usr/local/lib/python2.7/dist-packages
  Mopidy>=1.0: 2.2.3 from /usr/lib/python2.7/dist-packages
  Pykka>=1.1: 1.2.1 from /usr/lib/python2.7/dist-packages
Mopidy-TuneIn: 0.4.1 from /usr/lib/python2.7/dist-packages
Mopidy-Local-Images: 1.0.0 from /usr/local/lib/python2.7/dist-packages
  setuptools: 40.8.0 from /usr/lib/python2.7/dist-packages
  Pykka>=1.1: 1.2.1 from /usr/lib/python2.7/dist-packages
  uritools>=1.0: 2.2.0 from /usr/lib/python2.7/dist-packages
    ipaddress: 1.0.17 from /usr/lib/python2.7/dist-packages
  Mopidy>=1.1: 2.2.3 from /usr/lib/python2.7/dist-packages
GStreamer: 1.14.4.0 from /usr/lib/python2.7/dist-packages/gi
  Detailed information:
    Python wrapper: python-gi 3.30.4
    Relevant elements:
      Found:
        uridecodebin
        souphttpsrc
        appsrc
        alsasink
        osssink
        oss4sink
        pulsesink
        id3demux
        id3v2mux
        lamemp3enc
        mpegaudioparse
        mpg123audiodec
        vorbisdec
        vorbisenc
        vorbisparse
        oggdemux
        oggmux
        oggparse
        flacdec
        flacparse
        shout2send
      Not found:
        flump3dec
        mad

From what I've experienced it's never the first track but only subsequent tracks. As restarting (with state saving enabled) fixes it.

I currently don't have access to the server to test stop. stop would also clear my queue, right?
So you'd want me to get it to play faster, then stop and play the same song again?

@kingosticks

This comment has been minimized.

Copy link
Member

commented Aug 21, 2019

From what I've experienced it's never the first track but only subsequent tracks.

Thanks, that's interesting.

stop would also clear my queue, right

No, Mopidy's core.playback.stop() does not clear the tracklist. Some webclients decide to do this extra action themselves. mpc doesn't suffer from that so you can just do mpc stop. I guess if your client does clear the tracklist on stop then it should be fine to just re-add all the tracks. I'm just trying to see if clearing down the playbin state (via stop) always makes things work again.

So if you get it to play faster, then stop, and then play the song that was being played too fast.

@BrainStone

This comment has been minimized.

Copy link

commented Aug 23, 2019

Stopping and then playing again fixes it. (temporarily)

Edit: Would it help if I could provide you with files that allow to reproduce the issue? (I wouldn't feel comfortable uploading them publically but I surely can give you a link in private)

@kingosticks

This comment has been minimized.

Copy link
Member

commented Aug 23, 2019

OK sure. Send me an email or a private message on the forum.

@BrainStone

This comment has been minimized.

Copy link

commented Aug 23, 2019

Sent a few files via DM on the forums.

@BrainStone

This comment has been minimized.

Copy link

commented Aug 26, 2019

Did the files help?
And also did you download them? So I can remove the share.

@kingosticks

This comment has been minimized.

Copy link
Member

commented Aug 28, 2019

So I see from your files that the two 'Centipede' tracks have 48k sample rate and the other two are 44.1k. You can imagine if there is some bug where the new sample rate isn't set properly you'd get the effect described here. The problem for me right now is that I can't reproduce it on my Ubuntu desktop with Gstreamer 1.15.90.0 and Pulseaudio.

I can reproduce it on Raspbian (GStreamer: 1.14.4.0 and ALSA).

The next step is to try and find the difference between playing the different tracks back-to-back compared with stopping between them. GST_DEBUG=5 gives you that log, but it's a mission to go through it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
3 participants
You can’t perform that action at this time.