-
-
Notifications
You must be signed in to change notification settings - Fork 206
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
fix for elusive crashing issue #773
Conversation
can't believe i didn't notice it before
trying to not change anything extra
I believe the idea was to make sure all of the audio samples got put on to the output_queue before the termination was sent. There are 100s (thousands?) of instances running and I would think this would be much more prominent if it were an issue. What is pointing you in your examples to this? Have you tried building a debug version and getting the stack trace? |
yeah this didnt solve it cause it still crashed with
|
I'm pretty certain it has something to do with the fact that I'm using networked storage mounted as a local folder, which, whenever there is some latency with the connection, it basically locks up the entire computer waiting for it to respond, and so the buffer fills up, way more than it's supposed to, and once it starts responding again it tries to process too much at one time and crashes, it's driving me crazy and I'm too dumb to figure this out but I'm going to keep trying regardless... |
Is your 'catpureDir' on the networked storage? Can you let trunk-recorder create the files locally and then have the uploadScript or a separate process move them to networked storage? You probably wouldn't need much local storage. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this was stupid and didn't actually work
that's a good idea, but I actually think I finally tracked it down and figured it out, I'm just trying to decide if it's actually fixed before opening a third pull request for no reason lol |
I kinda jumped the gun and posted a pull request the other day without testing it, but I've been running with this change all day and like 50,000 calls, everything appears to be functioning perfectly fine... I think it does seem to be ending calls sooner, but not like any earlier than they should be, just tends to seem like less of a silence gap between calls within a single recording.
Does anyone know why it would continue processing call audio if terminate_call is true? This seems to have solved the crashing issue I was having, and looking back at a previous issue that I thought was solved, I noticed in the debug info I posted back then, it was crashing while terminate_call was true, so it appears this could have been the actual issue at hand and I didn't notice because for whatever reason this crash happens randomly a bunch of times in a row and then goes away completely, but this time I actually had a chance to track it down and figure it out while it was happening, compile a bunch of versions with extra debug info, and narrow it down to pretty much this exact spot where it was having issues.