When the network connection changes while playing an HTTP stream, I always get the "Server does not support seeking." error from GStreamer.
It seems like GStreamer tries to seek on reconnect, which fails, an propagates the error to Clementine which in turn ceases playback with
the error message handed through from GStreamer, even though there is now a perfectly fine network connection again.
As a workaround, try to reload the stream when this error occurs.
fixes#5116
In the new version of gstreamer, alsasink supports floating samples, so it seems to be bypassing audioconvert.
Integer samples make downmixing work correctly.
Fixes#1747
The pipeline has the caps for the analyzer applied in the wrong place. This results in the audio output being limited to 16 bit regardless of the input file.
This change also cleans up the mono/sample rate caps as well.
Two problems here:
- the first was that "StartPlaybackLater" wasn't called from the thread which created SpotifyServer, so the timer never started.
- then the playback sometimes failed or started with an offset: just hack to ignore sourcedrained signal in this case.
This change provides the ability to set a fixed pipeline sample rate as an alternate to automatically negotiating it.
This can be useful on systems with sound cards that work at a fixed rate, as well as it can triage issues (on Windows)
where changing tracks hangs due to a problem with gstreamer's caps negotiation.
Gstreamer was failing to link the pipeline if 32bit could not be enabled.
We should just let gst autonegotiate the bit depth of the pipeline, which it does with mono disabled anyways.
Spotify doesn't work with this fix anymore, gstreamer throws `gst_segment_to_stream_time: assertion 'segment->format == format' failed`. Using `audio/*` for caps doesn't work either, the channes property is ignored. An `if (url_.scheme == "spotify")` would work, but maybe there is a more elegant solution.
This reverts commit 8799222d64.
SourceDrainedCallback() has a valid next url and calls TransitionToNext(). This sets a new decode bin for the pipeline. The pipeline then buffers the new track and sends GST_MESSAGE_BUFFERING. BufferingMessageReceived() then pauses the pipeline because it's buffering. But we are buffering the next track and not the current one, so the pipeline has still data and doesn't need to be paused.
This is a regression in the upgrade to gstreamer1.0.
The gst_buffer_unref() is incorrect as it removes the buffer when it is still needed by the chunker.
Forcing the pointer to be null prevents it from segfaulting but causes it to skip all chunks in the buffer, dropping the framerate and causing a worse case of #4321.
Removing these 2 lines restores original functionality.
- Rewrite gstspectrum (1.0) to use FFTW (2x faster) and emit raw magnitude
values (not log scaled).
- Rewrite the moodbar generation code to be somewhat understandable, and
do it in Clementine instead of gstreamer.
benpicco
Santiago Gil
Mark Furneaux
John Maguire
Arnaud Bienner
Eduardo Sánchez Muñoz
Mark Furneaux
Andreas
Krzysztof Sobiecki
David Sansome
Chocobozzz
Andreas