Slow indexing from Windows file share

Comments

18 comments

  • Official comment
    Tony W.
    Product Support Manager

    Hi Rasmus

    Thank you for the log file - there is no issue with the network stack - please consider correcting the Artwork files that are 5000px square to improve performance.

    Please see; https://support.bluos.net/hc/en-us/articles/360000368827 for tips and tricks. Also, many of our consumers have had success with www.blisshq.com to optimise Artwork files in their library before indexing.

  • Seppi Evans
    Hi-Res

    Assuming both your PC and the Node are wired the Node could be resizing the artwork? There is an Optimise Artwork option in the Bluesound App.

    0
  • Rasmus

    Good suggestion but the feature is not enabled, I think its related to something deeper in the network stack, I see a lot of TCP Dup ACK's when the node 2i is reading from a windows file share, and only a few when reading from my Synology NAS.

    3000 song took less than 3 minutes using Synoogy, and almost 10 minutes using a Windows file share.

    It reminds me of an issue I saw about a your ago, it was caused by the Node 2i not having enough CPU power to process the packets from a gigabit network.

    0
  • Seppi Evans
    Hi-Res

    I did initially think it was more network related, you could try swapping the ports on your switch so your PC has the NAS port as your NAS has a Gigabit port?

    0
  • Rasmus

    I have tried moving to other ports (everything is gigabit), same issue.

    It's also very annoying that bluesound have removed the diag logs from the app :-(, but the more I look at the pattern the more I'm sure that the Node 2i network interface is flooded and can't process the incomming packets (just like I have seen before) because of a very low incomming buffer configuration.

     

    0
  • Seppi Evans
    Hi-Res

    You could try lowering the NICs speed to 100Mbps, not played with Windows for years but used to be an option.

    0
  • Rasmus

    The Windows 10 is also used as a fileserver, changing to 100Mbps would slow the entire network then. Also you can't change the speed on the node 2i ifself, so you would have to do it on the switch, and that is bad network behaviour, and actually not a supported method as specified by IEEE, if I remember correctly.

    0
  • Seppi Evans
    Hi-Res

    Sigh… it was for testing, 10 minute job to prove either way on the PC

    0
  • Rasmus

    100 Mbps seems to remove the issue from the data layer, but now the error counters in my switch has started to grow instead.

    I enabled flow control, even though its not best practice nor recommend, but now everything looks fine in wireshark and speed is better than ever, indexing songs 3000 took only 1 minute and 20 sec.

    The culprit here seem to be the Node 2i network stack, again :-(

    0
  • Tony W.
    Product Support Manager

    I enabled flow control, even though its not best practice nor recommend, but now everything looks fine in wireshark and speed is better than ever, indexing songs 3000 took only 1 minute and 20 sec.

    This all points to poor artwork or larger artwork (than needed) as per Seppi's original diagnosis - the reindex took much faster because it is an append of the original Index and Artwork is being ignored.

    None of what you describe is Networking related.

    Then you ask;

    10.000 songs took 1 hour and 15 minutes, the same operation took about 10 minutes using my Synology ds214 NAS.

    ..because Synology does not create a database of your music allowing you to cross-reference, sort or display it in the BluOS App.

    0
  • Rasmus

    Hi Tony,

    You couldn't be more wrong, sometimes I wonder if you are here to help or just to defend your products! I'll leave you the benefit of the doubt and explain in details why you are wrong.

    1. Every test I did was with a clean Node2i config, so no appending was going on, only new indexing.

    2. My artwork has no influence on my testing, they are all 800 x 800 pixels.

    3. The synology and windows host was configured as close as possible when it comes to TCP/IP.

    Here is what happens, looking at wireshark (network trace):

    Import from Synology.....lots of retransmission and out of order indicating that bluesound interface is flooded, the Synology is much faster than the Node2i so some errrors are expected.

    Import from Windows...80% or more is retransmit and other garbage indicating that the network interface is giving up on the Node2i. The windows host is and Core i5-10500 so my guess is that is like 10 times faster than the Synology.

    Sending network data from a fast unit to a slower one, will always have retransmit and other "ugly" stuff in the trace, what you can do on the slow side is to tune your network stack and you should be able to keep things more or less clean, e.g. the same procedure with my ZP80 Sonos from 2008 does not give any network errors, they have also spend a lot of time tuning the network stack.

    I also did some tracing after the import while playing music and again wireshark showed a lot of retransmitting, after that I enabled Flow Control on my switches and Windows Host and everything settled down, no more errors, only to and from the external partners that the Node2i is communicating with, but that makes sense since I don't have control over the traffic from external partners and they are not using flow control.

    So to sum up...EVERYTHING is related to the network stack, and you should definitely look into your network config on your products and tune the incoming buffers to accept more data.

    It's also quite funny that you write somewhere that the bluesound Node2i can index 1000-1200 tracks per minute, and with my simple tuning (flow control) I get 3000 song in 1 minute and 20 sec (from a Windows Host)....maybe I'm not so wrong after all ;-)

    Br

    Rasmus

    0
  • Tony W.
    Product Support Manager

    Just managing expectations and 1st rule of troubleshooting...

    Thank you for the additional information - please select Help, Send Support Request in the App with subject line community post 4417151495575.  This way I can send the log file along with your findings to our QA Team for review.

    0
  • Rasmus

    Will do.

    ../Rasmus

    0
  • Seppi Evans
    Hi-Res

    As Tony pointed out, a Rebuild Index is what should be run each time to compare like for like but either way it’s not something that’s done throughout the day.

    0
  • Bjørn Ulvik
    Hi-Res

    This is what should be expected from a Synology share; Tested on DS1812+, DS1813+, DS218j, Ds119j and RS1219+. All with the same result.
    Rebuilding index with optimize artwork on, about 40 seconds for 1000 files.
    Rebuilding index with optimize artwork off, about 20 seconds for 1000 files.

    0
  • Tony W.
    Product Support Manager

    Bjorn's numbers are consistent with current QA benchmarks of a wired NODE to a wired NAS. (Thanks for the real-world confirmation).

    0
  • Tony W.
    Product Support Manager

    Hi Rasmus

    Thank you for the log file - there is no issue with the network stack - please consider correcting the Artwork files that are 5000px square to improve performance.

    Please see; https://support.bluos.net/hc/en-us/articles/360000368827 for tips and tricks. Also, many of our consumers have had success with www.blisshq.com to optimise Artwork files in their library before indexing.

    0
  • Rasmus

    Hi Tony,

    I have replied to the support thread, lets keep it there until we have sorted out things, because right now you are jumping to wrong conclusions.

    Br

    Rasmus

    0

Please sign in to leave a comment.