Relayserver doesnt reconnect after encoder disconnection

[WizardX]

I have 1 shoutcast2 master server and a second shoutcast2 server connected to the first as a private relay (the master server is private aswell by the way).

As soon as I stop the encoder towards the first server the second server is off course disconnected but it doesn't seem to automatically reconnect to the master.

The message displayed on the relaying (second) server is:
Server Status: Server is currently down.
There is no source connected or no stream is configured for stream #2

Only when restarting or Updating stream configuration by clicking the update link in the admin panel the stream re-starts.

Any suggestions what could be causing this problem?

[DrO]

it's a bug in the v2 DNAS and ironically is on my todo list for things to fix tomorrow. what you're doing at the moment is the only way to get a relay to re-connect after it was dropped.

-daz

[WizardX]

Ah good news, it would be very convenient if the latest fixes and updates were released in the next few days. Still waitin' for build 30

[DrO]

a new public release is not going to happen in a few days as there are YP update dependencies which need to be rolled out first along with a load of documentation updates, etc.

i will however send you a test build to confirm things are ok once i've finished working on things (am behind on things today so i've still not started working on a fix).

i wouldn't want to use build 30, i'd rather use build 55 or something after that.

-daz

[WizardX]

Sent me a PM, will be happy to test things out for you.

[DrO]

can you confirm your values of relayreconnecttime and relayreconnecttime or are they not specified and you're just using the defaults? since it only attempts to re-connect 3 times by default with a 30 second interval and then it will just give up trying to re-connect.

[edit]
ok here's my current results / thinking on things.

the DNAS is attempting to re-connect to the relay as indicated from the internal and public builds i've just tested against. however with the number of attempts set so low it is very easy for it to never see the relay if it comes back after the time the relay handling is kept alive i.e. 1min30 at the default values then elapses.

so i'm at least going to allow relayconnectretries=0 to be supported to allow for it to just keep looking for the relay based on relayreconnecttime for the interval between checks.

-daz

[WizardX]

This is how a instance would look like in my config:

streamid_27=27
streampath_27=/broadcaster027
streamauthhash_27=
streampassword_27=******
streamrelayurl_27=http://x.x.x.x/broadcaster027
streampublicserver_27=never
streamw3clog_27=/var/log/shoutcast2/broadcaster027_w3c_8100.log
streambanfile_27=/shoutcast2/ip/broadcaster027.ban
streamripfile_27=/shoutcast2/ip/broadcaster027.rip
streamriponly_27=0
streamallowpublicrelay_27=0
streamallowrelay_27=1
streamautodumpsourcetime_27=30
streamautodumpusers_27=0
streambackupfile_27=
streamintrofile_27=
streamlistenertime_27=0
streammaxuser_27=500
streamsonghistory_27=10
streamuvoxcipherkey_27=

Both values are not specified. An infinite check would be very nice, it definately happens that a broadcaster only broadcast on specific times instead of all-the-time.

[DrO]

what build type would you want for testing?

i've changed the default of relayconnectretries to be 0 so out of the box it will keep trying to acquire the source relay.


i've done a load more work on the whole handling today and i've fixed most of the issues i've been able to find with the relay handling. am now left with a linux specific quirk which causes it to wait for ~3mins more than it should be between retry attempts even if the retry time is only at the default of 30secs.

-daz

[WizardX]

Preferrably a windows build and a linux x64 build if possible.

[DrO]

win32 or win64 ?

-daz

[WizardX]

Allthough the box is a x64 system, there's a 32 bit OS on it, so we better stick to the 32 bits. Thanks

[DrO]

k, well once i've resolved the linux specific issue then i'll pm you win32 and linux64 test builds.

-daz

[WizardX]

Great, thanks so far!

[DrO]

check your pm (and with that i'm now going to get some sleep and have a bit of a weekend).

-daz

[WizardX]

Haven't seen any problems so far. Great support DrO!

[DrO]

am i right to assume that no news is good news with this?

-daz

[WizardX]

Ehh, thought I did send you a message. But indeed, all went right! Much thanks.

[geniegate]

Originally Posted by WizardX

I have 1 shoutcast2 master server and a second shoutcast2 server connected to the first as a private relay (the master server is private aswell by the way).

As soon as I stop the encoder towards the first server the second server is off course disconnected but it doesn't seem to automatically reconnect to the master.

The message displayed on the relaying (second) server is:
Server Status: Server is currently down.
There is no source connected or no stream is configured for stream #2

Only when restarting or Updating stream configuration by clicking the update link in the admin panel the stream re-starts.

Any suggestions what could be causing this problem?

For a completely unrelated problem, I implemented a "cat" utility, takes a master stream, and then connects to shoutcast as a source.

That might be something you could try? (kind of ugly.. still not sure how it'll handle real-world fail-overs)

The reason I did it was because the directory doesn't seem to be working for me, in relay mode. (Is your stream listed? as a relay?)

[DrO]

WizardX: you did but it was at about the same time as the post made above and after a week from that i wasn't sure. but that's good that all is ok (as is the same as i've heard from a few other testers of the fix)

geniegate: the issue WizardX was nothing to do with the issue you are having and that cludge is not going to be needed now that the internal builds are correctly handling a failure of the relay source.

-daz