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

Some songs produce silence #213

Closed
mrvanes opened this Issue Oct 10, 2012 · 16 comments

Comments

3 participants
@mrvanes

mrvanes commented Oct 10, 2012

I played the Album "Toto" by Toto the other day and four of the songs on that album didn't play (the progress bar in my webclient moves but there's only silence). These songs play normal in the desktop client Clementine. The songs are:

  • I'll supply the love
  • Georgy Porgy
  • You are the flower
  • Angela

The error in the mopidy log on all four:

ERROR    GStreamer encountered a general stream error. gstbasesrc.c(2550):
gst_base_src_loop (): /GstPlayBin2:playbin20/GstURIDecodeBin:uridecodebin0/GstAppSrc:source:
streaming task paused, reason not-negotiated (-4)
@jodal

This comment has been minimized.

Member

jodal commented Oct 10, 2012

@adamcik Could this be caused by audio data not matching the caps set on the appsrc?

@adamcik

This comment has been minimized.

Member

adamcik commented Oct 10, 2012

To be honest I was kinda waiting for this. Yes, I believe that would be the cause. I saw it happen a few times, but had trouble reproducing it.

@mrvanes

This comment has been minimized.

mrvanes commented Oct 14, 2012

I now seem to encounter this problem with nearly half of the songs played and seems to be related to the 0.8.0 update?

@jodal

This comment has been minimized.

Member

jodal commented Oct 23, 2012

I didn't manage to reproduce by playing that album using Mopidy 0.8.0-80-g893efe4. At least, the first track and "I'll supply the love" played without problems. I assume you don't see different behavior depending on clients any longer, and that the sole difference was the upgrade to Mopidy 0.8.0?

@mrvanes

This comment has been minimized.

mrvanes commented Oct 24, 2012

What I noticed in clients (RompR webclient e.g.) that the time increases while playing a song that fails, but it never ends. So that might be a piece of Javascript that just foolishly assumes it's tracking whatever is not playing. I don't know enough about the mpd protocol to know whether there's synchronisation of time played to the client?
Apart from that, yes, the problems seem to have started after the 0.8.0 upgrade.

I just tried to replay the offending songs and this is what I get:

WARNING  There is no codec present that can handle the stream's type. gsturidecodebin.c(712): unknown_type_cb (): /GstPlayBin2:playbin20/GstURIDecodeBin:uridecodebin39
ERROR    Your GStreamer installation is missing a plug-in. gstdecodebin2.c(3076): gst_decode_bin_expose (): /GstPlayBin2:playbin20/GstURIDecodeBin:uridecodebin39/GstDecodeBin2:decodebin239:

After reinstalling gstreamer-plugins-ugly (and playing the offending song) I see again:

ERROR    GStreamer encountered a general stream error. gstbasesrc.c(2550): gst_base_src_loop (): /GstPlayBin2:playbin20/GstURIDecodeBin:uridecodebin0/GstAppSrc:source:
streaming task paused, reason not-negotiated (-4)

I replayed the whole excersise with debugging on, and this is the log from the point where I play the silent song:
git://gist.github.com/3944482.git

Maybe there's a relation with the fact that gstreamer thinks I need gstreamer-plugins-ugly to play the song? Are some spotify songs encoded using different codecs? I can't believe that?

Hope this helps.

@mrvanes

This comment has been minimized.

mrvanes commented Oct 24, 2012

About the exact version of mopidy: I can't be sure, but maybe this helps:

INFO     Starting Mopidy 0.8.0
INFO     Platform: Linux-3.5.3-i686-with-debian-6.0.6
INFO     Python: CPython 2.6.6
INFO     Mopidy uses SPOTIFY(R) CORE
INFO     Output set to alsasink device=dmyxer_vlc
INFO     MPD server running at [pandora]:6600
INFO     Disabled: mopidy.frontends.lastfm.LastfmFrontend (No module named pylast)
INFO     Disabled: mopidy.frontends.mpris.MprisFrontend (No module named dbus)
INFO     Mixer set to alsamixer using track called Master
INFO     Connected to Spotify
INFO     Loaded 1 Spotify playlist(s)
INFO     New MPD connection from [192.168.1.10]:58379

I installed the debian packages you conveniently supply.

@mrvanes

This comment has been minimized.

mrvanes commented Oct 24, 2012

I can confirm I have no problems playing these songs in 0.7.3-6 (debian packages).

@jodal

This comment has been minimized.

