Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[RoderickGI]

I'm in the same situation with my ISP Ralph. Actually, they are a Retail Service Provider these days, reselling Broadband provided by the National Broadband Network, but most people don't understand what RSP means, so I use ISP, mostly.

I nearly responded to that question with a page full of  . Telstra, my RSP, is the largest in Australia. The best support you can get out of them is from other users, via Crowd Support. They would replace the router if I complained enough... with another one exactly the same, and probably second hand. That would be it.

In your case I assume Comcast didn't provide and therefore isn't even responsible for the Asus RT-N66U router, so they probably wouldn't even try to assist.

[stevemac]

When I use my Android phone running Gizmo to try to connect to a MC Server running on my Workstation it fails.

Is the phone on the local WLAN or using the cellular network and coming in from the WAN?

Been a long time since I accessed MC from WAN, but used to have this issue (or something very similar) on Telstra Bigpond using their modem / router in bridge mode and an Asus router.  When I looked at it - each time it failed there was no entry in the ARP table for the media server's IP address.  I do not believe I solved it

Steve

[RoderickGI]

Local WLAN. Using the same DHCP Server on the router as wired connections, so same network segment.

[wer]

Yeah, don't bother calling Comcast, Ralph. Follow the testing advice I gave you and let us know the results.

[RalphBrooks]

Yes, I can formulate several theories but I prefer to work from data. Unplug the switch from your router, and test again.  Yes the nuc won't have Internet access for a while but that's not important.  Test repeatedly to establish whether or not the results are intermittent or not.  You had said before it happened "sometimes".

Great question and I did that testing this evening.  Stanger and stranger...
In short, it failed even when disconnected from the router!
By the way, when I say the failure happens sometime, I mean JRiver MC may stop playing after just the first song or it could take up to 6 or so songs, but I have not been able to get past around 10 songs unless I implement the polling configuration solution discussed earlier and then it never fails.

To be more specific on my test configuration: First I powered up my entertainment system including NUC PC and Primare as the DLNA renderer with the network connected, allowing all of the devices to be provisioned by the router.  I then disconnected the switch box from the rest of our home network (including the router) and configured JRiver MC to play a set of songs located on the NUC SSD drive.  The NAS (with the rest of the music files) is connected to our network on a different switch box in another part of the house so the NAS is removed from this test configuration.  Tested multiple times, still failed.  JRiver stopped playing at the end of either first or second song.

This then brought to mind could the issue be caused by one of the other devices in the entertainment system connected to that switch box (Direct-TV cable box, XBOX, PlayStation, Amazon Fire) so I disconnected all the other devices from the switch box such that just the NUC and Primare are connected.  I retested multiple times and again it consistently failed, anywhere after the first song to after the sixth song.

Next test I thought to try was replacing the existing switch box (ASUS Gigabit Ethernet switch: GX-D1018) with a different model (TPLINK Gigabit Ethernet switch: TP-DG1005D ) that I had laying around.  Result: Still failed, same symptom, sometimes the first song, sometimes after a few songs.

I then realized while Norton 360 is still removed from my NUC PC, the windows 10 firewall and re-enabled itself.  So I again disabled it and tested again.  Result: still failed

As another test I can try isolating these devices behind another router in LAN mode (yes, I'm sure I have another one laying about somewhere...), but that experiment will need to wait until tomorrow. However, based on my test results tonight I'm not convinced it would make any difference.  Now why my system configuration "passes" with the router connected to the network and the router firewall turned off I don't grasp the logic.

Aaaa the joys of technology...
Further thoughts?

[wer]

I can think of a several possibilities:

You made an error in your testing, you have an intermittent problem and jumped to the wrong conclusion, something is going on with wifi which is still letting the router be involved, or you have two problems, or you have a loop in your network.

With your router disconnected from the other devices as you just described, turn off the firewall and test again.  If changing the firewall setting affects the results of your tests, then either your router is still connected through a different path, or traffic is going over wifi to reach the router.  Then power off the router and try again.

[JimH]

In your case I assume Comcast didn't provide and therefore isn't even responsible for the Asus RT-N66U router, so they probably wouldn't even try to assist.

The manufacturer, Asus, should also provide instructions and general online advice.

Thanks, wer and RoderickGI, for the fine help.

Replacing the router with a newer or better one is also an option.

[RalphBrooks]

Hmmm...appreciate your creative perspective on possible issues with my testing.
In an attempt to mitigate those possibilities I offer the following data points:

Took Wifi out of the picture:
While the Primare can support wifi I have it configured in setup only for hardwire ethernet, so wifi is not enabled on that device.  Now the NUC has wifi capability and the driver was enabled, but I never setup wifi in Windows and it certainly was not be logged into the router  (l logged into the router and confirmed the NUC was not listed as a connected device).  Never-the-less I disabled the Windows wifi hardware driver, rebooted the NUC and retested.  Result: Still failed

Windows Firewall:
As for Win10 firewall on the NUC (Norton 360 still uninstalled) I tested both with it on and off while disconnected from the router and it failed in both configurations.

Router on or off:
I also went so far as to turn off the router late last night (hard to do during the day as others in the house rely on network access) and retested.  Result: still failed

Network loop:
As for test configuration or network loop I have reduced the test configuration to only two devices connected via an ethernet switch box.  Doesn't get any simpler than that and I see no possible network loop.

Possible error in testing:
So my prior data-point that is not consistent with my later test results is where turning off the router firewall the failure could not be reproduced.  So I ran as series of tests again with the router fire wall turned off.  Result: Failed, the same failing mechanism of stopping after the end of a song, but this time in multiple runs it only took between one to three songs before it stopped.  I can't explain my prior results of passing in this configuration, perhaps I just didn't run it long enough.

So where does my issue now stand.  I have the original JRiver logs showing what appears to be a communication issue where JRiver MC is not receiving a status change from the rendereer (Primare).  I have identified no systems configuration where the symptoms does not occur other than to configure the Primare DLNA Controller Options in JRiver MC to "Ignore Transport Events (Use Polling Mode)".  I can leave it at this and go with polling mode, but I'd really love to uncover the root of this failure mode.

The one remaining analysis I have not yet gone done is using Wireshark in the minimal network configuration (with router disconnected) and compare logs of network activity on a passing run (song plays and jumps to next song) vs failing run (song stops at the end). 

I do have one additional data point.  I pulled out and set-up my old OPPO BDP-105 player and confirmed it exhibits the exact same failure mechanism as with the Primare BD32 MKII.  I have not yet tried this experiment using my OPPO BDP-103 player, but I will.

[wer]

Possible error in testing:
So my prior data-point that is not consistent with my later test results is where turning off the router firewall the failure could not be reproduced.  So I ran as series of tests again with the router fire wall turned off.  Result: Failed, the same failing mechanism of stopping after the end of a song, but this time in multiple runs it only took between one to three songs before it stopped.  I can't explain my prior results of passing in this configuration, perhaps I just didn't run it long enough.

This is actually good progress.  I would put that down as an intermittent (or at least inconsistent) problem and it was the wrong conclusion that the router firewall was responsible. It's easy to go down the wrong path with inconsistent problems, so no one should blame you.  But it's good that we've now eliminated that possibility.  It also makes me feel better because my spidey-sense was tingling about that part.  I appreciate your being willing to test completely.  The problem with being in my position and being asked to speculate is I'm going to have to list some possibilities that the questioner might not "appreciate".    So don't take offense at that.

Wireshark would be the next appropriate step.  Andrew is very expert at this sort of issue, and the info from the sniff will probably point in the right direction.

[RalphBrooks]

Took me a few days to prioritize time back to working on my issue where a song will simple stop at the end and not start the next song, but I now have an Ethernet trace log of passing and failing play cycles and looking for assistance in better understanding what might be occurring on Ethernet that can point to a root cause of this issue.  Given the size of the log file (70MB) I could not attach it, but I have posted it to my goggle drive with open access as follows:
https://drive.google.com/file/d/10KKQNnpZjWcNgcKsjPqv7wrwfUlMAcGp/view?usp=sharing

Test configuration (very simple):
- Powered on entrainment system connected to network and allowed router to provision NUC (JRiver control/server) and Primare BD-32 MKII (Player/renderer) with only those two devices connected to a local switch box which I then disconnected from home network.
- IP addresses assigned by router:
Router: 192.168.1.1
NUC:  192.168.1.109
Primare/Oppo:  192/.168.1.246
- I started JRiver and in the DLNA controller Options menu for the BD32MKII and deselected the Ignore Transport Events (use polling mode).  Disabling this configuration as it is the work-around to my issue.
- I then selected a small group of 6 shorter songs located on the SSD drive in the NUC (no NAS involved in this test configuration)
- I started Wireshark Ethernet logging and then selected Shuffle play on JRiver

Test results:
Music stopped at the end of the third song played after which I then stopped Ethernet logging.

Log analysis:
Three songs played with the following relative position indicators in the log file showing the play command.
- First Song:  /Music/F561325.flac
      Line 86:  /control/AVTransport:play command from NUC to Primare
- Second Song:  /Music/F561329.flac
      Line 3762:  /control/AVTransport:play command from NUC to Primare
- Third Song:  /Music/F561324.flac
      Line 9937:  /control/AVTransport:play command from NUC to Primare

On all three songs once the song starts playing I see the NUC (control/player) repeatedly issue a series of commands:
- POST /control/AVTransport: #GetPositionInfo
- POST/control/RenderingControl: #GetVolume
- POST/control/RenderingControl: #GetMute
However, on the third song at line 16387 is the last of these sequence.  From there on all remaining commands are the NUC asking the Primare for position starting at line 16463
- POST /control/AVTransport: #GetPositionInfo
This is consistent with the behavior where the song is stuck playing the last second of the song.

What I can’t tell is what the Primare (player/renderer) is reporting back to JRiver MC in each of these cases and why at some point it keeps looping, asking for position.  Or why the renderer appears stuck playing the last second of a song.

Thought?

[zybex]

Just read the last post and felt like jumping in without reading the rest 

The repeated GetPositionInfo/GetVolume/Getinfo requests are for MC to update the UI with the current playback position and status.
It sounds like the Primare hangs, stops playing, and then MC keeps re-issuing the same command trying to get a reply which doesn't come.

I've had similar issues with a non-audio network device (a network-controlled RF filter) where my tool kept polling the device for status every second or so. After about 24h of this, the device froze and would no longer work until a reboot. We opened a case with the manufacturer and they found out an internal memory leak that, because of the thousands of status requests, kept inching up until a buffer overflow after some time. They issued a firmware upgrade that fixed it.

Your issue sounds exactly like that.

Theory 2:
As the Primare keeps playing until the end of song and then just doesn't move to the next one (because it doesn't receive a command), maybe the problem is the router/switch as I've seen mentioned above. Look for options related to Flood protection which are common in most routers and high-end switches. Also check for options related to IGMP Snooping and Multicast/Broadcast blocking.

