unstable HTTP streaming

Need help with MPD?
Post Reply
pierrepoulpe
Posts: 11
Joined: October 10th, 2014, 8:58 am

unstable HTTP streaming

Post by pierrepoulpe » October 10th, 2014, 9:45 am

Hi Guys,


My mpd has troubles to play http streams (audio format flac 2*44100*16bits, from qobuz.com : my music provider).

It sounds like if http stream were overfilling a buffer, because it's not a problem of stream pausing and starting again, but sounds more like a "fast forward". It works very badly at the start of the stream and then it becomes better, almost stable at the middle of the track.

- It was working very fine for ... over a year on my previous debian squeeze / mpd 0.16.0 localy compiled
- I tried the standard 0.16.x debian package (squeeze), 0.17.x debian testing, and I compiled last 0.18.16
- I tried to increase curl buffer in sources before compiling :

src/input/CurlInputPlugin.cxx

Code: Select all

static const size_t CURL_MAX_BUFFERED = 2048 * 1024;

/**
 * Resume the stream at this number of bytes after it has been paused.
 */
static const size_t CURL_RESUME_AT = 1536 * 1024;
- I tried to play a flac file hosted on my personal website : works fine. So I suspect an issue that is dependant of http server parameters (chunk size for instance?). qobuz.com uses IIS 7.5, my host service I think apache.

- When running mpd interactively (--stdout --no-daemon --verbose )
I see a lot of error with flac plugin timely corresponding with audible issue, but nothing about curl.
See here :
http://paste.debian.net/125489/

- local files run smoothly

- Qobuz server responsiveness is not suspect to me, I never had a bufer underrun for over a year with mpd 0.16. Downloading the stream is saturating my DSL line (1.6 MB/S while flac need <100KB/s). No such problem when using their player.



So :
Could you confirm me that it's libcurl that is used to get http stream?
Where are the buffers? Internal curl buffer? mpd input buffer? mpd output buffer?
How can I debug/monitor those different buffers status?
Any idea?

Many thanks for any input,

max
Forum team
Posts: 673
Joined: January 15th, 2013, 3:43 pm

Re: unstable HTTP streaming

Post by max » October 10th, 2014, 5:02 pm

Looks like the stream is corrupt and it's not MPD's fault. If you disagree, say why you are sure.

pierrepoulpe
Posts: 11
Joined: October 10th, 2014, 8:58 am

Re: unstable HTTP streaming

Post by pierrepoulpe » October 10th, 2014, 5:40 pm

a/ It was working perfectly fine right before migrating my server from squeeze/mpd 0.16 to wheezy mpd 0.{16,17,18}
b/ Downloading the URL with wget (or any browser) gives a correct file.

Unfortunately, URLs are generated on the fly from their API, and are not valid a few minutes/hours after, and even not from another computer (check with IP I think)

This is why I would prefer some help to debug deeper, and eventually give the devs a reproducible procedure when I understand the problem.

max
Forum team
Posts: 673
Joined: January 15th, 2013, 3:43 pm

Re: unstable HTTP streaming

Post by max » October 10th, 2014, 7:08 pm

What makes you so sure the server will give you the same data with "wget"? Many streaming servers send different data depending on the client.

max
Forum team
Posts: 673
Joined: January 15th, 2013, 3:43 pm

Re: unstable HTTP streaming

Post by max » October 10th, 2014, 7:09 pm

Oh, and you upgraded your whole operating system. The bug may or may not be in libFLAC or some other library you upgraded. Are you really sure that MPD is to blame, or was this just a random guess?

pierrepoulpe
Posts: 11
Joined: October 10th, 2014, 8:58 am

Re: unstable HTTP streaming

Post by pierrepoulpe » October 10th, 2014, 8:11 pm

While I don't have an absolute evidence against mpd, it is at the center of the story.

But I need to investigate deeper. It's why my questions were :
- Could you confirm that libcurl is responsible of getting data from http ?
- How many different buffers are involved in the process?
I know two of them, output buffer, and input curl buffer. Any other?
- Who is allocating memory for these buffers? Who is responsible to not overfill the buffer? libcurl or mpd?
- How to monitor the status of these buffers?

I can confirm with network packet capture that the server is sending the full flac file with no corruption. I need to install tshark or so..

Local flac files are working fine. Isn't it the same libflac involved in this case?

pierrepoulpe
Posts: 11
Joined: October 10th, 2014, 8:58 am

