Skip to main content ↑ ↓

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: fb2.1 regression: URLs in file-based playlists not handled quite right (Read 1129 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

fb2.1 regression: URLs in file-based playlists not handled quite right

Since upgrading from fb2k 2.0 to 2.1, I found all of my Internet radio URLs in a file-based playlist no longer work.  fb2k screams loudly:

Code: [Select]
Unable to open item for playback (Length of object is unknown):
"https://somafm.com/m3u/darkzone64.m3u"

Unable to open item for playback (Length of object is unknown):
"https://somafm.com/m3u/deepspaceone64.m3u"

What the file-based playlist consists of:
Code: [Select]
#
https://somafm.com/m3u/darkzone64.m3u
https://somafm.com/m3u/deepspaceone64.m3u

If we examine what the server returns for the first URL, we can see Content-Length is provided, along with an actual playlist itself:

Code: [Select]
$ curl -v 'https://somafm.com/m3u/darkzone64.m3u'
*   Trying 173.239.76.147:443...
* Connected to somafm.com (173.239.76.147) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* Cipher selection: ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:@STRENGTH
* successfully set certificate verify locations:
*  CAfile: /usr/local/share/certs/ca-root-nss.crt
*  CApath: none
* TLSv1.2 (OUT), TLS header, Certificate Status (22):
* TLSv1.2 (OUT), TLS handshake, Client hello (1):
* TLSv1.2 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
* TLSv1.2 (IN), TLS handshake, Server finished (14):
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
* TLSv1.2 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.2 (OUT), TLS handshake, Finished (20):
* TLSv1.2 (IN), TLS change cipher, Change cipher spec (1):
* TLSv1.2 (IN), TLS handshake, Finished (20):
* SSL connection using TLSv1.2 / ECDHE-RSA-AES256-GCM-SHA384
* ALPN, server accepted to use http/1.1
* Server certificate:
*  subject: CN=somafm.com
*  start date: Nov 22 00:00:00 2023 GMT
*  expire date: Feb 20 23:59:59 2024 GMT
*  subjectAltName: host "somafm.com" matched cert's "somafm.com"
*  issuer: C=AT; O=ZeroSSL; CN=ZeroSSL RSA Domain Secure Site CA
*  SSL certificate verify ok.
> GET /m3u/darkzone64.m3u HTTP/1.1
> Host: somafm.com
> User-Agent: curl/7.79.1
> Accept: */*
>
* Mark bundle as not supporting multiuse
< HTTP/1.1 200 OK
< Server: nginx
< Date: Thu, 28 Dec 2023 11:40:20 GMT
< Content-Type: audio/x-mpegurl
< Content-Length: 375
< Connection: keep-alive
< Last-Modified: Thu, 28 Dec 2023 11:40:11 GMT
< ETag: "177-60d9060d1dced"
< Content-Security-Policy-Report-Only: default-src   http://somafm.com https://somafm.com http://*.somafm.com https://*.somafm.com https://checkout.stripe.com blob:;  style-src 'self' https://checkout.stripe.com 'unsafe-inline' ;  img-src * https://* http://* data:;  font-src 'self' data:;  script-src 'self' http://somafm.com https://somafm.com http://*.somafm.com https://*.somafm.com https://js.stripe.com https://checkout.stripe.com blob: 'unsafe-eval' 'unsafe-inline' ;  frame-src 'self'  https://js.stripe.com https://hooks.stripe.com https://checkout.stripe.com https://*.soundcloud.com/ http://www.youtube.com/embed/ https://www.youtube.com/embed/ ;  media-src http://somafm.com https://somafm.com http://*.somafm.com https://*.somafm.com https://w.soundcloud.com https://api.soundcloud.com blob:;  object-src 'self' http://*.somafm.com https://*.somafm.com blob:;  connect-src http://somafm.com https://somafm.com http://*.somafm.com https://*.somafm.com https://checkout.stripe.com https://api.stripe.com
< X-Content-Type-Options: nosniff
< Access-Control-Allow-Headers: *
< Access-Control-Allow-Methods: GET, POST, PUT, DELETE, OPTIONS
< Feature-Policy: camera 'none'; magnetometer 'none'; gyroscope 'none';microphone 'none'; speaker 'self'
< X-Frame-Options: SAMEORIGIN
< Referrer-Policy: no-referrer-when-downgrade, strict-origin-when-cross-origin
< Expires: Thu, 28 Dec 2023 11:40:40 GMT
< Cache-Control: max-age=20
< X-Proxy-Cache: MISS
< Access-Control-Allow-Origin: *
< X-SomaVersion: 202110181757
< Accept-Ranges: bytes
<
#EXTM3U
#EXTINF:-1,SomaFM - The Dark Zone
http://ice2.somafm.com/darkzone-64-aac
#EXTINF:-1,SomaFM - The Dark Zone
http://ice1.somafm.com/darkzone-64-aac
#EXTINF:-1,SomaFM - The Dark Zone
http://ice4.somafm.com/darkzone-64-aac
#EXTINF:-1,SomaFM - The Dark Zone
http://ice6.somafm.com/darkzone-64-aac
#EXTINF:-1,SomaFM - The Dark Zone
http://ice5.somafm.com/darkzone-64-aac


* Connection #0 to host somafm.com left intact

The bug/issue: if I *don't* use a file-based playlist, i.e. I manually choose File -> Add location -> https://somafm.com/m3u/darkzone64.m3u then things play fine (obviously all 5 server endpoints show up in the playlist).

How I was using this originally: having URLs in a file-based playlist, and letting fb2k read the actual M3U playlist (from the initial URL) and let fb2k use whatever server gets returned first.  In other words: in the above example, fb2k would fetch https://somafm.com/m3u/darkzone64.m3u for the "actual" playlist, then pick a server/endpoint from that list (I assume the first one).

Why I do it this way: it ensures if SomaFM (Internet radio/streaming provider) changes their playlist (add/remove servers), that fb2k always has an accurate list.  If I was to simply save the M3U from the server in a local file, if they added/removed servers I'd never know.

Workaround: change the file-based playlist to contain the direct streaming servers themselves.  This is annoying/silly (see above):
Code: [Select]
#
http://ice2.somafm.com/darkzone-64-aac
http://ice2.somafm.com/deepspaceone-64-aac

Re: fb2.1 regression: URLs in file-based playlists not handled quite right

Reply #1 –
Thanks for the bug report, it is being looked into.

Please note that what you do worked by accident in foobar2000 v2.0 - it was handled by HLS reader even though this stream is not HLS at all.
The no-length message comes from underlying AAC stream, which HLS reader now expects to be a finite resource that can be preloaded.
Microsoft Windows: We can't script here, this is bat country.

Re: fb2.1 regression: URLs in file-based playlists not handled quite right

Reply #2 –
Thanks Peter!  If you need me to test some changes and can provide a Windows x64 build, I'd be happy to give it a try.

Re: worked by accident: I had a feeling this might be the case.  I wasn't sure if "how" I was using M3U files was exactly kosher.  Do you have any recommendations for a "proper" replacement/implementation that I can use on 2.1 in the meantime (other than simply hard-coding the server list (see: workaround))?  If not, that's OK.
 

Re: fb2.1 regression: URLs in file-based playlists not handled quite right

Reply #3 –
Can confirm this issue is fixed in 2.1.1.  Thank you!