[RalphBrooks]

Interesting, thanks for your input.  My scenario is a little different in that the player/renderer completes playing the song fine and isn't hung, but it could be intermittently reporting incorrect position data back to the player (JRiver on a WIn10 based NUC). Hoping the Ethernet trace files might provide more insight into failure mechanism details.  Like why does it only happen at the end of a song and not randomly in the the middle of a song?

I was able to reproduce this issue on both my original OPPO BDP-105 as well as my Primare BD-32 MKII which is based on the OPPO BDP-105 design.  Could be a common FW/SW bug in both devices, but if so I would expect anyone with an OPPO-105 (Primare units are MUCH less common) could reproduce this playing music via DLNA.  I have read on this forum reports of other OPPO-105 user reporting similar issue.  Also, this issue only occurred starting with MC release 25 and later.

[zybex]

Well, it's natural that the file completes playing, as that's how DLNA works. MC sends the Play command for a given file, and then doesn't really have to do anything else - the player will play the file to the end unless it receives another command. After the song finishes, the player has nothing else to do so it stays idle. In the case of MC, it keeps polling the device to know/display the current play status&position, but that's not required for the song to keep playing.

The issue is apparently one of these:
1. device stops responding to MC requests due to some bug/issue
2. switch/router starts blocking MC requests or device replies due to some misconfiguration, flood protection, etc.
3. A firewall on the NUC starts blocking packets due to flood protection (unlikely)
4. MC has a bug causing it to fail to process the Status replies and can't proceed to next song

You could look at the packet trace to check if the replies from the Player to MC are actually reaching the NUC. If those GetPositionInfo requests go unanswered, then the issue is likely 1/2; if the replies are arriving, then it's 3/4.

[RalphBrooks]

Hmmm... of the four scenarios you outline I'm more inclined to go with 4.  I have no firewalls installed in this configuration and I've swapped out the switch with a completely different model and same issue.  From what I see in the Ethernet log (posted on my goggle drive) the Primare is responding to all of the requests from MC/NUC, I just can't tell what it's responding without a better understanding of reading the log file.

[wer]

That's your penalty for not reading the rest of the thread, Zybex. We already eliminated 2 and 3.

Hopefully Andrew will know from the sniff.

[zybex]

Eh, sometimes a fresh pair of eyes can see new things... I'm too sleepy to read the whole thread

[JimH]

Have you tried the settings for broken renderers?

[RalphBrooks]

Jim,
Yes, previously confirmed a workaround for this issue by selecting the Ignore Transport Events (use polling mode) in the DLNA controller Options menu for the player (see prior responses for details).  This effort is an attempt to understand why the default transport event-based communication is not working.

[JimH]

There is at least one other setting for broken renderers.

[zybex]

I looked briefly at the packet capture.
In short, MC keeps polling the device for the position (GetPositionInfo). Near the end of the song, it polls more frequently until it receives an indication that the song ended, then it sends the PLAY for the next song.

For the good case (song of duration 3:11):
- MC polls repeatedly with GetPositionInfo
- device responds with current position = 3:08, then 3:09, 3:10, 3:11
- MC requests GetTransportInfo (3 times)
- device responds STOPPED (3 times)
- MC starts the sequence of commands to play the next song

For the bad case (song of duration 3:29)
- MC polls repeatedly with GetPositionInfo
- device responds with current position = 3:26, then 3:27, 3:28, 3:28, 3:28, 3:28 ... ad nauseum.

So MC keeps waiting for 3:29/STOPPED, which never comes.
Possibilities:
- renderer FW bug (not playing the last second, or misreporting the position due to rounding)
- corrupt file misreporting its real size? Maybe it says 3:29 but it's actually 3:28
- MC doesn't seem at blame here... but it could detect this stalled playback by issuing a GetTransportInfo intercalated with GetPositionInfo to check if it's STOPPED.

Last device reply, repeated:

<s:Body>
    <u:GetPositionInfoResponse
        xmlns:u="urn:schemas-upnp-org:service:AVTransport:1">
        <Track>
            1
            </Track>
        <TrackDuration>
            0:03:29.000
            </TrackDuration>
        <TrackMetaData>
             [truncated]&lt;DIDL-Lite xmlns=&quot;urn:schemas-upnp-org:metadata-1-0/DIDL-Lite/&quot; xmlns:dc=&quot;http://purl.org/dc/elements/1.1/&quot; xmlns:upnp=&quot;urn:schemas-upnp-org:metadata-1-0/upnp/&quot; xmlns:dlna=&quot;urn:schemas-dln
            </TrackMetaData>
        <TrackURI>
            http://192.168.1.109:52100/Music/F561324.flac?Reader=4
            </TrackURI>
        <RelTime>
            00:03:28
            </RelTime>
        <AbsTime>
            00:03:28
            </AbsTime>
        <RelCount>
            2147483647
            </RelCount>
        <AbsCount>
            2147483647
            </AbsCount>
        </u:GetPositionInfoResponse>
    </s:Body>

[RalphBrooks]

There is at least one other setting for broken renderers.

Since the OPPO does not support gapless playback the Disable SetNext Support (for broken renderers) is automatically checked when MC checks the OPPO for capability. Of the other three options in DLNA Controller Options setup only the Ignore Transport Events (use polling mode) option made a difference.

[RalphBrooks]

I looked briefly at the packet capture.
In short, MC keeps polling the device for the position (GetPositionInfo). Near the end of the song, it polls more frequently until it receives an indication that the song ended, then it sends the PLAY for the next song.

For the good case (song of duration 3:11):
- MC polls repeatedly with GetPositionInfo
- device responds with current position = 3:08, then 3:09, 3:10, 3:11
- MC requests GetTransportInfo (3 times)
- device responds STOPPED (3 times)
- MC starts the sequence of commands to play the next song

For the bad case (song of duration 3:29)
- MC polls repeatedly with GetPositionInfo
- device responds with current position = 3:26, then 3:27, 3:28, 3:28, 3:28, 3:28 ... ad nauseum.

So MC keeps waiting for 3:29/STOPPED, which never comes.
Possibilities:
- renderer FW bug (not playing the last second, or misreporting the position due to rounding)
- corrupt file misreporting its real size? Maybe it says 3:29 but it's actually 3:28
- MC doesn't seem to blame here... but it could detect this stalled playback by issuing a GetTransportInfo intercalated with GetPositionInfo to check if it's STOPPED.

Last device reply, repeated:

<s:Body>
    <u:GetPositionInfoResponse
        xmlns:u="urn:schemas-upnp-org:service:AVTransport:1">
        <Track>
            1
            </Track>
        <TrackDuration>
            0:03:29.000
            </TrackDuration>
        <TrackMetaData>
             [truncated]&lt;DIDL-Lite xmlns=&quot;urn:schemas-upnp-org:metadata-1-0/DIDL-Lite/&quot; xmlns:dc=&quot;http://purl.org/dc/elements/1.1/&quot; xmlns:upnp=&quot;urn:schemas-upnp-org:metadata-1-0/upnp/&quot; xmlns:dlna=&quot;urn:schemas-dln
            </TrackMetaData>
        <TrackURI>
            http://192.168.1.109:52100/Music/F561324.flac?Reader=4
            </TrackURI>
        <RelTime>
            00:03:28
            </RelTime>
        <AbsTime>
            00:03:28
            </AbsTime>
        <RelCount>
            2147483647
            </RelCount>
        <AbsCount>
            2147483647
            </AbsCount>
        </u:GetPositionInfoResponse>
    </s:Body>

Issue occurs on songs at random (plays them completely sometimes, fails on other passes), find it very unlikely issue caused by corrupt file reporting incorrect song length, open to defining an experiment to definitively prove this. One more data point on this music source from DLA as well as sourced from local SSD drive exhibit the failure.

[zybex]

Yes, but the replies from the device are wrong. It points to a FW issue.
Can you try removing all tagging/Clipart from a bunch of files and try playing them? Just so the player doesn't see extra data at the end of file.

[RoderickGI]

I'm still looking.

I'm more interested in the lack of response from MC to these requests:

GET /Music/F561325.flac?Reader=2 HTTP/1.1

Even for the first two tracks MC fails to send some of the file. In all cases, the trace shows that MC sends a partial file, then when later requests are sent, MC fails to respond.

For example, for the first file:
Frame 68 to 82 There is an Event Subscription.
Frame 94 The Renderer sends a "HEAD /Music/F561325.flac?Reader=2 HTTP/1.1" request to the Server.
Frame 95 The Server responds with "HTTP/1.1 206 Partial Content", which is fine, although there appears to be a minor anomaly with the Content length being 2900857, while the Content-Range: is 0-2900856. Maybe that 1 microsecond is the problem, if MC thinks it never gets to the end. But, MC works for some tracks, so I'll have to check the third track.
Frame 104 The Renderer sends a "GET /Music/F561325.flac?Reader=2 HTTP/1.1" to the Server, but there is no response to close that HTTP conversation. The Server does send the data though, as can be seen by packets with payloads.
Frames 662 to 681 That conversation finishes with the Renderer sending Reset packets to the Server.
Frame 683 The Renderer sends another "GET /Music/F561325.flac?Reader=2 HTTP/1.1" to the Server, but again there is no response to close that HTTP conversation. Again, the Server sends data, but I can't tell if it is resending data that it thinks the Renderer didn't receive, or sending the next part of the file.
Frame 1303 That conversation finishes with the Renderer sending Reset packet to the Server.
Frame 1319 The Renderer sends another "HEAD /Music/F561325.flac?Reader=2 HTTP/1.1" request to the Server.
Frame 1339 The Server responds with "HTTP/1.1 206 Partial Content", which is fine.
Frame 1353 Another GET. No response. Data sent.
Frames 1897 to 1902 Another RESET.
Frame 1904 Another GET. No response.
Frame 2539 Another RESET.
Frame 2543 HEAD
Frame 2544 Partial Content.
Frame 2553 Another GET. No response.
Frame 3447  Partial Content.

That finishes file F561325.flac.

There is some conversation back and forth. The Server responds to all Renderer requests with a "HTTP/1.1 200 OK" as it should.

Frame 3627 to 3739 There is another Event Subscription.
Frame 3770 The Renderer sends a "HEAD /Music/F561329.flac?Reader=3 HTTP/1.1" request to the Server to start processing the next file.
The above process is repeated.

The process is repeated for the third file, and the only difference I can see is that the Renderer doesn't send a RESET to the Server after the last GET HTTP conversation. Why that is the case, I can't tell. Memory being filled on the Renderer, or handles, could be the issue. Maybe as it didn't receive any Response to its GET requests it is holding on to the earlier data. Although the RESETs should clear that.



Anyway, I have to get on to other stuff now. Maybe I will come back to the last conversation in the trace, or maybe someone else can find something in it. I haven't read the last few posts as I have been typing this up.

[zybex]

Frame 95 The Server responds with "HTTP/1.1 206 Partial Content", which is fine, although there appears to be a minor anomaly with the Content length being 2900857, while the Content-Range: is 0-2900856. Maybe that 1 microsecond is the problem

HEAD requests are just to get the headers and always result in 206.
The numbers are bytes, not ms. Range from 0 to 2900856 = 2900857 bytes in total, so that's OK.

Looking at the TCP streams, the conversation is really all messed up; multiple attempts to GET the file where eventually the ACKs get out of sync with the Sequence numbers, resulting in TCP RESET of the conversation and another GET retry.

It seems your ECS/Realtek network card is sending 32KB packets, which is completely off specification (not as a fragmented datagram, it's really full 32KB non-fragmented segments). The device doesn't seem to like them - each 32KB packet sent by the NUC gets 10 or 12 ACK replies with increasing sequence numbers up to the actual expected ACK; eventually the numbers derail and no longer match the expected values, and the connection is reset. Then the device tries again. This may be causing incomplete data transfers, as I even see the device sending ACKs for sequence numbers which weren't even sent yet (so the device thinks it has received more data than it actually has)

Jumbo frames aren't supposed to go above 9KB, while normal packets are usually just 1500 bytes. A 32KB packet is called a Super-Jumbo-Frame (SJF), but I don't expect anything out there to support it. It requires much larger buffers and explicit support on both sides. From the multiple ACKs, it looks like the device is trying to cope by sending ACKs as the data is arriving and filling its small buffers, but many times it loses track and resets the stream.

Here's what you can do:
- Check your network card properties and disable SJF, and even simple Jumbo Frames
- Check the MTU size for this card with "netsh interface ipv4 show subinterface". Was it tweaked with some tool? Change it back to 1500
- update the NIC driver

[RoderickGI]

The numbers are bytes, not ms. Range from 0 to 2900856 = 2900857 bytes in total, so that's OK.

Doh! Of course.

Nice diagnosis. Hopefully, your suggestions will fix the issue. I'm going to check if any of my NICs have Jumbo Packets turned on. They shouldn't, but...

[JimH]

I had a problem once (don't remember what it was) that was solved by turning off jumbo packets.

If there have been other changes to the network card settings, it might be related to this problem.

[AndrewFG]

It seems your ECS/Realtek network card is sending 32KB packets, which is completely off specification

Hats off to @zybex for his very insightful analysis!
=> OP please let us know if it fixes your problem.

Just to add my 2c on top of @zybex's analysis of your Wireshark trace: it also proves that both of the potential UPnP mechanisms for tracking a renderer's transport state and position are working fine in your case...

a) the NOTIFY (eventSub) messages are working and also
b) the SOAP GetTransportState, GetPositionInfo, etc. transactions are working

So -- once you have fixed the Jumbo packet issue -- you can (should) also turn off "Ignore Transport Events"...

[RalphBrooks]

Thanks all for your time and effort in looking into the details on my issue.
I did the checks and changes as proposed above, but it doesn’t appear the discussed LAN settings are the issue.  Perhaps I’m still not looking in all the right menus, but if the setting are already correct it again raises the question of the behavior seen in my initial Ethernet trace log.  In this cycle I also tested some additional audio file configurations with a combination of passes and fails that be insightful.  I also propose to capture two more Ethernet log files for two different test configurations.

Test results as follows:

- Checked LAN Driver:  Updated, still fails
The Intel Driver Assistance Utility said the NIC driver was up to date, but upon telling the windows device manager to search for a new drive it found an update from Realtec that I installed and rebooted NIC. Tested before and tested after, same failing symptom. (See attached screen capture of driver screen LAN config_screen2)
Old Driver:  10.2.703.2015
New Driver: 10.16.323.2017

- Checked LAN config for Jumbo Frame setting: Appears to already be disabled
Unless there is another configuration menu I didn’t see it appears to already be disable!
(See attached screen capture of driver screen LAN config_screen2)

- Checked MTH setting: Appears to already be set to 1500
At command prompt entered "netsh interface ipv4 show subinterface".  Screen displayed shows MTH set to 1500. (See attached screen capture of MTU setting MTU_screen1)

- NUC LAN Configuration History:  Factory default
No customization on the default LAN setting have ever been done on this NUC since I installed Win10.

- Testing with another computer:  Still failed
In earlier testing I used a Win10 based Thinkpad laptop running MC ver 27, with music files located on my NAS and my Primare BD-32 MKII as the renderer over my home Ethernet.  I was able to reproduce the failure mode.  However, given concerns being observed regarding the NUC LAN data I decided to retest using the laptop. I was again able to reproduce the same failure mode.  Network adapter in the laptop is based on an Intel 82577LM Gigabit controller.  I selected one of my FLAC music library play lists and put MC in shuffle mode.  Over three test runs it failed on the eighth song, the first song and then again on the eighth song played in each run.  Given the completely different hardware configuration I can setup the same limited network configuration using the laptop and run Wireshark to capture another Ethernet trace log, but first I wanted to try a few other test configurations, as follows.

- Tested looping on a single music file: Passed
Use the NUC I looped for around 40 min on just one of the tracks (about 4 mins long) from the same album I used for the initial Ethernet trace capture.  No failure observed.  I then thought maybe looping on the same song results in a different Ethernet handshake so I tried the next test.

- Tested with smaller music files: Passed
I created a set of songs based on a single track from the same album I've been used for the Ethernet trace capture.  I took the shorted song (about 30 second long), copied it 8 times, removed most of the meta-data, including artwork and just keep basic album, track name and artist name so I could track playing MC.  I looped on the songs for around 30 mins and no failure observed.  Interesting, it passed, but I changed two variables in this test case, the file size selected was small and I made it even smaller eliminating most of the meta-data.  So off to the next test configuration to try and narrow the changes needed to create a passing configuration.

- Tested full album without metatdata: Failed
Using the NUC I took the same album used for the initial LAN trace capture, I just removed the artwork and most of the metadata from each file and ran it again.  On two runs it failed after the third song and then after the fifth song.

Next steps:
My current thought it I can capture two more Ethernet trace logs one with the NUC and another using my laptop.
I can use the same reduces network configuration of only two devices connected to the switch box and playing the test album of song where I removed the meta-data as a means to reduce the handshake overhead on each pass.

Open to recommendations on different or additional testing configurations based on latest feedback …

[wer]

I haven't looked at the sniff, but guys, you should be aware that packet lengths in Wireshark can be dramatically wrong due to the effects of offloading. This is driver config dependent. 

The OP should check the offloading config on the card. Disable it if you want worse performance but wireshark to be more accurate.  Perhaps that would be a good temporary step.  I doubt it will affect the DLNA behavior but it might help you to better see what is actually happening.

Your most accurate results from any sniffing software will come when it's run on a separate machine, connected to a hub (or monitoring port if the switch has that feature).

[zybex]

Bummer. Now I need to return all those premature kudos.

Yep, wer is right, I was tripped by the "Large Send Offload" option, as explained here:
https://packetbomb.com/how-can-the-packet-size-be-greater-than-the-mtu/

Mr. Brooks, could you please disable Large Send Offload and repeat the packet capture so that we can better analyze the packet sequences? The sequence numbers still look funny, regardless of the offload effects. The rest of the analysis stands.

[wer]

This is really not surprising. Jumbo frames are normally disabled by default, but SOME kinds of offloading (especially checksum) are usually enabled by default. It just depends.  And honestly, if a blu-ray player even had the ability to digest and respond to a super jumbo frame, I'd be shocked; although I admit it is not something I have ever tested.

If you're going to run wireshark on a machine involved in the problem, I would recommend you disable ALL the offloading on the card. Go through all the options, write down what offloading is already enabled, and make a note that you are disabling it, so you can revert later. Also be aware that your driver might use a term like "Hardware acceleration" to refer to offloading; that's what it is: using asics on the nic to eliminate the need for the driver to do certain types of processing.

[RoderickGI]

Double bummer.

I just checked whether Jumbo Frames was turned on for my Workstation and found it was. Turned it off, hoping it would fix the anomalies I see with Gizmo and my Workstation MC Server. Nope.

I was wondering how you decided packets were 32Kb Zybex, and was going to look further at the trace. Now I won't bother.

I guess I need to find time to start a thread analysing my router, hey Wer. Not today. A visitor is coming! A rare event recently, as we get close to coming out of Coronavirus Lockdown.

[RoderickGI]

Should Checksum Offloads be disabled for testing as well Wer?

My Realtek NIC has five Checksum Offloads settings which are all set to Send and Receive (Rx & Tx Enabled). I would assume Ralph's NICs have the same settings.

[wer]

Yes, I would recommend turning them all off. I just said that in a previous post. (just note what you do so you can turn them back on later).

Generally having them turned on is very good. But it's bad for Wireshark.  If you have checksum offloading turned on, Wireshark will also see incorrect packet lengths because it won't see the FCS.   However these discrepancies will be smaller than the massive ones caused by segmentation offload.

Disabling all this stuff can cause performance problems under heavy load, but I doubt that will be an issue snooping DLNA.  I think wireshark has an option to ignore FCS to counteract false errors, called disable checksum validation, for when you have to use checksum offloading.

And before you get too excited about me looking at your snoop, the reason I haven't bothered to look at the one already for this thread is that I am by no means an expert on the DLNA protocol. I would expect Andrew to see 50x more problems with DLNA than I would catch.

[RalphBrooks]

Worked today reconfiguring NIC options and attempting to capture additional Ethernet trace logs using both my NUC and my Laptop running MC.  Interesting results and one new log captured/posted using NUC, but I’ll  need another day to try and obtain second trace log using Laptop.

NUC Testing:
- Reconfigured NIC setting in Device Manager Advanced tab where I changed the following options from enable to disabled:
     Advanced EEE
     Flow Control
     Interrupt Moderation
     IPv4 Checksum Offload
     Large Send Offload V2 (IPv4)
     Large Send Offload V2 (IPv6)
     NS Offload
- Same test configuration as before, only NUC and Primare connected to Network switch and disconnected from home network.
- Started Wireshark Ethernet logging
- Selected only my edited album (13 files, metadata and artwork removed), files located on NUC SSD drive, selected play (not shuffled, started at track 1). 
   Result: MC stopped/failed on end of second song.  I have uploaded this new Ethernet trace log to my Google drive:
               https://drive.google.com/file/d/10KKQNnpZjWcNgcKsjPqv7wrwfUlMAcGp/view?usp=sharing

- Observation:  The second track on my test album appears to fail more often than other tracks (I’ll guess at around 80% of the time I play it). 
- To ensure it not an issue with that particular track I did two more tests with the NUC. 
- Deselected track 2 from the songs to be played and restarted playing. 
  Result: fail/hung at the end of seventh song.
- Reconnect network switch to home network, selected a playlist from music on my NAS and start Play (Shuffle mode).   
   Result: MC stopped/failed on end of third song. 
- Results indict the NIC setting changes did not change the failing behavior on the NUC/Primare configuration.
- Now the question is does this new Ethernet trace log capture behavior that makes more sense than my initial trace log from yesterday?

Laptop Testing:  Still attempting to get an Ethernet trace log of a failing cycle
- Lenovo ThinkPad with Intel 87577M Gigabit Network Controller. 
- Reconfigured NIC setting in Device Manager Advanced tab where I changed the following options from enable to disabled:
     Adaptive Inter-frame spacing
     Flow Control
     Interrupt Modulation
     IPv4 CheckSum Offload
     Large Send Offload V2 (IPv4)
     Large Send Offload V2 (IPv6)
     TCP CheckSum Offload (IPv4)
     TCP CheckSum Offload (IPv6)
     UDP CheckSum Offlaod (IPv4)
     UDP CheckSum Offlaod (IPv)
- Connected only the Laptop and Primare to the Network switch and disconnected from home network.
- Started Wireshark Ethernet logging
- Selected only my edited album (metadata and artwork removed), files located on Laptop SSD drive, selected play (not shuffled, started at track 1). 
   Result: NO FAILURE, played all 13 tracks of the album. Hmmm…

- I now have a number of other test runs to try with the Laptop to understand if it’s just takes longer to fail than playing 13 tracks or if either moving the laptop location on the network or something in the NIC configuration changes are impacting failure mode.
- I’ll have more results tomorrow.

[RoderickGI]

Basically the same symptoms as before. The trace may be a bit cleaner, but I'm no expert on that.

For the first two files the Renderer sends RESETs to the MC Server, and the GetPositionInfo requests get the correct answer that the playback has reached the full duration of the file(twice on the second file). Then a GetTransportInfo gets a response of STOPPED (twice on the first and second file). Then the Server sends SetAVTransportURI with the URI of the third file. Then the Server sets Play.

For the third file there is no RESET of the MC Server, and the GetPositionInfo request never gets a response where the position matches the duration.

From memory, MC tries to send the next file to a DLNA Renderer 30 seconds before the current file finishes. Your first file is only 33 seconds long, so to be safe I wouldn't use that for tests. Aim for files at least 1 minute files. Trim down existing files if you wish, using the Convert function with the [Playback Range] field set to a minute or so, which will result in converted files with a duration that matches the [Playback Range] set.

The third file consistently doesn't get to the end. Eliminate it from testing, as it may be the problem. If the problem goes away when using other files, then maybe the file itself, or any file that fails, could be the cause of the problem.

[RalphBrooks]

Basically the same symptoms as before. The trace may be a bit cleaner, but I'm no expert on that.

For the first two files the Renderer sends RESETs to the MC Server, and the GetPositionInfo requests get the correct answer that the playback has reached the full duration of the file(twice on the second file). Then a GetTransportInfo gets a response of STOPPED (twice on the first and second file). Then the Server sends SetAVTransportURI with the URI of the third file. Then the Server sets Play.

For the third file there is no RESET of the MC Server, and the GetPositionInfo request never gets a response where the position matches the duration.

From memory, MC tries to send the next file to a DLNA Renderer 30 seconds before the current file finishes. Your first file is only 33 seconds long, so to be safe I wouldn't use that for tests. Aim for files at least 1 minute files. Trim down existing files if you wish, using the Convert function with the [Playback Range] field set to a minute or so, which will result in converted files with a duration that matches the [Playback Range] set.

The third file consistently doesn't get to the end. Eliminate it from testing, as it may be the problem. If the problem goes away when using other files, then maybe the file itself, or any file that fails, could be the cause of the problem.

So I'm reading thru your response this morning and confused because you're seeing three songs played...and saying it similar to the prior log results.
But the latest log I captures should only be 2 songs long.
Woops, just realized in my late night post I incorrectly added the link to my initial log, not the latest log as I intended, very sorry.
So here is the link the correct log from my NUC/Primare trace log I captured yesterday.
https://drive.google.com/file/d/12MMS9xw_sw80aCyAd2oNu2S-mSRvdIR-/view?usp=sharing

The first song played (track 1) is still the short 33 seconds long song so I will remove that from future tests runs.
Now what do you see?

I'm also working to get a log with failing cycle using laptop running MC instead of my NUC.

[wer]

The third file consistently doesn't get to the end. Eliminate it from testing, as it may be the problem.

No, I think there is a better approach for this.  Data-based problems can certainly happen, and we have an opportunity here to test for and eliminate or confirm this possibility.

A better way is to simplify your playlist:

Pick one track that you believe consistently works.  Duplicate it on disk 10 times; same data, 10 file names. Repeat it 10 times in the playlist, a different file name each time.  The same song/data (but a different file name) over and over.  See if your problem manifests.

If the problem does NOT manifest, take a "suspect" track, one that has been the choking track before, and insert it into the playlist.  Does playback stop at the suspect track?  Move the suspect track around in the playlist.  Does the cessation of playback move with the suspect track?

Using this compound test, we will know if we have a data problem or not.

Confirming or eliminating things is essential, so we know what to focus on.

[RoderickGI]

Woops, just realized in my late night post I incorrectly added the link to my initial log, not the latest log as I intended, very sorry.

Oh, bother. I should have realised that. Same file size, now I look.

A better way is to simplify your playlist:

That is an even better idea.

Just make the selected track at least one minute long, to eliminate making MC cope with short tracks. You can test with short tracks later if you need to. It should handle them fine, but the sequence will be better with the longer tracks.

[RoderickGI]

Well, the trace from Reply #87 does look cleaner. But the process follows the same pattern as before.

For the first file that works, the Renderer sends RESETs, but also reports playback gets to the end with a [FIN, ACK], then the process moves on to the next file.

With the second file there are also RESETs sent, but playback again stops at position 3:28 for a 3:29 duration file. Is that the same file? It looks like it. So a data issue could be the cause all along. Even more reason to try as Wer suggests above, first with copies of a file that you know plays, then introduce files that fail.

Or even just try to play the second file from this trace first in a Playlist, and see if it works or fails.


PS: I don't pretend to be able to follow all the [ACK], [PSH, ACK], Seq, and Ack packets. But I can't see anything that stands out in them either. The Renderer just never reports getting to the end of the file that fails. So MC never sends the GetTransportInfo request, so the Renderer never reports that it has stopped, so MC never sends the next SetAVTransportURI with the next file information, and hence the AVTransport:1#Play can't be sent.


PPS: What does MediaInfo report for the duration of that file that fails?

[RalphBrooks]

Well, the trace from Reply #87 does look cleaner. But the process follows the same pattern as before.

For the first file that works, the Renderer sends RESETs, but also reports playback gets to the end with a [FIN, ACK], then the process moves on to the next file.

With the second file there are also RESETs sent, but playback again stops at position 3:28 for a 3:29 duration file. Is that the same file? It looks like it. So a data issue could be the cause all along. Even more reason to try as Wer suggests above, first with copies of a file that you know plays, then introduce files that fail.

Or even just try to play the second file from this trace first in a Playlist, and see if it works or fails.


PS: I don't pretend to be able to follow all the [ACK], [PSH, ACK], Seq, and Ack packets. But I can't see anything that stands out in them either. The Renderer just never reports getting to the end of the file that fails. So MC never sends the GetTransportInfo request, so the Renderer never reports that it has stopped, so MC never sends the next SetAVTransportURI with the next file information, and hence the AVTransport:1#Play can't be sent.


PPS: What does MediaInfo report for the duration of that file that fails?

The album used for the second Ethernet trace log I posted was the full album, I just remove the meta-data and reconfigured the network controller setup options.  So the first and second song as different.  Track 2, which one of the tracks that failures/hang occurs often is reported via MediaInfo as 3:29 long.

I have been performing a series of tests on both my NUC and Laptop using the methodology proposed by Wer.  Failures do appear to follow the suspect songs, but failures is intermittent and don't fail/hang every time on the suspect tracks.  I will post those results shortly.

[wer]

If failures NEVER occur with "good" songs, and SOMETIMES occur with "suspect" songs, then we could be looking at a combination of factors: problematic data in certain files that combine with certain software conditions to create the failure - but neither the file nor the condition alone are enough to cause failure. Those can be difficult to identify and fix.

[AndrewFG]

Do your tracks have idv3 meta data tags?

My reason for asking is that with some file formats, with some tagging utilities, the idv3 block is right at the end of the file. And I have seen some renderers that try to “play” the tag, and get sick. Particularly if the tag contains one or more, large, album art icons.

So try de-tagging your test files. And/or try setting MC to “always convert, to PCM no header, L16” because that setting will push the tracks transcoded ‘bare’ without any tags.

[RalphBrooks]

Do your tracks have idv3 meta data tags?

My reason for asking is that with some file formats, with some tagging utilities, the idv3 block is right at the end of the file. And I have seen some renderers that try to “play” the tag, and get sick. Particularly if the tag contains one or more, large, album art icons.

So try de-tagging your test files. And/or try setting MC to “always convert, to PCM no header, L16” because that setting will push the tracks transcoded ‘bare’ without any tags.

Interesting idea.  My testing the last few days is with test albums reconfigured to where I removed artwork and most of the meta-data.  I did keep a minimal amount of meta-data to show tracks, song name, album name. 

I have the "add or configure DLNA Servers/Audio/Mode" configuration set to "Original", but I will do an experiment setting the Audio Mode to "specified output" and Format to "PCM L16 No header".  If you are rereferring to a different set-up menu let me know.

[RalphBrooks]

Interesting idea.  My testing the last few days is with test albums reconfigured to where I removed artwork and most of the meta-data.  I did keep a minimal amount of meta-data to show tracks, song name, album name. 