Re: unstable HTTP streaming

Post by pierrepoulpe » October 10th, 2014, 8:24 pm

From the same machine, same URL :
$ mpc clear
volume:100% repeat: off random: off single: off consume: off
$ mpc add "http://streaming.qobuz.com:80/file?uid= ... Oecjm4bQ4g"
$ mpc play

play very badly first 30 seconds.

$ curl "http://streaming.qobuz.com:80/file?uid= ... Oecjm4bQ4g" >> out2.flac && flac -cd out2.flac | aplay
works perfectly. Curl is supposed to be based on libcurl.
I didn't manage to redirect curl stdout to flac stdin. In fact flac seems to accept only wav for compression as stdin, not flac for decode.

pierrepoulpe
Posts: 11
Joined: October 10th, 2014, 8:58 am

Re: unstable HTTP streaming

Post by pierrepoulpe » October 13th, 2014, 11:00 pm

Ok, I added some debug watchpoint in the code :

CurlInputPlugin.cxx

in input_curl_easy_init()

Code: Select all

        curl_easy_setopt(c->easy, CURLOPT_VERBOSE, true);

        LogWarning(curl_domain,"---PBK kill debugflac"); // PBK
        remove("/tmp/flacDebug.flac");
and in input_curl_writefunction()

Code: Select all

        //PBK
        flacDebug = fopen("/tmp/flacDebug.flac","a+");
        fwrite(ptr, size, nmemb, flacDebug); 
        fclose(flacDebug);
        // /PBK


        size *= nmemb;
        if (size == 0)
                return 0;

        const ScopeLock protect(c->base.mutex);

        if (curl_total_buffer_size(c) + size >= CURL_MAX_BUFFERED) {
                LogWarning(curl_domain,"---PBK input_curl_writefunction -> pause\n"); // PBK
                c->paused = true;
                return CURL_WRITEFUNC_PAUSE;
        }

Code: Select all

