There are a number of cases where gst_pipeline_get_bus,
gst_element_get_static_pad, and g_object_get are called without releasing
references. In addition to memory usage, some of these elements hold file
descriptors. In normal operation, two file descriptors are leaked for each
played track. The default fd ulimit for many linux distros is 1024. This
is likely the cause of the crash reported in issue 6309.
This change fixes the obvious and consistent leaks, but it's probably not a
complete solution. There are many error and corner conditions that need to be
examined.
In the case that an error occurs in ReplaceDecodeBin before the bin is added to
the pipeline, unreference the object to allow cleanup. This change also separates
CreateDecodeBinFromUrl from ReplaceDecodeBin, following the pattern of
CreateDecodeBinFromString.
If ReplaceDecodeBin fails from TransitionToNext, uridecodebin_ will not be
replaced with a new element. Since TransitionToNext does not check the return
value, it unknowingly deletes uridecodebin_.
When switching between tracks with different sample rates, the probe queue blocks before the pipeline can emit EOS.
This prevents the track change from proceeding without manual intervention. This appears to be because the queue
element doesn't handle the rate change correctly (either due to buffer length, or cap negotiation).
The queue2 element however does handle this without blocking indefinitely.
Let's the user see the error message what failed instead of Clementine crashing.
Also don't do gst_object_unref unless bin is set.
This fixes GStreamer-CRITICAL gst_object_unref: assertion 'object != NULL' failed
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 functional but pretty hacky.
And, as noted in the comments, there is a small delay (depends, but usually several seconds) to have the seek taken into account. But IMHO it's better than nothing.
Fixes#2503
luz.paz
Jim Broadus
Jonas Kvinge
Eoin O'Neill
Mark Furneaux
Santiago Gil
John Maguire
Arnaud Bienner
Andreas
Krzysztof Sobiecki
Chocobozzz
David Sansome
Andreas
pie.or.paj
Marcus Fritzsch