In 1.6.7 and also in 1.6.9, when I use Add Location and provide one of the following URLs
http://radio.linnrecords.com/cast/tunein.php/linnradio/playlist.pls
http://radio.linnrecords.com/cast/tunein.php/linnclassical/playlist.pls
http://radio.linnrecords.com/cast/tunein.php/linnjazz/playlist.pls
(via https://www.linn.co.uk/linn-radio)
fb appears to stall out, but it's actually attempting to load the response of the initial load, which in this case has been 302 redirected:
GET /autodj HTTP/1.1
Host: radio.linn.co.uk:8003
Connection: close
User-Agent: foobar2000/1.6.9
Accept: */*
Icy-MetaData:1
HTTP/1.0 200 OK
Server: Icecast 2.4.4
Connection: Close
Date: Sat, 15 Jan 2022 00:13:27 GMT
Content-Type: audio/mpeg
Cache-Control: no-cache, no-store
Expires: Mon, 26 Jul 1997 05:00:00 GMT
Pragma: no-cache
icy-br:320
ice-audio-info: bitrate=320
icy-description:Default description
icy-genre:(null)
icy-name:Linn Radio
icy-pub:0
icy-url:http://radio.linnrecords.com/
icy-metaint:16000
.<...y........Ah..Z....b
j).q..q.............D....vO.oF..N..m.....8
.;..6gI.=y.D"F".`...(..0@b.P...w..
..".B.
D... z.........:0rR..Q..~
.H.miE..E.T.;. `..p..Q>#cH..J.)... ...h......1..
x...ca......%..<...uk.lY...k....;...i..7%F.K.J..S.....K...D..V.....0!.%XV.Z....k[...i.....(".a.S..g.s.. .5..D&.M..............n.....|.4?WJ.0B.h..
<a.@!..
>....3k.....L$0..Q.6...........<8..03...v......X!..t`..XU......`pA2.CE.....z.$..=..........S+..T..K,.d1m....O'..j.l.{........8Rgs...>.d...y/#P..-X.7....=DHN..@@..a.
.*....wLr.Mo...M....1...._......\..4.mg.1.3.....s..gf..`s..V2...2.
.......`.15..O.%
4{..............P.Uz4.#..2..rR..`x j...Bd...7r...)..`.......'..\HQs.h...*P8$.....w..@.....O..]..e..YV.uj.....rT..d"..f.2v64...M..!..w......F..-.OKj.........Fo.....qE.CiV...1...@..5x..BS.%2K.D.&....O....6.P.bc..U.....;QI'Z..w./s..6C3....!.1.c'(5..a..X...x...Hb...K.......... ..a..
....].@......
...P......4sR4
Q....X...(.2x....,M:`...
$5.-.f0.8.E..J..
[..U.).'....PYf..k.......r...Q...NM.[. ..)m..m....!....[.cN..[.7j.9...i.......`|.Xv....<y.Q.X...s.........W.......9.O......~]g.;....!..o.1.5...........D....z..oF...Y.m...E.:
.{C..'...h.B.f.2a.F.B(>`.a... .\..+.0SS..01w.q8.. #.T(8~....J..!.!..7......$hm!....S .sai&.@........P..(.aR.p...C..IZ..x.C.............}8v&.......EY....x.B.....U.(......D.3..(G.9......W(..f..j.H..u(F0A Ax
..f[2..KC....X.."...}%o.j....FMo..q.8?i.|..S..R:.....K.1....A.0..d....c....A...ED"...8P@...>.V&..-...4..`.H+.....bPr!....\.`.....aC.P#.2.4..7%.N0. ..&U..UW~...... ...H.{... .a@.......O......A.aU.D.OL...>..@".\O.@...g..Zz.,.].r...uY.....%.S.MW.EWo...ic....
N i_.]...c+Q.V.....Q{.X..G.6p`.{\..&',.#...0.....2.*.h...A.....A..bj.....o.xe...\.'<.\%....Bx.k@`.....`.."QA....u.!&.B..G......1r....l.(:....X...z..I..A..Vl9Q.w...f.9C......S..J...^..YQ..a.F...H.ej.$R.+.$.....7..K.{...V.,f.....|.hD....
tZ..#ScD;.I3-g..I.....8..s.#!...BS<.Kt~/c...d}...c...U.
It tries repeatedly until eventually giving up.
It seems like a quirk of how Linn have configured their system - replacing playlist files with 302 redirects to the actual stream endpoint. They're arguably breaking spec with this 302, instead of serving a static playlist file as the client expects, but I doubt we'll get them to change this. I did mention it to them on social media.
My initial theory is that fb2k isn't expecting to need to further evaluate the response content as the server replies with "Content-Type: text/html", so sits and waits for playlist while it's receiving actual stream data.
For comparison, this is what happens if you request one of those .pls "playlist" URLs in Chrome:
Request: http://radio.linnrecords.com/cast/tunein.php/linnradio/playlist.pls
Request URL: http://radio.linnrecords.com/cast/tunein.php/linnradio/playlist.pls
Request Method: GET
Status Code: 302 Found
Remote Address: 195.59.102.230:80
Referrer Policy: strict-origin-when-cross-origin
Connection: keep-alive
Content-Length: 0
Content-Type: text/html
Date: Fri, 14 Jan 2022 23:49:33 GMT
Location: http://radio.linn.co.uk:8003/autodj
Mime-Version: 1.0
Server: squid/3.4.8
Via: 1.1 webhost-proxy (squid/3.4.8)
X-Cache: MISS from webhost-proxy
X-Cache-Lookup: NONE from webhost-proxy:80
X-Squid-Error: 403 Access Denied
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.9
Accept-Encoding: gzip, deflate
Accept-Language: en-GB,en-US;q=0.9,en;q=0.8
Cache-Control: no-cache
Connection: keep-alive
DNT: 1
Host: radio.linnrecords.com
Pragma: no-cache
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/97.0.4692.71 Safari/537.36
the stream then buffers and plays in Chrome's built-in player.
So I guess it's up to us (well, you benevolent devs) to consider a workaround for this kind of misconfiguration...!) Or not, if you deem it a "wontfix"