SHOUTcast DNAS 2.2.2 (Build 123) 31st July 2014

[DrO]

This build is our new update and introduces new features as listed in the “Changes” section below, as well as addresses bugs reported in the previous build. It is recommended where possible to update to this build over any previous v2.x builds due to the stability and other compatibility improvements it provides.

This release is now available for the following platforms:

• Windows 32-bit (Windows 2000 and up)
• Windows 64-bit (Windows XP64 and up)
• Linux
• Linux 64-bit
• Raspbian (Raspberry Pi)
• Mac OS X (Intel)

Downloads

You can download the updated version of the DNAS v2 from the direct downloads for the operating system version you require:

• Windows (32-bit)
• Windows (64-bit)
• Linux (32-bit)
• Linux (64-bit)
• Raspbian (Raspberry Pi)
• MAC OS X Intel

Changes

Build 123 (31st July 2014):

• The first Radionomy provided SHOUTcast DNAS release after the sale of SHOUTcast (and Winamp) in January 2014
• This is primarily a maintenance release to resolve issues and broadcaster requests with the 2.2.x DNAS since the last build provided under AOL ownership
• Added 'pidfile' option to control the creation of the file containing the process id of the DNAS (this defaults to creating 'sc_serv_<portbase>.pid if not specified in the same folder as the DNAS)
• Added ability to block user agents from connecting to the streams on a global and per-stream basis if required (via admin pages and admin api methods)
• Added 'agentfile', 'streamagentfile' and 'saveagentlistonexit' configuration options to allow for where and how the sc_serv.agent file is stored (which is used for holding the blocked user agents)
• Added 'blockemptyuseragent' configuration option to allow for preventing client connections without a user agent from connecting (note: some valid clients e.g. some hardware devices may not provide a user agent and enabling this may incorrectly block legitimate client connections)
• Added 'Reload Banned List(s)' option to the server admin page to complement the 'Reload Reserved List(s)' option
• Changed network handling on non-Windows builds to try to resolve the random crashes with large listener numbers and scale better (e.g. going over ~330 concurrent listeners)
• Changed to use libcurl instead of a custom library for all YP requests to help resolve the YP connection reliability issues some users have seen with most of the 2.x releases
• Changed 'disableicy' default from '0' to '1' so we now by default provide HTTP instead of ICY headers - this resolves all known HTML5 audio playback access issues
• Changed the frequency and formatting of some of the log output
• Changed 'unique' to also apply to the 'portbase' config option
• Changed log file creation to use sc_serv_<pid>.log (where <pid> is the process id of the DNAS) if the default / fallback 'sc_serv.log' cannot be created e.g. due to file permissions creating / accessing an existing copy of the file (mainly affects non-Windows builds)
• Changed 'maxuser' default from 32 to 512 listeners (you will need to ensure the OS can support this e.g. adjusting ulimit -n on non-Windows installs)
• Changed 'relayreconnecttime' default from 30 to 5 seconds (based on usage feedback)
• Changed 'adaptivebuffersize' default from 5 to 10 seconds (based on usage feedback)
• Changed GCC version used to build the Linux / Raspberry Pi versions (now using GCC 4.7.2 instead of GCC 4.4.6 / 4.6.3 respectively)
• Changed title update handling in respect to issues related to CVE-2014-4166 (which we were not informed about before it was disclosed!)
• Fixed stream access issues (always providing stream #1) if streampath=/stream is set and providing multiple streams from the same DNAS
• Fixed formatting error in the JSON version of the listener details (XML version was not affected)
• Fixed some file handle leaks with log file handling (mainly happened when compressing older log files on rotation)
• Fixed a number of YP error handling issues (mainly found from changing over to use libcurl) e.g. stuck on 'Processing...' when an error was logged
• Fixed the 'city' value of the authhash not being correctly re-loaded when viewing the authhash
• Other miscellaneous code changes, improvments and related documentation updates

Getting Started

If you already have a running instance of the DNAS v2 then there should not be any issues with replacing your current version with this new version.

If this is a new install then make sure to read through the information in 'Readme_DNAS_Server.html' and the related documentation as well as considering using the setup mode which should make it easier to get started over all prior v2.x builds (and v1 based releases).

Finally, all current copies of the documentation are included with the installer / archive and is the recommended point of reference for this release. The information found online at http://wiki.winamp.com/wiki/SHOUTcast_Broadcaster for the DNAS server only relates to the v2.0 (build 29) release (this will be updated soon).


Reporting Issues

If you do come across an issue with the DNAS, then please do post in this thread with as much information as possible about what you're doing at the time, the system you are using and anything else which will make it easier to understand what is or isn't going on with your install.

Posts relating to authhash management issues will be ignored as this is not the thread for posting such issues.


Known Issues

The following are known issues with the v2 DNAS raised in previous releases but not currently fixed / fully confirmed as needing to be fixed (i.e. intended behaviour):

1. The configuration builder has not been fully updated for this release i.e. not all new options are available. This will be resolved in a later update and does not affect most configuration aspects if this mode is used.
2. Under sustained high numbers (1000's) of concurrent client connections, the DNAS server may in rare scenarios crash / segfault. This is primarily due to the networking methods currently used not scaling as well to the 1000s of concurrent client connections as desired compared to the need for more portable code between the platform builds. This requires completion of a networking stack re-write (no eta) and should not generally happen under most expected usage (most stations never break a few 100 concurrent listeners let alone 1000s at the same time).
3. The change of 'disableicy' from 0 to 1 may cause some clients not to show the current title anymore. Setting disableicy=0 will allow the prior behaviour at the expense of breaking default compatibility with Flash and HTML5 audio players. See http://forums.winamp.com/showpost.ph...08&postcount=7 for more on what you can do currently and what will be done in the next build.
4. Some Centova setups experience a crash when the logs are rotated. For some using the Linux 32-bit version helps as the issue has only been seen with the Linux 64-bit release. This is due to incorrectly handling invalid log / w3c files and if you have any 0-byte files in your log folder, if you remove them then first then you can update to the current DNAS release.
5. When attempting to update / remove an authhash, some installs will experience a 462 error (which is due to an issue with the integration of libcurl into the DNAS). Contact support with the authhash and the details you require to be changed. Additionally this may cause a failure to be listed or you will see generic 400 error messages.

Discussion about the previous version of the server including changelogs can be found in the following threads

• SHOUTcast DNAS 2 (Build 109)
• SHOUTcast DNAS 2 (Build 107)
• SHOUTcast DNAS 2 (Build 29)
• SHOUTcast DNAS 2 RC2 (Build 28)
• SHOUTcast DNAS 2 RC (Build 27)
• SHOUTcast DNAS 2 Beta (Build 18 + 19)
• SHOUTcast DNAS 2 Beta (Build 17)
• SHOUTcast DNAS 2 Beta (Build 13 + 14)
• SHOUTcast DNAS 2 Beta (Build 10)
• SHOUTcast DNAS 2 Beta (Build 7)

[DrO]

*new version bump*

[MrSinatra]

cool!

[thinktink]

Excellent!

[Bryon Stout]

awesome! Thanks DrO


DrO.. Just curious as to what was done to fix this issue?

"Changed network handling on non-Windows builds to try to resolve the random crashes with large listener numbers and scale better (e.g. going over ~330 concurrent listeners)"

[DrO]

we changed things to work with a method that shouldn't fail when going above 1024 open file handles and is portable enough for use on all of the non-Windows builds (as Windows doesn't provide it and it's handling of what we were using is different to *nix setups and so didn't experience the issue in such the same way).

so from what we've been able to test, it should now play ball as long as you set ulimit -n appropriately and server loads under higher listener number should be lower as well (assuming the test results match up with real world usage).

[Bryon Stout]

awesome.. Im going to install this later tonight and up my limit. Ill let you know if I have any issues.

[DrO]

was counting on you being willing to try it out asap

[aron9forever]

finally, good job
Two questions:
1) If you already have a running instance of the DNAS v2 then there should not be any issues with replacing your current version with this new version. This is pretty unclear. Can I just change the binaries and restart the server?

2) Will shoutcast ever support OGG? If not(wich will probably be the answer) is there any other known way to stream low bandwidth quality streams to mobile listeners? I couldn't get AAC to work on non-apple devices, is it possible?

