| Summary: | ASTERISK-20168: audiohook.c: Flushing audiohook | ||
| Reporter: | Aleksandr Gordeev (axonaro) | Labels: | |
| Date Opened: | 2012-07-25 02:12:06 | Date Closed: | 2012-07-26 16:09:52 |
| Priority: | Major | Regression? | |
| Status: | Closed/Complete | Components: | |
| Versions: | 10.6.0 | Frequency of Occurrence | |
| Related Issues: | |||
| Environment: | Attachments: | ||
| Description: | In logs : [2012-07-25 11:01:42] DEBUG[28715] audiohook.c: Flushing audiohook 0xb56c893c so it remains in sync [2012-07-25 11:01:42] DEBUG[28715] audiohook.c: Audiohook 0xb56c893c has stale audio in its factories. Flushing them both [2012-07-25 11:01:43] DEBUG[28764] audiohook.c: Audiohook 0xb54f493c has stale audio in its factories. Flushing them both It is normal ? | ||
| Comments: | By: Matt Jordan (mjordan) 2012-07-26 16:09:42.839-0500 Yes. Probably. This will get logged when an audio frame is written to an audiohook and the audiohook still has data available on it within some period of tolerance (100 ms). In your particular case, both the read/write factories still had audio on it that nobody had bothered to retrieve when this frame was written to it. Without other context its impossible to say for certain that you aren't going to experience something that you might not consider to be nominal behavior, but there's a reason why this is a DEBUG message and not a VERBOSE or higher message: its for debugging. It isn't an error, or a warning. If you aren't experiencing off nominal behavior, then you can disregard it. | ||