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.
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
There was a possibility of a dbz when a buffer sent to the
analyzer was shorter than 1ms long, such as what may happen at the end
of a track when stopping. This patch guards against this.
The chunks are now determined by the density of data in the buffer
to the length of audio in the buffer. The chunk length can change
size so that the audio that is analysed is exactly what is being played
at the instant the frame is requested.
The analyzers are sent new buffers of audio data to process each time
they pass through the gst pipeline. Different file formats and bit depths/
sample rates can change the size of these buffers, in some cases making them
large and therefore infrequent. This causes choppiness in the analyzer
as it is not getting new data with every frame. This patch chunks the buffers
coming off the pipeline to correspond with the framerate of the analyzer.
If "fade out on stop" is enabled, the "stop after this track" feature
would stop not stop the on current track, but instead start playing
the next track and fade out on that immediately. This patch disables
fadeout when the engine is stopped by HandleStopAfter().
This at least compiles against gstreamer 1.2.
Things that work:
* Playing audio
* Automatically completing tags
Things that don't work
* Spotify
* Moodbar
Things I haven't tested
* Transcoding
John Maguire
David Sansome
Chocobozzz
Andreas
Mark Furneaux
Arnaud Bienner
pie.or.paj
Marcus Fritzsch