[Cande]

Aron9,
to answer your first question, yesterday I updated DNAS to 2.2.2 on three Cent OS machines by stopping the server, replacing the binary (and other included files and folders) and restarting it with a total downtime of 20 seconds.
My previous config file works perfectly, now I'll study new options and parameters...

Great job DrO, thank you!
Cande

[pirithous]

Will there be a BSD version compiled?

[DrO]

Originally Posted by aron9forever

1) If you already have a running instance of the DNAS v2 then there should not be any issues with replacing your current version with this new version. This is pretty unclear. Can I just change the binaries and restart the server?

Cande has pretty much answered it and for most v1.x setups there is minimal to no effort needed in updating if just replacing the DNAS program file - its only the auto authhash generation which can be tgectricky part and that usually fails due to bad data from the connected source software.

Originally Posted by aron9forever

2) Will shoutcast ever support OGG? If not(wich will probably be the answer) is there any other known way to stream low bandwidth quality streams to mobile listeners? I couldn't get AAC to work on non-apple devices, is it possible?

currently not for the time being - just MP3 and ADTS-AAC is all that is supported. and that could be why you were having issues with AAC playback (though its generally web based playback which doesn't like the ADTS-AAC format and is why ideally the DNAS should be updated to be able to provide an MP4-AAC stream (with the DNAS making that from the stream so it doesn't mess with existing source tools.

as you can sort of stream ogg container streams with the DNAS but it doesn't create the required data blocks to allow you to access the stream correctly once that is out of the stream buffer. and title updates didn't work either from what I remember. as I had breifly gotten test builds of the v2 DNAS and source dsp about 2 years ago now just about making a valid Ogg Vorbis stream but it needed a lot more work to make things work correctly.

and based on looking at Ogg Vorbis numbers on other directories, there just doesn't seem to be interest in at least listing those sorts of streams (as i know of a few which are running Ogg Vorbis but aren't listed) so maybe there is a bit more a demand, but compared to main formats of MP3 and AAC, there's no contest on what people are using.

