Request [https://yp.shoutcast.com/yp2] failed, code: 28

[DannyGHE]

I have this error with a Freemium shoucast server . Any idea ?


Status:
Unable to access the Directory.
Check the server log for more details.
The stream will behave like it is private.

Log :
2020-04-02 10:37:58 DEBUG [YP] pvt_add No entry for key=4
2020-04-02 10:37:58 DEBUG [YP] getAddUpdateBody add for key=4 [0]
2020-04-02 10:38:03 ERROR [YP] Request [https://yp.shoutcast.com/yp2] failed, code: 28 [Connection time-out]
2020-04-02 10:38:03 DEBUG [YP] gotFailure Request key=4 cmd=0

[LStratmann]

Can you send us the config? We can also censor things like password and so on.

[DannyGHE]

Here it is .
Same config since months ...

adminpassword=****removed****
banfile=control/sc_serv.ban
destdns=188.165.35.60
destip=188.165.35.60
fixedbuffersize=2048576
logfile=logs/sc_serv.log
maxuser=50
password=****removed****
portbase=8008
requirestreamconfigs=1
ripfile=control/sc_serv.rip
w3clog=logs/sc_w3c.log
streamadminpassword_1=****removed****
streamauthhash_1=****removed****
streammaxuser_1=50
streampassword_1=****removed****

[DannyGHE]

To be honest, I am quite sure that it's a way to force us to use the last release of Shoutcast which will automatically downgrade quality to 126 kbps for freemium users.

The version that I am running on that specific server ( SHOUTcast Server v2.5.5.733) is not concerned by this automatic quality downgrade yet;-)

This version was running very well until that announce of some bugfixes on YP last week

[LStratmann]

So the server is not using the latest version? Then I think SHOUTcast has switched off the "old" YP so that you should subscribe to the new premium.

[DJ Egg]

We've not switched off the old (Java) YP.
We're not blocking stations using DNAS v2.5x or even v2.4.7
We're not trying to force people to use v2.6 (though if you're already using it, make sure it's build 753).
We're not trying to force people to upgrade in order to limit them to mp3 @ 128k

Re: Repeated destdns and destip values

They're really only good for specifying a domain instead of an ip, e.g. destdns=stream.myradiostation.com
or if the stream is a relay, or if a hosting provider specifically requires it (though you'd only need one of the entries, not both, and better to use destip= and publicip=)


______________________________________________________


http://188.165.35.60:8008

v2.5.5.733 / Linux64

Listing Status: Stream is currently up but unable to access the Directory.

Please confirm you are using the authhash for Melodie FM from the RadioManager.


If using a different authhash, send me it in a PM or use the support ticket system (keep bumping if I don't reply, there's literally hundreds of emails every day, and I'm only human, after all - sorry).

[DannyGHE]

Thanks for this clarification DJ Egg

Please confirm you are using the authhash for Melodie FM from the RadioManager.

Yes i do .

Danny

[DJ Egg]

The authhash looks good.

Please could you post results from DNAS server machine for command prompt: ping yp.shoutcast.com

[DannyGHE]

PING yp.shoutcast.com (31.12.71.119) 56(84) bytes of data.
64 bytes from 31.12.71.119 (31.12.71.119): icmp_seq=1 ttl=52 time=70.7 ms
64 bytes from 31.12.71.119 (31.12.71.119): icmp_seq=2 ttl=52 time=70.6 ms

I had also tested with firewall off --> No Change
[YP] Request [https://yp.shoutcast.com/yp2] failed, code: 28 [Connection time-out]

[DJ Egg]

ok, and the same for:

curl -vvI https://yp.shoutcast.com/yp2

[DannyGHE]

Here it is

* Trying 31.12.71.119...
* TCP_NODELAY set
* Connected to yp.shoutcast.com (31.12.71.119) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
* CAfile: /etc/pki/tls/certs/ca-bundle.crt
CApath: none
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.3 (IN), TLS handshake, [no content] (0):
* TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
* TLSv1.3 (IN), TLS handshake, [no content] (0):
* TLSv1.3 (IN), TLS handshake, Certificate (11):
* TLSv1.3 (IN), TLS handshake, [no content] (0):
* TLSv1.3 (IN), TLS handshake, CERT verify (15):
* TLSv1.3 (IN), TLS handshake, [no content] (0):
* TLSv1.3 (IN), TLS handshake, Finished (20):
* TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.3 (OUT), TLS handshake, [no content] (0):
* TLSv1.3 (OUT), TLS handshake, Finished (20):
* SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384
* ALPN, server did not agree to a protocol
* Server certificate:
* subject: OU=Domain Control Validated; OU=PositiveSSL Wildcard; CN=*.shoutcast.com
* start date: Aug 8 00:00:00 2017 GMT
* expire date: Aug 26 23:59:59 2020 GMT
* subjectAltName: host "yp.shoutcast.com" matched cert's "*.shoutcast.com"
* issuer: C=GB; ST=Greater Manchester; L=Salford; O=COMODO CA Limited; CN=COMODO RSA Domain Validation Secure Server CA
* SSL certificate verify ok.
* TLSv1.3 (OUT), TLS app data, [no content] (0):
> HEAD /yp2 HTTP/1.1
> Host: yp.shoutcast.com
> User-Agent: curl/7.61.1
> Accept: */*
>
* TLSv1.3 (IN), TLS handshake, [no content] (0):
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* TLSv1.3 (IN), TLS handshake, [no content] (0):
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* TLSv1.3 (IN), TLS app data, [no content] (0):
< HTTP/1.1 200 OK
HTTP/1.1 200 OK
< server: nginx
server: nginx
< date: Thu, 02 Apr 2020 14:55:05 GMT
date: Thu, 02 Apr 2020 14:55:05 GMT
< content-type: text/xml;charset=UTF-8
content-type: text/xml;charset=UTF-8
< content-length: 123
content-length: 123
< keep-alive: timeout=600
keep-alive: timeout=600

<
* Connection #0 to host yp.shoutcast.com left intact

[DJ Egg]

Thanks. That looks good too.
Though we are actually using embedded libcurl (and openssl) libs in sc_serv.

We're struggling to reproduce your particular error, though we're still investigating....

You restarted the DNAS, yes?


We're not actually receiving the request from your server.
It's being blocked somewhere before reaching us.

[DannyGHE]

I've tried to move this SHOUTcast Server v2.5.5.733 to a new setup of Centos 8 , or Centos 7 without any improvement .
Everything is working .... execpt YP registration.

If I start a Shoutcast Server v2.6.0.753 ( with a premium account ) on the same servers , YP is working fine .

[m2m]

DannyGHE, We're getting the exact same problem utilising Shoutcast 2.5.5.733.

Like you, our config and setup has not changed for a long time. We noticed that our servers stopped communicating with yp.shoutcast.com/yp2 around the time that a bug fix was recorded as being implemented.

All our streams are now showing as private.

Hopefully, DJ Egg and the team can get to the bottom of this.

[RickoDean]

did anyone manage to sort this out? My station has stopped communicating with Shoutcast yp on May 29, 2020. last month, I did 1.2M listening hours. its been showing 0 for the third day in a row and I have not yet seen a targetspot earnings since I started using Shoutcast back in 2017. I beginning to believe that you can't survive if you don't pay. I'm outraged

station Status: Unable to access the Directory.
Check the server log for more details.
The stream will behave like it is private.

[bobk37]

I'm getting the same error. I did notice this when I ran tsc_serv.exe setup

2020-06-01 23:11:39 ERROR [YP] Request [https://yp.shoutcast.com/yp2] failed, code: 60 [SSL certificate problem: certificate has expired]

[Googe]

Same happening to me.

Errors:
DEBUG log:
2020-06-01 21:30:41 DEBUG [YP] pvt_update add still pending for key=1 [1] [20]
2020-06-01 21:30:41 DEBUG [YP] Creating new curl handle for: https://yp.shoutcast.com/yp2
2020-06-01 21:30:41 DEBUG [YP] Request URL: https://yp.shoutcast.com/yp2
2020-06-01 21:30:42 ERROR [YP] Request [https://yp.shoutcast.com/yp2] failed, code: 60 [SSL certificate problem: certificate has expired]

CURL:
curl -vvI https://yp.shoutcast.com/yp2
* Trying 31.12.71.119...
* TCP_NODELAY set
* Connected to yp.shoutcast.com (31.12.71.119) 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: /etc/ssl/cert.pem
CApath: none
* 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 (OUT), TLS alert, Server hello (2):
* SSL certificate problem: certificate has expired
* stopped the pause stream!
* Closing connection 0


running really old Mac version...10_07_2011

[Googe]

Working again, as of 6/2:
Response code=[200]
2020-06-02 13:14:29 INFO [YP] Updating listing details for stream #1 succeeded.

Thanks to whomever!

[bobk37]

Yes - working correctly now. Thanks for fixing!

[RickoDean]

Now my server is working and public. Thanks to whomever rectified this. Meanwhile My radio manager is still showing 0 live listeners although my server counter has me at a little past 3200. I hope this gets fixed as well.

[Googe]

Whoops, new error...

2020-06-02 22:38:00 DEBUG [METRICS] Creating new curl handle for: https://metrics.shoutcast.com/metrics
2020-06-02 22:38:00 ERROR [METRICS] Request failed on https://metrics.shoutcast.com/metrics with SSL certificate problem: certificate has expired

[Busby]

Sorry to bump this.
I have 1 server running SHOUTcast Server v2.5.5.732/posix(linux x64) which is listing OK at Shoutcast, and another running the same version and the same authhash, but getting the following error:
Status: Unable to access the Directory.
Check the server log for more details.
The stream will behave like it is private.
I have checked both the streaming port and the next one are open.

I am working on updating to sc_serv_update_linux_x64_2_6_1_777 but have limited Linux skills so waiting for a friend to have time.

Can anyone help please with the directory listing.

[DJ Egg]

Originally Posted by Busby

Sorry to bump this.
I have 1 server running SHOUTcast Server v2.5.5.732/posix(linux x64) which is listing OK at Shoutcast, and another running the same version and the same authhash, but getting the following error:
Status: Unable to access the Directory.
Check the server log for more details.
The stream will behave like it is private.
I have checked both the streaming port and the next one are open.

I am working on updating to sc_serv_update_linux_x64_2_6_1_777 but have limited Linux skills so waiting for a friend to have time.

Can anyone help please with the directory listing.

fr1.1mix.co.uk & fr3.1mix.co.uk servers are both on port 8060

In listenh.m3u, fr4.1mix.co.uk is listed as being on port 8000

This is the server with the streams that are "unable to access the directory".
Is the port config correct, or should it also be 8060?

[Busby]

Originally Posted by DJ Egg

fr1.1mix.co.uk & fr3.1mix.co.uk servers are both on port 8060

In listenh.m3u, fr4.1mix.co.uk is listed as being on port 8000

This is the server with the streams that are "unable to access the directory".
Is the port config correct, or should it also be 8060?

Many thanks for the reply.

I have 3 servers;

fr1.1mix.co.uk using port 8060
fr2.1mix.co.uk using ports 8000 and 8060
fr3.1mix.co.uk using ports 8000 and 8060

I have 2 playout systems and the plan was to have 1 playout system streaming to fr1 on port 8000, and another on port 8060 with 8000 being the main stream with 8060 being the 'fallbackurl' and fr2 and fr3 acting as relays.

As I was never able to get 'fallbackurl' to work, I finished up with 2 separate servers relying to separate mount points.

I'm trying to make some sense of this now as it's just a mess..

[Busby]

Originally Posted by DJ Egg

fr1.1mix.co.uk & fr3.1mix.co.uk servers are both on port 8060

In listenh.m3u, fr4.1mix.co.uk is listed as being on port 8000

This is the server with the streams that are "unable to access the directory".
Is the port config correct, or should it also be 8060?

The server which displays "unable to access the directory" is FR2, both 8000 and 8060 ports.
FR1 and FR3 are fine.

Thanks in advance..

[Busby]

Originally Posted by DJ Egg

fr1.1mix.co.uk & fr3.1mix.co.uk servers are both on port 8060

In listenh.m3u, fr4.1mix.co.uk is listed as being on port 8000

This is the server with the streams that are "unable to access the directory".
Is the port config correct, or should it also be 8060?

Many thanks for the reply - a Unix update on the server resolved the problem..