dsmurfin / sacnkit Goto Github PK

At present per-slot priority message sent once per second, and a single messages whenever taking over control.

To be compliant with the whitepaper and draft E1.31-1 we should:

• Send 3 per-slot packets at full rate before transmitting at the supressed rate
• Send 3 per-slot packets at full rate whenever priority changes before transmitting at the supressed rate

Hi All 👋
Nice to meet you ;)

I have a project using sACNKit and found edge case in which the socket termination message is always sent instead of message for universe.

In my case the problem occurs when doing such operations:

1. Start sACNSource and add a single universe to it
2. Call removeUniverse with the number of above universe
3. Add again the same universe again

As far as I figured out the removeUniverse registers socket in the socketsShouldTerminate dictionary, which later is never cleaned out. In effect the sendDataMessages method instead of picking up the right message, always sends the socketTerminationMessages. This happens in this line:

let messages = socketsShouldTerminate[interface] != nil ? socketTerminationMessages : universeMessages

The intuition says me that probably we should clean the socketsShouldTerminate dictionary at some point, but I'm not that familiar with the whole code to be able to quickly find proper place.

If you could take a look I would be more than grateful 🙇 . Or you can leave me a hint where it should be cleaned and I will prepare a PR with the changes. Just let me know what suits you better ;)

If sACNSource interfaces are updated between initialization and start, the source will bind to nil interfaces as well as any additional interfaces assigned.

ETCLabs/sACN@e563f0a

It may be desirable to ignore certain CIDs, for example, to ignore data from the same application that might be received over the wire

sACNMerger.swift

updatePAPForSource and updateLevelsForSource return if source data has less than 512 slots (DMX.addressCount).

To fix, compare count against newPrioritiesCount, or newLevelsCount respectively.

This is intended to support primary/backup scenarios

Some Components have been seen with invalid UTF-8/ASCII names, for example:

54657374657200722076312e312e377200e709510238aa6235481428ac9ccc6f9e561056c54327f80a004a44f9b7358818e11c7e1838646ab74976e535ed0000

We should either attempt to continue by resolving an invalid name to a generic source name invalid, or try and extract something from the data provided.

The properties of sACNMergerConfig are not marked as public and therefore this struct cannot be used.