Based on latest feedback I’ve spend the last few days performing another series of tests
Summary:
No impact/improvement by specifying LAN speed on the NUC at 100MB, nor did replacing the Ethernet Switch box with an RJ-45 cross-over Lan cable, NUC still fails/hangs. Also tried swapping out LAN cables on NUC and Primare, but again no effect. Not yet obtained/tried USB Ethernet adapter. However, additional testing using my Laptop proved more interesting, but also frustrating as odd pass/fail behavior was not repeatable.
100M vs 1G LAN speed comparison test:
Reconfigured the NIC in the NUC to be 100MB speed instead of enabling 1Gigb support and looped on a song/file shown to repeatedly fail.
Note: The Priamare BD32 MKII (as well as the OPPO BDP105) only support 10/100 LAN, so the 1GB capable NIC in the NUC Sever has to negotiate down 100Mb speed any Ethernet interaction anyway
- Test hardware NUC & Primare
- Album: Modified 7-walkers (7_Walker_test_3)
* Track 12 off this same album I’ve been using (7-Walkers) that O (track 12)
* Same song used 10 times with different track number and file name assigned.
* Metadata removed
- Files stored locally on NUC SSD, no NAS involved
- Selected Network configurations disabled in device manager (per prior responses)
- On the NUC Entered control panel and device manager/network adapters/Realtec PCIe GBE Family Controller/advanced tab/Link speed & duplex/ changed setting from Auto Negotiation to 100Mbps full duplex
- Rebooted NUC after setting change with system connected to home network
- Then disconnected from the home network
Result: Failed/hung consistently on first or second song (tested 5 time to confirm), so forcing Ethernet speed to 100Mb showed no change in failures.
Remove Ethernet Switch Box from the configuration:
Built and tested with RJ-45 crossover cable between NUC and Primare player instead of going thru the 1Gb Ethernet switch.
- Test hardware NUC & Primare
- Album: Modified 7-walkers (7_Walker_test_3)
* Track 12 off this same album I’ve been using (7-Walkers) that O (track 12)
* Same song used 10 times with different track number and file name assigned.
* Metadata removed
- Files stored locally on NUC SSD, no NAS involved
- Selected Network configurations disabled in device manager (per prior responses)
- After powering all unit on connected to home network I replaced Ethernet connections between both NUC and Primare to the Ethernet Switch Box with a single direct RJ-45 crossover cable between the NUC and Primare
- Also test with NIC speed configured using both 100Mb as well as Auto Negotiation in device manager
Result: NUC failed/hung consistently on first or second song (tested 5 time to confirm), so the Switch box does not appear to be a contributing factor in failures
Comparison Testing between Laptop and NUC:
Before starting this sequence of tests I first verified that the DLNA settings in MC on both the Laptop and NUC are configured the same.
Since the Laptop was consistently passing and I found a consistently failing test album played on the NUC my initial plan was to capture trace logs of both devices playing the same album/songs in passing cycles on the Laptop and then failing cycle on the NUC.
To do this I decided to use the same test album I have been using 7_Walker_test_3 (same song loaded 10 times), which consistently fails on the NUC and the “same” 7_Walker_test_3 test album loaded on the Laptop consistently passes on the Laptop. However, I noticed when playing this test album on my laptop there had to be some extra metadata loaded on the laptop local version compared to the same test album loaded on the NUC local drive. I found that my Laptop had the Library Import option box checked to Analyze audio on new files so when I imported the album it added the additional metadata. Both versions had Artwork removed and most of the other meta-data, but I still wanted to do an apple-to-apple comparison of the exact same test album. So I worked on getting the exact same files on both devices.
Because the two test albums had the same file/artist/album artist names I could not just copy/import the version from the NUC local drive onto my laptop local drive without MC displaying duplicate songs making it difficult to select what song to play. The next few steps I took resulted in some odd pass/fail behavior, but it might provide additional pointers to the root cause of my issue.
I copied the 7_Walker_test_3 test album from the NUC local drive and installed it on the Laptop local drive under a difference directory name so as not to disturb/edit the actual files. Since it has the same meta-data names I deleted the current 7_Walker_test_3 from the Laptop MC library (kept the files) and then imported the 7_Walker_test_3 files I copied from the NUC. Retested on the Laptop
Result: They failed, consistently on the first or second song on multiple test runs. That was a new behavior I have not been able to reproduce consistently on the Laptop until now. Since my Laptop was back in my office and on the home network I did not capture an Ethernet trace of this failure
However, I could now envision a possible way to capture Ethernet Trace logs of both a failing and passing cycle on a single device (Laptop) using the same song. I had the newly failing test album already imported, but now I needed to create and import the passing test album which I had previously removed from MC. So I created a copy of the original folder containing the 7_Walker_test_3 on the Laptop local drive and edited the meta-data to add an e at the end (NUC 7_Walker_test_3_e). I then imported and tested this slightly modified test album.
Test Result: Test album Walker_test_3_e passed as expected, but I went back and retested the 7_Walker_test_3 that I had copied from the Laptop (and this is the odd behavior) it would no longer fail
Hmmm… now what to do.
Odd, that importing the additional test album made the failing album start passing on the Laptop.
Next I thought I’d try the same kind of experiment using the NUC.
Here is what I tried: I made a copy of album 7_Walker_test_3 off the NUC (containing less meta-data) and edited Artist and Album_Artist, named it 7_Walker_test_4 and put it in a new folder on the NUC local drive also called 7_Walker_test_4. I then imported this into MC on the NUC. I then tested 7_Walker_test_4
Result: NO FAILURES. This was great, as it was the first time I’ve seen consistently passes on this song with the NUC as server.
I captured an Ethernet trace log showing the first four songs of 7_Walker_test_4 successfully playing (I stopped shortly after the forth song started).
Log 7:
https://drive.google.com/file/d/1sKyALvMCb3ykfhroFQxoxrM7NUrIWy_q/view?usp=sharingNext I retesting test album 7_Walker_test_3 on the NUC local drive in the hope I could now get a side by side comparison on a passing and failing cycle on the same server device with basically the same song, very small difference in meta-data.
Result: The original 7_Walker_test_3 of which I did not touch and which had consistently failed on the first or second play of a song….NO LONGER FAILS. I tested this multiple times. Now this was odd.
Next I rebooted the NUC/MC and retested 7_Walker_test_3 again.,
Result: Now it was back to failing on the first or second song, again! I tested this multiple times. Log 8 shows it failing at end of first song
Log 8:
https://drive.google.com/file/d/1GvsG0FYf8MuejOnIEm5xqwDVczhYhQx4/view?usp=sharingWe can compare Log 7 which captured passes cycles against Log 8 which captured fail/hung at the first song.
Question: Do these logs show any significant difference in behavior in terms of things like resets being sent?
Question: How might rebooting the NUC and reloading all the software cause this kind of behavior in this case. Memory getting reloaded differently?
I then retested test album 7_Walker_test_4 again.
Result: I was now failing as well on the first or second song.
Next, I wondered if I could back out the 7_Walker_test_4 album addition, reboot and add it back it again and see if 7_Walker_test_3 album will start passing again on the NUC.
Result: It still fail. This means I could not reproduce this odd sequence of events observed on the NUC
Given this odd (and unrepeatable) behavior using the NUC I decided to go back to testing with the Laptop again:
I first retested two of the test albums now residing on the Laptop local drive
- 7_Walkers_test_3 - The initial file (containing MC waveform analysis in metadata)
- 7_Walkers_test_4 - Same 10 audio files, but I copied the 7_Walkers_test_3 file off the NUC which has the waveform analysis in metadata removed) and renames the metadata/file name as 7_Walkers_test_4
Result: Both albums still passing (which is where I last left it) so I captured an Ethernet event log of a passing cycle of the first 4 songs of 7_Walkers_test_4 using Laptop as server.
Log 9:
https://drive.google.com/file/d/1etrhsnP2r_goiDc2EEEZvltVBLe1Ew_1/view?usp=sharingI created yet another test album 7_Walkers_test _5, an exact copy of 7_Walkers_test _4 and imported to see if loading another test album would will cause it to start failings so I could do a side by side Ethernet log comparison on the Laptop.
Result: No change, everything still passing (I did capture a log, but it’s all passing data playing the first four songs)
Log 10:
https://drive.google.com/file/d/1WN96LiLrzn4WKzqvtcqWzY-cLcFv_I6V/view?usp=sharingSo what to try next other than try a USB Ethernet card. Run memory test on memory card in NUC? Replace memory card? I've seen/logged failures with the Laptop as server, just not as repeatable as it is with the NUC.