so it's probably a nice format to have support for at some point (as it would likely also open up the means to support Opus streams - since it uses a similar container iirc), but there's far more important things that can and should be worked on (e.g. providing AAC streams in a more compatible format than what we provide so they'll work with Flash and HTML5 audio) than what is essentially a niche format for the Directories a SHOUTcast DNAS would be able to be part off.

Originally Posted by Cande

...and restarting it with a total downtime of 20 seconds.

that's not too bad though closing with the new version should be somewhat quicker as some of the cleanup actions could cause a 20 second delay on top of everything else done at shutdown. so hopefully future updates should be a bit quicker to make (though the main thing now is how many clients active at the time as to how soon it can close down completely).

Originally Posted by pirithous

Will there be a BSD version compiled?

probably not - there's only a handful of people using the BSD build of the v2.x DNAS and its just not a platform we actively use and test on. the Mac build could also possibly be dropped but that's got a bit more usage and we've had more people contact us about issues using it than BSD - you're the only one I directly know off that is using the BSD build.

to give an idea of things, there are more v1.x SPARC DNAS known to the yp than v2.x BSD by a factor of 10 and there's not that many SPARC instances to start with.

[Cande]

Hello,
after about 40 hours usage, it looks like some stability problems still remain with the new build, at least for my setup.

Shoucast DNAS hangs when sources either disconnect or stop streaming due to issues on their side.
Basically, this happens in two situations:

1. Shoutcast's hosting server (CentOS 6.5 64 bit) drops one or more sources' connections (firewall is the suspect);
2. at least one source stops streaming (encoder/streamer stopped) or halts the stream (encoder/streamer still active but sends nothing)

In my configuration, the DNAS is set to allow a total of 20 (private) streams, but actually only 11 are used. Max number of listeners rarely exceeds 300 so I don't think it's a load problem. Ulimit is set to 8192.

Since situation #1 happens rarely, I'm now focusing on #2: do you have suggestions?
Maybe if I relay the encoders/streamers to a more stable streaming tool heading to our DNAS, this issue will be fixed...

Thanks a lot for any hint!
Cande

[DrO]

what do you mean by 'hangs' ?

are we talking about a crash / segfault or just things take a while to respond ?

and is it manually reproducible i.e. if you manually kill the source it happens ? (as this is mainly to determine if its something which could be consistently tested against to try to resolve)

[Cande]

Thanks for the quick reply Dr0!

I can reproduce the issue quite easily by stopping the source or better stopping/restarting it a couple of times.

As for the hangs, actually both scenarios occur and I have setup an auto recovery solution for each:

. sc_serv crashes and gets immediately respawned by an Upstart script;
. sc_serv hangs (stops responding despite still active) and after max 60 seconds gets killed by a cron job checking if it's alive (by locally monitoring if sc_serv answers to simple http request on the streaming port), then gets respawned by the Upstart script

I can see both situations happening on the server's log messages by checking the signal detected by the Upstart script before performing respawn: ABRT in case of crash, KILL in case of hang, with the latter happening more frequently.

Any clue?

Thanks a lot!!!
Cande

[DrO]

could do with seeing some sort of dnas log output or backtrace (though not sure how well that will work with the compile) if you're able to do so.

are the streams publically listed? as the only obvious thing I can think off at the moment is it might be related to the yp remove handling (as that's the code which has seen the biggest change between this and the last build).

though the ideal would be if its possible to have some sort of access to an example setup showing the issue which I could then use to more easily test out things and try to find the case of the issue.

[Cande]

The streams are all private (no yp set), sc_serv logs don't give much information apart from sources disconnections/reconnections shortly before the process ends working.

Please note that this issue is not new to me and was not introduced with this brand new build.
I've been investigating this for months now and also tried several changes to our setup to solve it or at least isolate the culprit and now I am pretty sure it is a "source side" problem: what I don't know yet is if this instability is caused by a sc_serv bug or by a source's streamer stack problem.

At the moment, I have a test setup behind a private network and I could open a TeamViewer session to a desktop machine with access to sources and server, but please allow some days to prepare it.

Back to my first question, if I install Shoutcast DNAS on each source's machine (Windows XP) and set it up as a relay to our streaming server, could it be a workaround and most importantly: is it possible?

Thanks again!

[DrO]

yes you could setup the main DNAS to pull in (as relays) the instances on the Windows machines.

[pirithous]

Originally Posted by DrO

probably not - there's only a handful of people using the BSD build of the v2.x DNAS and its just not a platform we actively use and test on. the Mac build could also possibly be dropped but that's got a bit more usage and we've had more people contact us about issues using it than BSD - you're the only one I directly know off that is using the BSD build.

to give an idea of things, there are more v1.x SPARC DNAS known to the yp than v2.x BSD by a factor of 10 and there's not that many SPARC instances to start with.

Interesting metrics; I know BSD does Linux binary compatibility, but I'm not sure how well it works. At this point we'll probably switch our server over to Linux at some point, but I'm really dreading having to reconfigure everything and do the data transfer.

And I just can't see Mac OS X being a good OS choice for a server, just as Windows 7 would be a stupid choice for a server. Apple discontinued making Xserve rack units in 2004 which is disappointing, and I'm not sure what's contained in the proprietary blobs that make up today's OS X. Being optimized for the desktop, even though the kernel is based off BSD, means exactly that.

[Cande]

OK, thank you! I will try to setup a source with relay and stress test it to see what happens and let you know...

Cheers!

[DrO]

pirithous: we have to base things on what we can see (maybe there's more using it that aren't listed but as we can only measure against what is listed, that's what we've got to use). plus without knowing if targeting 8.x or 9.x was better for the handful of people who are using the BSD build (what those running the v1.x DNAS BSD build are using for their BSD version i've no idea and doubt those would ever consider updating - if they did then it might be worth providing a newer v2.x BSD build).

but BSD and Mac are a pain to test on at the best of times when it's not the main OS we're developing against (as i only test them via VMs). as the Linux and Windows builds (along with the Raspbian build as although that's more of a pet project for me but has it's uses towards improving the main versions used) are what we're working on / directly testing on. and the Linux and Windows builds are what most people use to run things (and you could say a desktop version of Linux isn't ideal to run things on either compared to running on a Windows machine ).

so it comes down to us spending time internally testing something hardly anyone uses or spending that same time on the main platforms being used (which is very heavily skewed towards Linux versions across v1.x and v2.x installs) and providing fixes / improvements for that platform when it'll help more in one go.

[aron9forever]

Originally Posted by DrO

currently not for the time being - just MP3 and ADTS-AAC is all that is supported. and that could be why you were having issues with AAC playback (though its generally web based playback which doesn't like the ADTS-AAC format and is why ideally the DNAS should be updated to be able to provide an MP4-AAC stream (with the DNAS making that from the stream so it doesn't mess with existing source tools.

as you can sort of stream ogg container streams with the DNAS but it doesn't create the required data blocks to allow you to access the stream correctly once that is out of the stream buffer. and title updates didn't work either from what I remember. as I had breifly gotten test builds of the v2 DNAS and source dsp about 2 years ago now just about making a valid Ogg Vorbis stream but it needed a lot more work to make things work correctly.

and based on looking at Ogg Vorbis numbers on other directories, there just doesn't seem to be interest in at least listing those sorts of streams (as i know of a few which are running Ogg Vorbis but aren't listed) so maybe there is a bit more a demand, but compared to main formats of MP3 and AAC, there's no contest on what people are using.

so it's probably a nice format to have support for at some point (as it would likely also open up the means to support Opus streams - since it uses a similar container iirc), but there's far more important things that can and should be worked on (e.g. providing AAC streams in a more compatible format than what we provide so they'll work with Flash and HTML5 audio) than what is essentially a niche format for the Directories a SHOUTcast DNAS would be able to be part off.

well, I guess if you fix acc for html5, that should do the trick too, android should play it, shouldn't it? That's basically what I care about, I used to run icecast two years ago and switched to sc because of mp3 encoding problems(horrible artifacts) and lack of a proper autodj(didn't hear of liquidsoap yet) and ogg worked best for mobile as well as for cross platform compatibility.
Get it working then, with 40% mobile traffic it's really hard to serve listeners with a 128kbps stream which is pretty unreliable on 3g, and also very traffic consuming.

[brando1962]

Hello DrO,
I continue here from the centova cast foruAfter dozen of restarts at the log rotate I try the 32bit version of the new dnas. Nothing, same problem: some of the streams (not all) restarts by centova at log rotate becouse sc_serv crash.
I try to switch back to the previus 32bit version (2.2.1. 109) and the crashes t log rotate stop.
I see 2 kind of problems, like Cande says:
One is for the crash at log rotate.
Other is still present from the 2.2.1.109.
Sometimes (not at log rotate) the server crash. I see these recurrent things in server crashing:
- The server is a 'live' session from and external encoder
- It doesn't crash if is a RELAY from another server
- It doesn't crash if is drived form sc_trans (autoDJ never crash)
- If a server is without source connected... sometimes it crash.

At the moment is not possible to me to get a test account. I 'll talk with my system administrator for seeing what is possible to do (all our servers have a VPN for all ssh connections).
Roberto

[aron9forever]

Originally Posted by brando1962

- It doesn't crash if is drived form sc_trans (autoDJ never crash)

This points out the obvious, it's a problem with whatever you're streaming with. Or better said, shoutcast's compatibility with said streamer

[Cande]

Originally Posted by brando1962

Hello DrO,
I see 2 kind of problems, like Cande says:
One is for the crash at log rotate.
Other is still present from the 2.2.1.109.
Sometimes (not at log rotate) the server crash. I see these recurrent things in server crashing:
- The server is a 'live' session from and external encoder
- It doesn't crash if is a RELAY from another server
- It doesn't crash if is drived form sc_trans (autoDJ never crash)
- If a server is without source connected... sometimes it crash.
Roberto

Hi Roberto,
actually, I never encounter crashes/hangs at log rotate: this has never been an issue in my case.
As Aron points out, the cause of this instability could be originated by the "streamer stack" (the tool/encoder/plugin used to send data to sc_serv).

Now I will try to add the Windows version of Shoutcast DNAS to my "chain", by setting it up as a relay between the streamer stack and the streaming server and see what happens...

... will let you know about the results.

Cheers!
Cande

[brando1962]

Hi Cande,
the problem of the crash at log rotate is describe here:
http://forums.winamp.com/showthread.php?t=376175

After the last DNAS upgrade, the problem was only for the 64 bit version of it.
No problems with log rotate in the 32bit version.

In the new version of the DNAS the problem is still present in the 64 bit version and olso in the 32bit version.

So at the moment we have to switch back to the old 32bit version of the DNAS to get work fine my customers.
But you know that the old version has many others bugs fixed in the new one.
It seems a problem of Segmentation fault but I can't understand why the problem is present only from the last 2 releases of the DNAS. And why only the old 32bit version works fine without this kind of crash.

[DrO]

well at least things are now consistent between the 2 builds. unless you or someone else can provide us access to a working test setup which exhibits the issue on which we can debug things, there really isn't much else we can do to attempt to fix the issue (as clearly the existing fixes which resolved some file handle leaks have now made things consistent with the builds in a manner not hoped for).

[paspa]

Originally Posted by DrO

well at least things are now consistent between the 2 builds. unless you or someone else can provide us access to a working test setup which exhibits the issue on which we can debug things, there really isn't much else we can do to attempt to fix the issue (as clearly the existing fixes which resolved some file handle leaks have now made things consistent with the builds in a manner not hoped for).

I can provide a test host that seems to have the problem.
This is setup with the previous version 2.2.1 (109).
Let me know if you need access.

[DrO]

i've been provided access by another user last night and have spent the last few hours on it to determine the cause of the issue and am now sorting out the fix for it to go towards the next build (am not sure at the moment when that will be due to other things going on at the moment).


for those experiencing the crash on log/w3c rotation issue, if there are any 0-byte w3c or log files in your log folder, you should remove them and then should be able to update to and run 2.2.2 without issue. it's only if the 0-byte files re-appear where the current DNAS release may crash (which is one part of the fix that will be made to ensure such files cannot cause a crash on attempting to archive them).


it also looks like the removal of 0-byte files from the log folder could help cases where the DNAS refuses to run after updating from some of the earlier 2.x builds.

[brando1962]

Hi DrO and thanks for your work.
About the workaround, I see lot logfiles at 0 byte in the log directory in the server affected by the problem. So I think you hit the problem.
But I see that is not easy to not have 0-byte files for a long time. If the server doesn't have listeners for a long time, no errors, etc etc... it easy that when the log rotate some file can be at 0 byte. So this cannot solve the problem for a long time (I see that in 12/24 hours, some server produce a 0-byte log file). It is like to say: More your stream is listened... less crash you have ! :-)

[aron9forever]

Originally Posted by brando1962

Hi DrO and thanks for your work.
About the workaround, I see lot logfiles at 0 byte in the log directory in the server affected by the problem. So I think you hit the problem.
But I see that is not easy to not have 0-byte files for a long time. If the server doesn't have listeners for a long time, no errors, etc etc... it easy that when the log rotate some file can be at 0 byte. So this cannot solve the problem for a long time (I see that in 12/24 hours, some server produce a 0-byte log file). It is like to say: More your stream is listened... less crash you have ! :-)

wouldn't a quick fix be to just stop logging?

[DrO]

the empty files is down to how the centova log rotate action works as using the cronjob caused empty files but the direct action in the DNAS didn't do it from what I saw under testing.

and until we provide a newer build (as we need to resolve some other issues), the new centova version has an option to not rotate the logs (if I remember correctly from what I saw last night).

[Spanic]

Hello!!

As a complete new member here, does anybody know why artwork, artist and song title (of my radio station) are not shown in some radio directories? This happened since yesterday and after I've updated to shoutcast V.2.2.2 by restarting centova in control panel.

Thanks

[DrO]

is probably related to point #3 -> http://forums.winamp.com/showthread.php?t=373139#known

[Spanic]

Originally Posted by DrO

is probably related to point #3 -> http://forums.winamp.com/showthread.php?t=373139#known

Thanks DrO but I've searched in shoutcast config but I don't see any disableicy to make it '0'

[DrO]

you have to add it to the config file yourself as most of the time the settings are not present in a v2.x config unless you put them in or that's how it has been created for you like that. as it's typically like that so the DNAS will just use it's defaults with only what needs to be changed being specified in the config file.

[Spanic]

Originally Posted by DrO

you have to add it to the config file yourself as most of the time the settings are not present in a v2.x config unless you put them in or that's how it has been created for you like that. as it's typically like that so the DNAS will just use it's defaults with only what needs to be changed being specified in the config file.

Well before updating, everything was fine!! I wish I knew how to add it as I'm not so expert to do this but in anycase the provider must do that as my access to shoutcast DNAS is limited despite I have access as admin.

[DrO]

it was an unfortunate bug that was introduced as part of required changes to improve connectivity with a lot of more clients by default. and it's not like there isn't a viable work around until a newer DNAS build is released which has those changes as detailed in the thread you have looked at.

so all you or your provider has to do until a new DNAS build is released, is use a text editor of your choice, add that required line to the config file, save the change and then restart the DNAS for the change to be applied.

[Spanic]

Originally Posted by DrO

it was an unfortunate bug that was introduced as part of required changes to improve connectivity with a lot of more clients by default. and it's not like there isn't a viable work around until a newer DNAS build is released which has those changes as detailed in the thread you have looked at.

so all you or your provider has to do until a new DNAS build is released, is use a text editor of your choice, add that required line to the config file, save the change and then restart the DNAS for the change to be applied.

Thanks ever so much DrO for your answer

[brando1962]

Ok, it seems that deleting 0-byte files + workaround by centova help to fix the problem for now.
But this fix the crash at log-rotate.
What about the second issue: the crash random probably caused from source (or not source connected) ?