View Categories

Multicast Overlap/Stream Manager Error

Multicast overlap is a condition that can occur when system changes are made in a way that doesn’t allow Navigator and the Route Master blade to keep up with multicast ip address allocations. You end up with a “stream manager error” in Navigator and it will list a number of “exceptions.” These occur when two or more streams end up with the same multicast address and it can cause some strange audio problems.

If you are seeing such an error, you may have some duplicated multicast addresses in your system. If you can remove the network connection to the surface, and you find the headphone audio clears up right away, then that sounds like that’s what’s happening. Reconnect the surface, and make sure that all your Blades and PC Blades are running so you can confirm across your system whether or not the issue is duplicated multicast addresses. Here are the steps to first verify and then fix this issue:

  1. Confirm you do have stream multicast issues by viewing the System View window in Navigator. In the Source Streams tab, you’ll see a list of all active sources in the system. Sort this table by clicking on the Multicast Address field header. Note that the top of the list will have a lot of sources with 0.0.0.0 Multicast Addresses, which indicate they are LIO-only signals, like Spare buttons. Depending on your Navigator version, they may be listed as LIO Only rather than 0.0.0.0.

    The rest of the audio sources will be sorted by their multicast address, which means they should also be sorted by Blade. In other words, each Blade allocates a range of addresses, and so its source streams should all be listed together in a block that is using the color assigned to each Blade (and shown in the System Dock names). Having each Blade use a unique color makes it easy to quickly see whether there are overlapping signals since all the signals from one Blade should be in one “color block” and when the color changes that indicate those signals are from the next Blade and so on. To find overlaps you just scroll through the list and look for identical Multicast Addresses which use different colors. You can confirm the signals are on different Blades by looking at the Location and/or Sig ID fields since the signals on one Blade will also have the same Sig ID starting number, such as 5.0.x.x for example.

    NOTE: Some duplicate addresses are valid! Since each RJ45 jack actually has two signals (left and right), the system considers a stereo signal as one signal thus each stereo signal just has one multicast address. But when a stereo signal is split into two mono signals, which will also have the same multicast address, we have to use an offset to identify the separate “left channel” signal, which has a 0 offset, from the separate “right channel” which has an offset of 1, as is shown in the Offset column.

    If you don’t have see any conflicts in the Multicast Address column, then your issues are not due to duplicated multicast addresses and thus there must be some other issue such as multicast flooding that is causing audio distortion.

    If you do find duplicated multicast addresses, used Navigator to verify that every Blade has a unique Device ID assigned since Blades with a duplicate ID number would certainly cause this issue. To change a duplicate ID number requires the Blade to be factory reset and then reinitialized which deletes all current configuration settings from that Blade.

    If every Blade has a unique ID, but you still see a number of multicast address being assigned to sources on different Blade, then count the number of duplicated multicast addresses and note that number since you’ll need to use it in step 3.

  2. In the System View window scroll the list to the bottom and note the highest multicast address currently in use. Write this address down. For example in my test system, my highest address is 239.192.192.151. You can then close the System View window.
  3. View the System > Info Tab and look at the Multicast Addresses section. Note the number of “Addresses currently in use.” In my case, it is 176. To reallocate addresses take the number of duplicated addresses you found and add it to the addresses in use number to come up with the number you will need to use to reallocate addresses.

    In the Start Address field enter the Multicast address that you noted earlier, as your highest “in use address” and add +1 to the last octet. Thus, my system is 239.192.192.151, so I enter 239.192.192.152 into the Start Address field.

    In the Number of Addresses field, add the number of Addresses currently in use and the number of multicast duplicates that you counted and enter that number into that field. In my case, I have 176 addresses and no duplicates so I entered 180. Entering this number updates the Range numbers. In my case the Range is now: 239.192.192.152 to 239.192.193.75, or 180 addresses. Note your calculated Range start and end addresses.
  4. This step will cause signal reallocation to occur. All active audio streams will be momentarily interrupted during this process, so if the system is on-air expect audio delivery to be disrupted. Click the Apply button. You’ll get a pop-up from the Route Master Blade confirming the allocation change request. Click Yes will force the system to use this new Range of multicast addresses.

    Note: This is a temporary move. We want to move everything back to the original starting address, with a full open range, so you’ll need to reallocate once more to do that.

    View the Log tab to see all of the messages from the Blades as they reallocate their source addresses. Once this is completed, your audio will return, and you should find the log messages basically stop. View the System View window to confirm that the Blades moved to new addresses, and that there are no longer duplicate multicast addresses: each Blade’s addresses are shown in a block of a single color.
  5. As stated above, we need to move back to the default starting address and range, so in the Multicast Addresses section click the Reset button. This will change the Start Address back to our default setting, restore the default number of address, and update the Range addresses accordingly. Click the Apply button to force a second reallocation, this time back to the default range. You’ll get another popup from the Route Master Blade about doing this. Click Yes and the Blades will readdress their signals again, moving them back to their original address ranges. Again, watch the log to see this action occur.
  6. Once the signals are reallocated, open the System View and verify that all duplicate multicast addresses have been eliminated.