client: [0] process command "add "http://streaming.qobuz.com:80/file?uid=15924&eid=4305351&fmt=6&app_id=923032952&cid=210239&etsp=1413244332&hmac=N4yN241IDREnYZse0LssZnNcl2k""
playlist: add to playlist: http://streaming.qobuz.com:80/file?uid=15924&eid=4305351&fmt=6&app_id=923032952&cid=210239&etsp=1413244332&hmac=N4yN241IDREnYZse0LssZnNcl2k
client: [0] command returned 0
client: [0] process command "play"
playlist: play 0:"http://streaming.qobuz.com:80/file?uid=15924&eid=4305351&fmt=6&app_id=923032952&cid=210239&etsp=1413244332&hmac=N4yN241IDREnYZse0LssZnNcl2k"
curl: ---PBK kill debugflac
* Couldn't find host streaming.qobuz.com in the .netrc file; using defaults
* About to connect() to streaming.qobuz.com port 80 (#0)
*   Trying 79.143.255.10...
* 0x1195608 is at send pipe head!
* STATE: CONNECT => WAITCONNECT handle 0x117ccd0; (connection #0) 
client: [0] command returned 0
client: [0] closed
* Connected to streaming.qobuz.com (79.143.255.10) port 80 (#0)
* Connected to streaming.qobuz.com (79.143.255.10) port 80 (#0)
* STATE: WAITCONNECT => DO handle 0x117ccd0; (connection #0) 
> GET /file?uid=15924&eid=4305351&fmt=6&app_id=923032952&cid=210239&etsp=1413244332&hmac=N4yN241IDREnYZse0LssZnNcl2k HTTP/1.1
User-Agent: Music Player Daemon 0.18.16
Host: streaming.qobuz.com
Accept: */*
Icy-Metadata: 1

* STATE: DO => DO_DONE handle 0x117ccd0; (connection #0) 
* STATE: DO_DONE => WAITPERFORM handle 0x117ccd0; (connection #0) 
* STATE: WAITPERFORM => PERFORM handle 0x117ccd0; (connection #0) 
* additional stuff not fine transfer.c:1037: 0 0
* HTTP 1.1 or later with persistent connection, pipelining supported
< HTTP/1.1 200 OK
< Cache-Control: private
< Content-Length: 17321244
< Content-Type: audio/flac
< Last-Modified: Sun, 02 Oct 2011 11:01:30 GMT
< Accept-Ranges: bytes
< Server: Microsoft-IIS/7.5
< X-AspNet-Version: 4.0.30319
< X-Powered-By: ASP.NET
< X-Endpoint: 4
< Date: Mon, 13 Oct 2014 22:52:11 GMT
< 
decoder_thread: probing plugin flac
decoder: audio_format=44100:16:2, seekable=true
flac: FLAC__STREAM_DECODER_ERROR_STATUS_LOST_SYNC
flac: FLAC__STREAM_DECODER_ERROR_STATUS_LOST_SYNC
flac: FLAC__STREAM_DECODER_ERROR_STATUS_BAD_HEADER
flac: FLAC__STREAM_DECODER_ERROR_STATUS_LOST_SYNC
flac: FLAC__STREAM_DECODER_ERROR_STATUS_BAD_HEADER
flac: FLAC__STREAM_DECODER_ERROR_STATUS_LOST_SYNC
flac: FLAC__STREAM_DECODER_ERROR_STATUS_BAD_HEADER
flac: FLAC__STREAM_DECODER_ERROR_STATUS_LOST_SYNC
flac: FLAC__STREAM_DECODER_ERROR_STATUS_BAD_HEADER
flac: FLAC__STREAM_DECODER_ERROR_STATUS_LOST_SYNC
flac: FLAC__STREAM_DECODER_ERROR_STATUS_BAD_HEADER
flac: FLAC__STREAM_DECODER_ERROR_STATUS_LOST_SYNC
flac: FLAC__STREAM_DECODER_ERROR_STATUS_BAD_HEADER
flac: FLAC__STREAM_DECODER_ERROR_STATUS_LOST_SYNC
flac: FLAC__STREAM_DECODER_ERROR_STATUS_BAD_HEADER
flac: FLAC__STREAM_DECODER_ERROR_STATUS_LOST_SYNC
flac: FLAC__STREAM_DECODER_ERROR_STATUS_BAD_HEADER
flac: FLAC__STREAM_DECODER_ERROR_STATUS_LOST_SYNC
flac: FLAC__STREAM_DECODER_ERROR_STATUS_BAD_HEADER
flac: FLAC__STREAM_DECODER_ERROR_STATUS_LOST_SYNC
flac: FLAC__STREAM_DECODER_ERROR_STATUS_LOST_SYNC
flac: FLAC__STREAM_DECODER_ERROR_STATUS_LOST_SYNC
flac: FLAC__STREAM_DECODER_ERROR_STATUS_BAD_HEADER
flac: FLAC__STREAM_DECODER_ERROR_STATUS_LOST_SYNC
flac: FLAC__STREAM_DECODER_ERROR_STATUS_LOST_SYNC
flac: FLAC__STREAM_DECODER_ERROR_STATUS_LOST_SYNC
flac: FLAC__STREAM_DECODER_ERROR_STATUS_LOST_SYNC
flac: FLAC__STREAM_DECODER_ERROR_STATUS_LOST_SYNC
flac: FLAC__STREAM_DECODER_ERROR_STATUS_LOST_SYNC
flac: FLAC__STREAM_DECODER_ERROR_STATUS_LOST_SYNC
flac: FLAC__STREAM_DECODER_ERROR_STATUS_LOST_SYNC
flac: FLAC__STREAM_DECODER_ERROR_STATUS_LOST_SYNC
client: [1] opened from [::1]:51563
client: [1] process command "stats"
client: [1] command returned 0
client: [1] process command "status"
client: [1] command returned 0
client: [1] process command "playlistinfo"
client: [1] command returned 0
client: [1] closed
alsa_output: opened hw:0,0 type=HW
alsa_output: format=S16_LE (Signed 16 bit Little Endian)
alsa_output: buffer: size=90..262144 time=2040..5944309
alsa_output: period: size=45..131072 time=1020..2972155
alsa_output: default period_time = buffer_time/4 = 500000/4 = 125000
alsa_output: buffer_size=22050 period_size=5513
output: opened plugin=alsa name="My ALSA Device" audio_format=44100:16:2
curl: ---PBK input_curl_writefunction -> pause
* Pausing with 1448 bytes in buffer for type 01
* additional stuff not fine transfer.c:1037: 0 0
curl: ---PBK input_curl_writefunction -> pause
* Pausing with 1448 bytes in buffer for type 01
^Cstate_file: Saving state file /var/lib/mpd/state
* Closing connection #0
player: played "http://streaming.qobuz.com:80/file?uid=15924&eid=4305351&fmt=6&app_id=923032952&cid=210239&etsp=1413244332&hmac=N4yN241IDREnYZse0LssZnNcl2k"
output: closed plugin=alsa name="My ALSA Device"
listen: listen_global_finish called
main: db_finish took 0.150000 seconds

Code: Select all

bk@NASBEF09C:~/mpd/mpd-0.18.16$ flac -cd /tmp/flacDebug.flac | aplay

flac 1.2.1, Copyright (C) 2000,2001,2002,2003,2004,2005,2006,2007  Josh Coalson
flac comes with ABSOLUTELY NO WARRANTY.  This is free software, and you are
welcome to redistribute it under certain conditions.  Type `flac' for details.

Lecture WAVE 'stdin' : Signed 16 bit Little Endian, Fréquence 44100 Hz, Stéréo
flacDebug.flac: 12% complete^CInterrompu par le signal Interrompre...


First : no buffer overrun, scratches occurs way before mpd has to say pause to curl.
Second : the flacDebug.flac file is perfect. So data are ok when curl submit it to mpd.

Now I have to understand the buffer mechanism to understand why data are corrupted inside mpd. Any idea before I spend time to investigate?

pierrepoulpe
Posts: 11
Joined: October 10th, 2014, 8:58 am

Re: unstable HTTP streaming

Post by pierrepoulpe » October 14th, 2014, 1:39 am

I repeated the same kind of buffer write in file, inside FlacInput::Read()
Data is ok until then...

So why libflac doesn't work with streams, while it works ok with file?

pierrepoulpe
Posts: 11
Joined: October 10th, 2014, 8:58 am

Re: unstable HTTP streaming

Post by pierrepoulpe » October 14th, 2014, 8:23 am

I put some watchpoints in curl read_from_buffer(), and FlacInput::Read().
At the beginning, when the first http packet arrived, there is only one packet to send to libflac.

Is it possible that libflac has not been designed to wait for more data before processing it? With file input, this is never happening.


My question : I'd like to modify CurlInputPlugin.cxx to wait a given amount of data in buffer, before starting to return it, let's say 10KB.
I tried a few options, but it's not working : blocking the process, or stopping the playback immediately.

What's the good way to implement that?

Code: Select all

playlist: play 0:"http://streaming.qobuz.com:80/file?uid=15924&eid=4305351&fmt=6&app_id=923032952&cid=210239&etsp=1413276210&hmac=DaRiNcRc1m-xQ9qH7hhXSeCM_K8"
curl: ---PBK kill debugflac
client: [4] command returned 0
client: [4] closed
* Couldn't find host streaming.qobuz.com in the .netrc file; using defaults
* About to connect() to streaming.qobuz.com port 80 (#0)
*   Trying 79.143.255.10...
* 0x940f10 is at send pipe head!
* STATE: CONNECT => WAITCONNECT handle 0xb3e00468; (connection #0) 
* Connected to streaming.qobuz.com (79.143.255.10) port 80 (#0)
* Connected to streaming.qobuz.com (79.143.255.10) port 80 (#0)
* STATE: WAITCONNECT => DO handle 0xb3e00468; (connection #0) 
> GET /file?uid=15924&eid=4305351&fmt=6&app_id=923032952&cid=210239&etsp=1413276210&hmac=DaRiNcRc1m-xQ9qH7hhXSeCM_K8 HTTP/1.1
User-Agent: Music Player Daemon 0.18.16
Host: streaming.qobuz.com
Accept: */*
Icy-Metadata: 1

* STATE: DO => DO_DONE handle 0xb3e00468; (connection #0) 
* STATE: DO_DONE => WAITPERFORM handle 0xb3e00468; (connection #0) 
* STATE: WAITPERFORM => PERFORM handle 0xb3e00468; (connection #0) 
* additional stuff not fine transfer.c:1037: 0 0
* HTTP 1.1 or later with persistent connection, pipelining supported
< HTTP/1.1 200 OK
< Cache-Control: private
< Content-Length: 17321244
< Content-Type: audio/flac
< Last-Modified: Sun, 02 Oct 2011 11:01:30 GMT
< Accept-Ranges: bytes
< Server: Microsoft-IIS/7.5
< X-AspNet-Version: 4.0.30319
< X-Powered-By: ASP.NET
< X-Endpoint: 3
< Date: Tue, 14 Oct 2014 07:43:30 GMT
< 
decoder_thread: probing plugin flac
curl: read_from_buffer, requested 8192
curl: reead_from_buffer, returned 1154
flac: FlacInput::Read() 1154
curl: read_from_buffer, requested 8190
curl: reead_from_buffer, returned 1448
flac: FlacInput::Read() 1448
decoder: audio_format=44100:16:2, seekable=true
curl: read_from_buffer, requested 8190
curl: reead_from_buffer, returned 1448
flac: FlacInput::Read() 1448
flac: flac input error
flac: FLAC__STREAM_DECODER_ERROR_STATUS_LOST_SYNC
flac: flac input error
flac: FLAC__STREAM_DECODER_ERROR_STATUS_LOST_SYNC
flac: flac input error
flac: FLAC__STREAM_DECODER_ERROR_STATUS_BAD_HEADER
flac: flac input error
flac: FLAC__STREAM_DECODER_ERROR_STATUS_LOST_SYNC
flac: flac input error
flac: FLAC__STREAM_DECODER_ERROR_STATUS_BAD_HEADER
flac: flac input error
flac: FLAC__STREAM_DECODER_ERROR_STATUS_LOST_SYNC
flac: flac input error
flac: FLAC__STREAM_DECODER_ERROR_STATUS_BAD_HEADER
flac: flac input error
flac: FLAC__STREAM_DECODER_ERROR_STATUS_LOST_SYNC
flac: flac input error
flac: FLAC__STREAM_DECODER_ERROR_STATUS_BAD_HEADER
flac: flac input error
flac: FLAC__STREAM_DECODER_ERROR_STATUS_LOST_SYNC
flac: flac input error
flac: FLAC__STREAM_DECODER_ERROR_STATUS_BAD_HEADER
flac: flac input error

pierrepoulpe
Posts: 11
Joined: October 10th, 2014, 8:58 am

Re: unstable HTTP streaming

Post by pierrepoulpe » October 16th, 2014, 9:36 am

I managed to make a modification to prefill buffer before starting the decode :
In CurlInputPlugin.cxx

added a started bool on input_curl struct.

Code: Select all

struct input_curl {
....
        //PBK
        bool started;
....
        input_curl(const char *url, Mutex &mutex, Cond &cond)
                :base(input_plugin_curl, url, mutex, cond),
                 request_headers(nullptr),
                 paused(false),
                 tag(nullptr),
                started(false) {}*
....
And

Code: Select all

static bool
fill_buffer(struct input_curl *c, Error &error)
{
        while (c->easy != nullptr && c->buffers.empty())
                c->base.cond.wait(c->base.mutex);


        if (c->postponed_error.IsDefined()) {
                error = std::move(c->postponed_error);
                c->postponed_error.Clear();
                return false;
        }

        //ADDED FOR PREFILL
        if (!c->buffers.empty())
                while (curl_total_buffer_size(c) < CURL_RESUME_AT && !c->started)
                        c->base.cond.wait(c->base.mutex);
        c->started = true;
        // /ADDED

        return !c->buffers.empty();
}
Quick and dirty... no timeout, not tolerant to a server that don't reply, etc...

Anyway, it works - much - better. But not perfectly : 9 tracks out of 10 play smoothly, without it was more 1 out of 20.

I will look on flac side. I'll try to write a small test program simulating the return of irregular small chunks, see if I can reproduce, and ask on flac devel mailing list what do they think about that.
Note that debian wheezy is supplied with flac 1.3.0, which the latest (may 2013) stable release from flac dev team. No new release nor beta version. I think we can consider flac as mature...

I'll also try to install flac 1.2, the version that were one debian squeeze.

pierrepoulpe
Posts: 11
Joined: October 10th, 2014, 8:58 am

Re: unstable HTTP streaming

Post by pierrepoulpe » October 20th, 2014, 11:59 am

1/ In order to use ffmpeg instead of libflac, I changed the priority of decoders in DecoderList.cxx to put ffmpeg before flac.
Without the change in CurlInput to prefill buffer, it works perfectly fine....

If I don't find the solution with libflac, this is an acceptable workaround... for me.


2/ I found this interesting comment :
in decoder/FlacIOHandle.cxx

Code: Select all

FlacIORead(void *ptr, size_t size, size_t nmemb, FLAC__IOHandle handle)
{
	InputStream *is = (InputStream *)handle;

	uint8_t *const p0 = (uint8_t *)ptr, *p = p0,
		*const end = p0 + size * nmemb;

	/* libFLAC is very picky about short reads, and expects the IO
	   callback to fill the whole buffer (undocumented!) */
But I don't understand what's the purpose of this piece of code, when and where it's called, etc.... Any explanation?

KlinktBeter
Posts: 18
Joined: August 30th, 2014, 7:46 pm

Re: unstable HTTP streaming

Post by KlinktBeter » October 24th, 2014, 6:40 pm

I have something very similar when using vortexbox-player + mpd 0.19.X
It was never present up to 0.18.13 which is the last 0.18.X I've compiled for vortexbox 2.2

0.19.1

[vortexbox.localdomain vortexbox]# mpd --version |head -1
Music Player Daemon 0.19.1

[vortexbox.localdomain vortexbox]# mpd --stdout --no-daemon --verbose /etc/vortexbox-player/mpd0.conf
config_file: loading file /etc/vortexbox-player/mpd0.conf
server_socket: bind to '0.0.0.0:6600' failed: Address already in use (continuing anyway, because binding to '[::]:6600' succeeded)
path: SetFSCharset: fs charset is: UTF-8
libsamplerate: libsamplerate converter 'Medium Sinc Interpolator'
vorbis: Xiph.Org libVorbis 1.3.3
sndfile: libsndfile-1.0.25
db: reading DB
curl: version 7.21.7
curl: with NSS/3.13.5.0
state_file: Loading state file /var/lib/mpd/state
inotify: initializing inotify
inotify: watching music directory
curl: icy-metaint=32768
decoder_thread: probing plugin flac
...
flac: FLAC__STREAM_DECODER_ERROR_STATUS_LOST_SYNC
flac: FLAC__STREAM_DECODER_ERROR_STATUS_LOST_SYNC
flac: FLAC__STREAM_DECODER_ERROR_STATUS_LOST_SYNC
flac: FLAC__STREAM_DECODER_ERROR_STATUS_LOST_SYNC
flac: FLAC__STREAM_DECODER_ERROR_STATUS_LOST_SYNC
flac: FLAC__STREAM_DECODER_ERROR_STATUS_LOST_SYNC
flac: FLAC__STREAM_DECODER_ERROR_STATUS_LOST_SYNC
flac: FLAC__STREAM_DECODER_ERROR_STATUS_LOST_SYNC
flac: FLAC__STREAM_DECODER_ERROR_STATUS_LOST_SYNC
flac: FLAC__STREAM_DECODER_ERROR_STATUS_LOST_SYNC
flac: FLAC__STREAM_DECODER_ERROR_STATUS_FRAME_CRC_MISMATCH
flac: FLAC__STREAM_DECODER_ERROR_STATUS_LOST_SYNC
flac: FLAC__STREAM_DECODER_ERROR_STATUS_FRAME_CRC_MISMATCH
flac: FLAC__STREAM_DECODER_ERROR_STATUS_LOST_SYNC
flac: FLAC__STREAM_DECODER_ERROR_STATUS_LOST_SYNC
flac: FLAC__STREAM_DECODER_ERROR_STATUS_FRAME_CRC_MISMATCH
flac: FLAC__STREAM_DECODER_ERROR_STATUS_LOST_SYNC
flac: FLAC__STREAM_DECODER_ERROR_STATUS_LOST_SYNC
flac: FLAC__STREAM_DECODER_ERROR_STATUS_LOST_SYNC
flac: FLAC__STREAM_DECODER_ERROR_STATUS_LOST_SYNC

Sounds plays chopped up, and everytime there's a hickup, there's a clear error


0.18.13

Going back to 0.18.13 = perfect

[vortexbox.localdomain vortexbox]# mpd --version |head -1
Music Player Daemon 0.18.13

[vortexbox.localdomain vortexbox]# mpd --stdout --no-daemon --verbose /etc/vortexbox-player/mpd0.conf
config_file: loading file /etc/vortexbox-player/mpd0.conf
server_socket: bind to '0.0.0.0:6600' failed: Address already in use (continuing anyway, because binding to '[::]:6600' succeeded)
path: SetFSCharset: fs charset is: UTF-8
libsamplerate: libsamplerate converter 'Medium Sinc Interpolator'
db: reading DB
curl: version 7.21.7
curl: with NSS/3.13.5.0
soundcloud: disabling the soundcloud playlist plugin because API key is not set
daemon: opening pid file
daemon: writing pid file
avahi: Initializing interface
avahi: Client changed to state 2
avahi: Client is RUNNING
avahi: Registering service _mpd._tcp/432EVO
avahi: Service group changed to state 0
avahi: Service group is UNCOMMITED
state_file: Loading state file /var/lib/mpd/state
playlist: queue song 1:"http://localhost:9000/stream.mp3?player ... 0:7e:af:9c"
inotify: initializing inotify
inotify: watching music directory
avahi: Service group changed to state 1
avahi: Service group is REGISTERING
curl: icy-metaint=32768
decoder_thread: probing plugin flac

-> no hickups

KlinktBeter
Posts: 18
Joined: August 30th, 2014, 7:46 pm

Re: unstable HTTP streaming

Post by KlinktBeter » October 30th, 2014, 11:29 am

To be sure the FLAC issue from an LMS stream is not already present in 0.18.X, just compiled 0.18.16.

0.18.16 -> no issues with flac streaming:
0.19.1 -> crc mismatch & lost sync issues:

flac: FLAC__STREAM_DECODER_ERROR_STATUS_FRAME_CRC_MISMATCH
flac: FLAC__STREAM_DECODER_ERROR_STATUS_LOST_SYNC

Building both versions on same platform (vortexbox 2.2) with identical libraries and OS.

KlinktBeter
Posts: 18
Joined: August 30th, 2014, 7:46 pm

Re: unstable HTTP streaming

Post by KlinktBeter » October 30th, 2014, 2:42 pm

pierrepoulpe wrote:1/ In order to use ffmpeg instead of libflac, I changed the priority of decoders in DecoderList.cxx to put ffmpeg before flac.
Without the change in CurlInput to prefill buffer, it works perfectly fine....

If I don't find the solution with libflac, this is an acceptable workaround... for me.
I just tested your solution on 0.19.1, as this issue was introduced in 0.19.x when using LMS as flac streaming source, and not present in 0.18.X

Code: Select all

# diff DecoderList.cxx DecoderList.cxx.org
64,65c64,65
< #ifdef HAVE_FFMPEG
<       &ffmpeg_decoder_plugin,
---
> #if defined(HAVE_FLAC)
>       &oggflac_decoder_plugin,
108a109,111
> #endif
> #ifdef HAVE_FFMPEG
>       &ffmpeg_decoder_plugin,
While I no longer hear clicks and pops, I'm worried about the fact that there are still errors in the curl http stream:

Code: Select all

#mpd --stdout --no-daemon --verbose /etc/vortexbox-player/mpd0.conf
...
ffmpeg/flac: sample/frame number mismatch in adjacent frames
ffmpeg/flac: sample/frame number mismatch in adjacent frames
ffmpeg/flac: sample/frame number mismatch in adjacent frames
ffmpeg/flac: sample/frame number mismatch in adjacent frames
ffmpeg/flac: sample/frame number mismatch in adjacent frames
ffmpeg/flac: sample/frame number mismatch in adjacent frames
ffmpeg/flac: sample/frame number mismatch in adjacent frames
ffmpeg/flac: sample/frame number mismatch in adjacent frames
ffmpeg/flac: sample/frame number mismatch in adjacent frames
ffmpeg/flac: sample/frame number mismatch in adjacent frames
ffmpeg/flac: sample/frame number mismatch in adjacent frames
ffmpeg/flac: sample/frame number mismatch in adjacent frames
ffmpeg/flac: sample/frame number mismatch in adjacent frames
ffmpeg/flac: sample/frame number mismatch in adjacent frames
ffmpeg/flac: sample/frame number mismatch in adjacent frames
ffmpeg/flac: sample/frame number mismatch in adjacent frames
ffmpeg/flac: sample/frame number mismatch in adjacent frames
ffmpeg/flac: sample/frame number mismatch in adjacent frames
ffmpeg/flac: sample/frame number mismatch in adjacent frames
ffmpeg/flac: sample/frame number mismatch in adjacent frames
ffmpeg/flac: sample/frame number mismatch in adjacent frames
ffmpeg/flac: sample/frame number mismatch in adjacent frames
ffmpeg/flac: sample/frame number mismatch in adjacent frames
ffmpeg/flac: broken stream, invalid padding
So I believe 0.19 has introduced some issue with flac http streaming (probably in curl), that was not present in 0.18.

Post Reply