When is the OGG/Vorbis seek WARNING relevant?

Hi, I’m trying to understand when warnings like the one below are relevant:

[Aug 29 20:25:47] WARNING[12705][C-0000000b]: format_ogg_vorbis.c:384 ogg_vorbis_seek: Seeking is not supported on OGG/Vorbis streams in writing mode!

That happen when using MixMonitor, as:
same => n,MixMonitor(${UNIQUEID}.ogg,ab)

If I understood it correctly, Asterisk won’t be able to seek content of the recorded file while it’s being written. Is this correct?

If this is the case, on what scenarios would Asterisk try to seek the MixMonitor file while it’s being written? Would it do with normal Dialplan applications, as Transfer? Or this is relevant only when using an AGI that would read the file as it’s being written? I haven’t found a situation where the warning is relevant so far, but I may have just not faced a problematic scenario yet.

Because of this, I’m unsure if I can ignore the warning or not. I tried searching about this warning and haven’t found anything about its impact. I’m sorry if this is answered somewhere else.

The error message probably goes away if you remove the ‘a’ option from MixMonitor(), or if you change to another file format such as WAV instead of OGG.

Looking through the code, it appears that the WARNING you see probably means that your OGG file is being overwritten instead of appended to. In more detail… take a look at mixmonitor_save_prep() function of the apps/app_mixmonitor.c file to see where the ast_writefile() function of main/file.c file is called to find where the abstract seek is called:

/* If truncated, we'll be at the beginning; if not truncated, then append */
f->seek(fs, 0, SEEK_END);

…but you may note nothing is done with the return value of seek() function. Each format ostensibly implements this function, and most flesh it out to actually work, so they return something positive; but, several of the formats return -1 due to various reasons.

You might find the issue if you are issuing multiple starts and stops of the monitoring. The ‘a’ option is basically being ignored, so you’ll keep overwriting the same file name. The workarounds could be to change file formats eg. WAV now then transcode to OGG later, or change file names to a more unique name eg. ${UNIQUEID}-${EPOCH}-${RAND()}.

Thank you for this answer, it was very helpful. I’ve tested a few things: issuing multiple MixMonitor with the same filename without stopping seem to not cause problems, while stopping and starting again will result in a recording with only the recording from after the last MixMonitor.

Removing the a option does not make the WARNING disappear. I tried using:

same => n,ExecIf($["${MIXMONITOR_FILENAME}" = ""]?MixMonitor(${UNIQUEID}.ogg,b))

To not run the MixMonitor multiple times, I think this should at least reduce the amount of WARNINGs being outputted.

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.