Member

jodal commented Oct 24, 2012

Ok, thanks. I'm working on a patch I'd like you to try when I have it working, since I can't reproduce this myself.

@jodal

This comment has been minimized.

Member

jodal commented Oct 24, 2012

Can you try applying this patch, and see if it resolves the problem?

The patch readds some code that was included in 0.7.3, but was removed when we switched to using Gstreamer's playbin2 element in 0.8.0.

diff --git a/mopidy/audio/__init__.py b/mopidy/audio/__init__.py
index df5efb9..8ad8811 100644
--- a/mopidy/audio/__init__.py
+++ b/mopidy/audio/__init__.py
@@ -70,6 +70,11 @@ class Audio(ThreadingActor):
         fakesink = gst.element_factory_make('fakesink')
         self._playbin.set_property('video-sink', fakesink)

+        self._playbin.connect('source-setup', self._setup_source)
+
+    def _setup_source(self, playbin, source):
+        source.set_property('caps', self._default_caps)
+
     def _teardown_playbin(self):
         self._playbin.set_state(gst.STATE_NULL)
@mrvanes

This comment has been minimized.

mrvanes commented Oct 24, 2012

# mopidy
INFO     Starting Mopidy 0.8.0
INFO     Platform: Linux-3.5.3-i686-with-debian-6.0.6
INFO     Python: CPython 2.6.6
INFO     Mopidy uses SPOTIFY(R) CORE
Exception in thread PykkaActorThread-1:
Traceback (most recent call last):
  File "/usr/lib/python2.6/threading.py", line 532, in __bootstrap_inner
    self.run()
  File "/usr/lib/pymodules/python2.6/pykka/actor.py", line 300, in run
    return Actor._run(self)
  File "/usr/lib/pymodules/python2.6/pykka/actor.py", line 169, in _run
    self.on_start()
  File "/usr/lib/pymodules/python2.6/mopidy/audio/__init__.py", line 54, in on_start
    self._setup_playbin()
  File "/usr/lib/pymodules/python2.6/mopidy/audio/__init__.py", line 73, in _setup_playbin
    self._playbin.connect('source-setup', self._setup_source)
TypeError: <__main__.GstPlayBin2 object (playbin20) at 0x85583c4>: unknown signal name: source-setup

INFO     MPD server running at [pandora]:6600
INFO     Disabled: mopidy.frontends.lastfm.LastfmFrontend (No module named pylast)
INFO     Disabled: mopidy.frontends.mpris.MprisFrontend (No module named dbus)
^CINFO     Interrupted. Exiting...
@jodal

This comment has been minimized.

Member

jodal commented Oct 24, 2012

Guess I got newer GStreamer than you (running Ubuntu 12.10). I'll make an updated patch which does this the old way... give me a few minutes :-)

@jodal

This comment has been minimized.

Member

jodal commented Oct 24, 2012

Try this one:

diff --git a/mopidy/audio/__init__.py b/mopidy/audio/__init__.py
index df5efb9..88c62c0 100644
--- a/mopidy/audio/__init__.py
+++ b/mopidy/audio/__init__.py
@@ -70,6 +70,12 @@ class Audio(ThreadingActor):
         fakesink = gst.element_factory_make('fakesink')
         self._playbin.set_property('video-sink', fakesink)

+        self._playbin.connect('notify::source', self._on_new_source)
+
+    def _on_new_source(self, element, pad):
+        source = element.get_property('source')
+        source.set_property('caps', self._default_caps)
+
     def _teardown_playbin(self):
         self._playbin.set_state(gst.STATE_NULL)
@mrvanes

This comment has been minimized.

mrvanes commented Oct 24, 2012

The last patch applies cleanly and fixes the problem.
Thx!

@jodal

This comment has been minimized.

Member

jodal commented Oct 24, 2012

@mrvanes Great! :-)

@adamcik Do you see any problems with reintroducing this approximately as in the above patch? Could this affect local file playback negatively?

@adamcik

This comment has been minimized.

Member

adamcik commented Oct 24, 2012

Hmm, it might effect i negatively, should be easy to test. To play it safe I might want to guard it with a uri.startswith('appsrc://').

@jodal

This comment has been minimized.

Member

jodal commented Oct 24, 2012

Seems to work nicely on the local backend with the URI guard. Haven't tested without an URI guard. I'll let the guard stay there, as this change is specific to Spotify and not wanted for local file playback even if it may work.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment