Attached is a document on the very first steps one should always do when analyzing Wireshark captures from CobraNet network audio systems.  The overall health of the network can often be determined by how well the network propagates the CobraNet Conductor Beat packets.  Devices that chime in to try to be conductor from the far reaches of the network are signs of how well these Beat packets are being propagated everywhere.  They are like canaries in the mine, when they "cheep", something is not well with their neck of the woods on the network.  

For example, in a past analysis it was possible to determine that the downlinks from the core switch to the next layer of switches in went down, but not the uplinks from them.  This was evident because the CobraNet devices all tried to become conductor, which settled out so there were five "local" conductors (one per remote switch) in addition to the main conductor on the core switch.  

Not covered in the document is Step 2 of an analysis.  If the CobraNet Beat packets look OK as covered in the document, then next one should look at everything BUT CobraNet, which is done with the Wireshark display filter: 

     eth.type != 0x8819. 

Sometimes, it can also help to turn off Remote Desktop or TeamViewer packets, IEDnet and ARP to see what unexpected or funny things there may be, such as with the filter:

     (eth.type != 0x8819) && !(udp.port == 3048) && !arp && !(udp.dstport == 3702) && !(udp.dstport == 514)

 One may want to look at the Statistics -> Capture File Properties after applying this filter to see how many packets/second of other stuff there is in the capture.

Updated Sept 6, 2018 to include Step 4 to check for Beat Packet Delay Variation.