I have the "add or configure DLNA Servers/Audio/Mode" configuration set to "Original", but I will do an experiment setting the Audio Mode to "specified output" and Format to "PCM L16 No header".  If you are rereferring to a different set-up menu let me know.

Nope, tried those setting, still fails/stops at the end of a song (using NUC/Primare combination).

But I have observed something to make it pass that I had not tried before.  If I start a song that I expect will fail, let's say it's 3:29 long and after a few seconds of playing I then skip ahead to anywhere past the 60 second mark (also tried 1/2 and 3/4 way into the song) it will pass.  If I start and only skip about 10-seconds into the song it will still fail.  A data point, but I don't know it helps.

I've not posted my other results yet as I'm trying to understand why my NUC/Primare combination can reproduce failures consistently on at least specific songs, but my Laptop/Primare combination which had at least been demonstrating intermittent failures, now appears to be passing consistently!  Backing out the changes done to that system like to the NIC settings to see if that might be what is now allowing it pass consistently...stay tuned...

[wer]

Ok.  Do make sure you finish up the testing I prescribed before, as that will give us a clear indication.

[RalphBrooks]

And my saga continues....
After several days of additional testing I have some new input and I’ve captured additional Ethernet log files.
Summary (at least my take on the results): 
-  Failures appear to follow specific songs (files). 
-  Some songs appear to never exhibit the failure mode, others may fail intermittently and some fail consistently
   (at least when using the NUC as the server)
-  Some songs appear to fail consistently using the NUC, but when I attempted to reproduce the same failures using my Laptop they all passed (played correctly)
-  While I able to reproduce (and log) failures using my laptop on multiple earlier runs I am now unable to reproduce any failures using the laptop as the server, even after backing out changes to files, network and laptop NIC configurations.

Testing Details:
First I decided to try and capture a failing cycle using a different server, my laptop running MC instead of the NUC.
I did this test before Wer’s email recommending a different test methodology so it used my initial test album, but I did eliminated the first short track (only 33 seconds long) and second track which appeared to be failing more often (about 80% of the time using the NUC).  As this is a completely different device as the server I thought it may be useful to see if the network communication behavior is the same or different from the NUC.
-  Test hardware Laptop & Primare
-  Album: Modified 7-walkers (7_Walker_test_2)
    *  Metadata removed
    *  Files stored locally on Laptop SSD, no NAS involved
-  Disconnected from the home network
-  Only Laptop and Primare connected to Network switch
-  Tracks 1 and 2 not selected to play
-  Selected Network configurations disabled in device manager (per prior responses)
Results:  Failed/stopped on the eighth song played (track 10 on the album)
Log 3:  https://drive.google.com/file/d/1tADNgJCvFdBrJtuprvKXwqvpbZX3SL3-/view?usp=sharing

Next, once I read Wer’s email I worked to identify a song off my test album that doesn’t exhibit the failure. I went back to using the NUC to start off this testing.
-  Test hardware NUC & Primare
-  Album: Modified 7-walkers (7_Walker_test_3)
    *  Selected one song off this same album I’ve been using (7-Walkers) and that I didn’t recall having seen fail/stop before (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
-  Disconnected from the home network
-  Selected Network configurations disabled in device manager (per prior responses)
Results: Failed on the second song.  I reran this test 3 more times, and it consistently hung on first or second song.
Log 4:  https://drive.google.com/file/d/1_DZ3_C60tqzgF6O_xi7gqsAfE_Ma00Oz/view?usp=sharing

I then decided to repeat the last test configuration, but use my Laptop instead of the NUC
-  Test hardware Laptop & Primare
-  Album: Modified 7-walkers (7_Walker_test_3)
    *  Selected one song off this same album I’ve been using (7-Walkers) and that I didn’t recall having seen fail/stop before (track 12)
    *  Same song used 10 times with different track number and file name assigned.
    *  Metadata removed
-  Files stored locally on Laptop SSD, no NAS involved
-  Disconnected from the home network
-  Selected Network configurations disabled in device manager (per prior responses)
Results: Out of 10 tracks (all the same song) it never failed.  So this song which fails consistently on the NUC passes consistently on my Laptop.

Well that’s interesting, NUC and Laptop demonstrate different passing and failing behavior on the same song.
Given this result I decided to try another song/album looking for a passing song on the NUC.  So I created yet another special “album using yet another single track from a completely different album.
-  Test hardware NUC & Primare
-  Created new modified test album (7_Test Album)
    *  Single track (track 1) off 10,000 Maniacs album (Few & Far Between) repeated 10 times (7_Test Album)
    *  Same song used 10 times with different track number and file name assigned.
    * Metadata removed
-  Files stored locally on NUC SSD, no NAS involved
-  Disconnected from the home network
-  Selected Network configurations disabled in device manager
Results:  Looped thru three times (30 songs played) and no failures

Next I tried testing using Wer’s recommended test structure.  I inserted a suspected failing track into the prior passing test configuration.
-  Test hardware NUC & Primare
-  Created yet another modified test album (7_Test Album_Test 2)
    *  For the suspected failing track I used 7-Walker, track 12 as it appears to fail every time (at least using the NUC) when part of sequential songs on a test album. 
    *  I inserted it as track 4 in this test album (7_Test Album_Test 2)
    *  Metadata removed
-  Files stored locally on NUC SSD, no NAS involved
-  Disconnected from the home network
-  Selected Network configurations disabled in device manager
Result:  Hung/stopped on 4th song which was the suspect track.  Tested 10 times, failed every time.  (see link to log below)
(I also tried selecting a 3 song grouping with track 4 being the second song and again hung on the same suspect track as before)
Log 5:  https://drive.google.com/file/d/17wK1xZLNy9XDSFYMe99Q-HwbOQqgD2A6/view?usp=sharing

Next I reran the same test file just used with the suspect file inserted at track 4, but using Laptop in place of the NUC
-  Test hardware Laptop & Primare
-  Test Album:  (7_Test Album_Test 2)
    *  Same test album as I used in the last test with the NUC where track four is the suspect song
    *  Metadata removed
-  In this test run (to expedite test cycles thru-put) I selected to play only three tracks 3,4 and 5.
-  Files stored locally on Lap Top SSD, no NAS involved
-  Disconnected from the home network
-  Selected Network configurations disabled in device manager
Result:  Passed every time (unlike the NUC which failed every time), and I tried 10 passes.  Consistent result from earlier testing, the suspect song (track 12 of 7 walkers) does not exhibit the failure mode when using my Laptop.

So based on this (limited) data sample it appears failures using the NUC follow a suspect song and they are not just random failures of any song. 
However, I was surprised that the Laptop failure are not consistent with those see using the NUC. So I decided to start doing more testing using my laptop running MC as the server in place of the NUC.
-  I moved my Laptop back to my office
-  Backed out NIC configuration changes done in device manager
-  Connected both Laptop and Primare to home network
-  Rebooted laptop
-  Reconnected all LAN on all entertainment devices back to Network switch in entertainment cabinet
-  Selected playlist on shuffle play as well as tried playing entire original album (7 walkers) with no modification to files
Results: No failures observed.  I’ll continue more testing, but I’ll be darned if I know what could have triggered this behavior change such that the Laptop has not hung on any song yet tried in later test configurations.

[wer]

First Ralph let me say you're to be commended for your diligence in sticking with the testing.  This kind of work can be a drag, but you've acquitted yourself well.

One thing I hope is true, that you did not explicitly mention: that you took every effort to ensure your DLNA configuration on the Laptop and the NUC were identical. If not, the test was invalid. But assuming you did, let's continue:

Unfortunately, I suspect the worst case has been realized.  A couple of preliminary conclusions can be reached from what you've provided.

1. There is definitely a data-based problem. There is something about certain files that is causing failures. It might not necessarily be bad or corrupted data, and could be software that is malfunctioning given certain edge-case but valid data; but regardless - it is data driven.  I would defer to Andrew or others in describing the exact nature of the offending data, if it can be determined.

2. There is probably a coordinating software problem, either at the MC or driver level, which is triggered by the data, and which explains why the manifestation is different between the NUC and the laptop. If this is so, it's why I refer to a worst case: this may be difficult to fully identify and avoid, short of overkill-type steps, like normalizing all the media files (e.g. convert to tagless PCM) as Andrew mentioned.

Beyond this I wouldn't want to speculate, although I'm hopeful that Andrew will see something that's clear to him when he looks at the snoop. But I'm beginning to suspect that might only reveal the malfunction but not the cause.

It also makes it difficult to foist the blame off on the Primare when it evidently behaves gracefully in combination with the laptop.

An effort should be made to identify any software or configuration differences between the NUC and the laptop. Drivers will be different obviously, but MC can be identical.  If Ralph is desperate enough to spend a little money, it is possible to achieve a great standardization between the NUC and the Laptop: get a USB Ethernet adapter, and test both the Laptop and NUC through it. This way they will be using identical network drivers, and that difference will be eliminated. All the other differences between the machines (if the MC config is identical) should be irrelevant.

I generally don't like telling someone to spend money just to test, but if the NUC problems disappear with a different network adapter & driver (which I would not estimate to be high likelihood) at least we know where the (partial) problem is. So perhaps $15-$20 is not too much to pay for that knowledge. Ralph would have to decide.

[zybex]

My reason for asking is that with some file formats, with some tagging utilities, the idv3 block is right at the end of the file. And I have seen some renderers that try to “play” the tag, and get sick. Particularly if the tag contains one or more, large, album art icons.

That's what I meant when I asked to remove metadata/art


I analyzed a couple of logs and have some findings.

I see on the FLAC streams that they just have some basic tags, but also have a 128KB block of padding (zeroes) at the top. This is probably where the clipart was, and when you remove it it just gets zeroed-out instead of having to rewrite the entire file. If you re-add the image, it gets written to that space. It makes sense and should not be related to your problem - The FLAC structure is correct, I checked.

The tests with the laptop are not comparable because it's sending MP3@128Kbps instead of FLAC. Looks like you have some transcoding option enabled in MC, the MP3 stream has a comment "Converting with JRiver". These files are smaller than the FLACs (in bytes), and that's perhaps why you see less issues with them. Though looking at the log, I still see many of the same TCP transport issues that are visible on the NUC. The MP3 streams also have a small ID3 tag at the top, and I can see that perhaps the Player doesn't like that (more on that below)

Almost all file transfers (or maybe ALL, I didn't check) from the server to the Player are problematic, and consist of multiple retries. Each transfer is aborted by the Player, shortly after start, with RST packets sent to the server. Then another retry occurs. This is similar for "good" files and for "bad" files that stop playback. The number of retries is not always the same, but eventually the file does get transferred (but not complete - read below).

The difference between the download attempts is the start Offset position. This is a typical sequence:

HEAD /Music/F590356.flac   => server replies with Content-Length=22996677 (filesize)
GET /Music/F590356.flac, RANGE=0-22996676  => RST after 1080KB
GET /Music/F590356.flac, RANGE=0-22996676  => RST after 885KB
HEAD /Music/F590356.flac   => server replies with Content-Length=22996677 (filesize)
GET /Music/F590356.flac, RANGE=0-22996676  => RST after 885KB
GET /Music/F590356.flac, RANGE=0-22996676  => RST after 1245KB
HEAD /Music/F590356.flac   => server replies with Content-Length=22996677 (filesize)
GET /Music/F590356.flac, RANGE=131072-22996676  => file transfer completes and playback starts

Now, because the player skips the first 128KB, it won't get the FLAC header which contains things like duration, sampling rate, channels, etc. The Player can guess these things from the stream (so it still plays), but perhaps it doesn't calculate the same exact playback length as expected by MC. It may round up/down, which on some songs may cause the mismatch of 1 second, leading to the playback stop.

For the MP3 files something similar occurs, but the Player now tries to skip less data - perhaps because it knows an MP3 is more "dense"? Also, the last successful download doesn't skip any data (even in the case of the song on which it stopped playback):

HEAD /Music/F421123.mp3    => server replies with Content-Length: 4709803 (filesize)
GET /Music/F421123.mp3, RANGE=0-4709802  => RST after 66KB
HEAD /Music/F421123.mp3    => server replies with Content-Length: 4709803 (filesize)
GET /Music/F421123.mp3, RANGE=0-4709802  => RST after 131KB
GET /Music/F421123.mp3, RANGE=0-4709802  => RST after 197KB
GET /Music/F421123.mp3, RANGE=10-4709802  => RST after 262KB
GET /Music/F421123.mp3, RANGE=0-4709802  => RST after 328KB
GET /Music/F421123.mp3, RANGE=4096-4709802  => RST after 360KB
GET /Music/F421123.mp3, RANGE=0-4709802  => RST after 721KB
HEAD /Music/F421123.mp3    => server replies with Content-Length: 4709803 (filesize)
GET /Music/F421123.mp3, RANGE=0-4709802  => file transfer completes and playback starts

All this takes 1 or 2 seconds max.

The pattern is always similar:
- multiple GET attempts, sometimes with a different start point
- For all Flacs it eventually skips the first 128KB
- For MP3, it stops much earlier (perhaps because it's decompressing as data arrives and the buffers fill faster).
- last attempt is always much larger, so it feels like a fallback mechanism, ie, download and ignore all errors

Conclusion... the player doesn't like something, that's for sure. Looks like it's network related, but I'm starting to think that it may have some internal hardware problem like corrupt RAM, causing random issues and data corruption. Do you hear any clicks/pops on the output audio? I extracted the FLAC streams and played them with MPC-HC, and there's a very audible click at the start on the files missing the 128KB. When I add back those 128 KB (by merging with one of the incomplete streams), it plays perfectly. Nice album, BTW

One other thing you can try is to reduce LAN speed to 100Mbps instead of gigabit. You can also try a direct cross-over cable connection to bypass any switch.

From MC side, I think it should change the polling algorithm and do GetTransportInfo interleaved with GetPositionInfo to detect STOPPED condition when the timestamp is frozen near the end. This would allow it to proceed to next song in this scenario (but I'm not sure if it would misbehave in case of the user pressing the STOP button manually)