Hacky patch for avoiding a crash on Unix receivers #145
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
I have tested this and used the logging I added to ensure that this patch is affecting things, and it avoids crashes without corrupting the audio stream. |
octylFractal
force-pushed
the
bugfix/abort-crash-hacky-patch
branch
from
e2ddd12 to
411f2ed
Compare
|
Receiver still crashes |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This is my uninformed attempt at fixing #117. Essentially, since the error only occurs if we have 0 channels, and that doesn't make sense anyways, simply discarding the troublesome data is better than crashing.
I think there is something wrong with how the data is being sent from windows, or the way that the network code is written, but I don't have a ton of experience with Windows development.