Possible regression with HTTP streaming between 1.3.20 and 1.4?

2018-12-18 16:32:48

I noticed after upgrading to v1.4 (through the betas, and recently the final) that HTTP streaming has become problematic.

At work, I connect through an HTTP proxy which I ultimately understand to be a load-balanced Squid setup. I frequently listen to radio shows from one radio station which are archived on a public web site.

For example, this file is what I've been trying to stream lately. Using v1.4, if I attempt to stream this show (or any similar shows from this server), the connection will always drop after a short period (between 35 and 120 seconds). If I seek further forward through the file, the same disconnect will happen.

Another test file from a different server stalls out, albeit after a long time period (just over 4 minutes).

Meanwhile, in 1.3.20, one of the Bassdrive files is HTTP streaming fine after 10 minutes... Eventually it did give up, but only after about 40 minutes of playback.

Windows Media Player (via the system HTTP proxy, which fb2k normally uses) and VLC are still streaming fine.

Shoutcast and Icecast streams work fine in both versions.

I've tested with streaming via a specific different work proxy (which nails up a session to the same external IP) with the same result, I've tried alternative proxies, I've also tried various things like disable HTTP seeking, reducing the buffer length, reducing the retry attempt time to 5 seconds / 1 second / 0 seconds...

I'm wondering if fb2k v1.3.20 is more tolerant of HTTP disconnects than v1.4? I don't have these issues with v1.4 on my home machine which has a direct Internet connection, it's only when proxy use is involved.

From VLC2's syslog while streaming a file from the same bassdrivearchive server, I can see sporadic disconnects - first near the start of the stream, then occasionally further in (about 5mins and 15mins after starting) although the audio still streams ok in the meantime:

Code: [Select]

core debug: looking for audio resampler module matching "any": 3 candidates
core debug: using audio resampler module "samplerate"
core debug: End of audio preroll
core debug: Decoder wait done in 8 ms
mpgatofixed32 error: libmad error: bad main_data_begin pointer
mpgatofixed32 error: libmad error: bad main_data_begin pointer
core warning: playback too late (70798): up-sampling
core debug: resampling stopped (drift: -1254 us)
core error: read error: No error
http debug: got disconnected, trying to reconnect
core debug: net: connecting to corporateproxy-address port 80
core debug: connection succeeded (socket = 1448)
http debug: protocol 'HTTP' answer code 206
http debug: Server: nginx/1.14.1
http debug: Content-Type: audio/mpeg
http debug: response body size=110678340
http debug: resource size=111345142
http debug: Connection: close
core error: read error: No error
http debug: got disconnected, trying to reconnect
core debug: net: connecting to corporateproxy-address port 80
core debug: connection succeeded (socket = 1424)
http debug: protocol 'HTTP' answer code 206
http debug: Server: nginx/1.14.1
http debug: Content-Type: audio/mpeg
http debug: response body size=109328796
http debug: resource size=111345142
http debug: Connection: close
http debug: Connection: close
http debug: got disconnected, trying to reconnect
core debug: net: connecting to corporateproxy-address port 80
core debug: connection succeeded (socket = 1424)
http debug: protocol 'HTTP' answer code 206
http debug: Server: nginx/1.14.1
http debug: Content-Type: audio/mpeg
http debug: response body size=104607154
http debug: resource size=111345142
http debug: Connection: close

I'm on the fence as to whether this is a fb2k issue or a proxy issue. I was going to email our network admins to enquire as to whether they've changed anything but thought it worth asking if any fb2k internals re handling HTTP has changed.

I haven't Wiresharked fb2k v1.4 on its own while HTTP streaming, but I can if it'll be useful.