Requires YAJL to build, and this doesn't include the necessary
automake changes. Can be built using
./configure CFLAGS="-I/usr/include/yajl" LIBS="-lyajl" --enable-soundcloud
Add the following to your config:
playlist_plugin {
name "soundcloud"
enabled "true"
apikey "c4c979fd6f241b5b30431d722af212e8"
}
Then you can stream from soundcloud using calls like:
mpc load soundcloud://track/<track-id>
mpc load soundcloud://playlist/<playlist-id>
mpc load soundcloud://url/http://soundcloud.com/some/track/or/playlist
For the last case, you can leave off the http:// or
http://soundcloud.com/ .
Add GMutex, GCond attributes which will be used by callers to
conditionally wait on the stream.
Remove the (now-useless) plugin method buffer(), wait on GCond
instead. Lock the input_stream before each method call. Do the same
with the playlist plugins.
For spotify playlists or tracks. Uses a spt uri, so with mpc you can
add playlists with
mpc load spt://spotify:user:simon.kagstrom:playlist:3SUwkOe5VbVHysZcidEZtH
libcue's track_get_length() returns 0 for the last track, because that
information is not available in the CUE sheet. This makes MPD quit
playing the last track immediately. If we set "song.end_ms=0", MPD
will play the track until the end of the song file, which is what we
want.
.. rather then append to the end of the previous one
Cuebreakpoints from the cuetools package has three modes of operation,
and the default is to append pregap (INDEX 00) to the end of the
previous track. This is the behavior most compliant to the existing
cue files.
Here is the patch which fixes the issue. I borrowed bits of
implementation from cuebreakpoints. I assumed that the whole audio
file must be covered by head-to-head going tracks, which is how
hardware CD players probably work. In cue_tag I changed rounding from
rounding up to rounding down because the thing in mpd which calculates
actual track duration (and current position) rounds it down, and I
didn't want to see in my playlist values different from whose in a
now-playing progress bar.
I've compared the resultant mpd behaviour with "mplayer -ss MM:SS.MS"
where the time was supplied by cuebreakpoints and noticed that mplayer
started each track a bit earlier then mpd, though this was the same
before the patch.
