Call recording stopped working

Hi,

We have just upgraded from FPBX v11 to v12 via the freepbx upgrade module
we are running Centos 5 64-bit and asterisk 11.16.0, FPBX framework 12.0.37, FPBX core 12.0.22

Extensions have call recording set to on for all calls. So that calls in and out of the extension are recorded. This has worked for many years and the recordings are in the usual location /var/spool/asterisk/monitor/{year}/{month}/{day}

All of a sudden, outbound call recordings have stopped working. This was not immediately after the upgrade, as I have a couple of recordings showing since then, however something seems to have broken it when doing configuration in the admin

In the CLI I can see lines such as: ast_writefile: No such format ''
and /var/spool/asterisk/monitor/2015/02/14/out-123-299-20150214-175649-1423936609.12.

The directory exists and ownership is asterisk.asterisk
call recording format is set to gsm in the advanced settings, Ive also tried wav
nothing seems to work!

-- Goto (sub-record-check,out,1)
-- Executing [[email protected]:1] NoOp("SIP/299-00000000", "Outbound Recording Check from 299 to 123") in new stack
-- Executing [[email protected]:2] Set("SIP/299-00000000", "RECMODE=yes") in new stack
-- Executing [[email protected]:3] ExecIf("SIP/299-00000000", "0?Goto(routewins)") in new stack
-- Executing [[email protected]:4] ExecIf("SIP/299-00000000", "0?Goto(routewins)") in new stack
-- Executing [[email protected]:5] Gosub("SIP/299-00000000", "recordcheck,1(yes,out,123)") in new stack
-- Executing [[email protected]:1] NoOp("SIP/299-00000000", "Starting recording check against yes") in new stack
-- Executing [[email protected]:2] Goto("SIP/299-00000000", "yes") in new stack
-- Goto (sub-record-check,recordcheck,9)
-- Executing [[email protected]:9] ExecIf("SIP/299-00000000", "0?Return()") in new stack
-- Executing [[email protected]:10] Set("SIP/299-00000000", "__REC_POLICY_MODE=YES") in new stack
-- Executing [[email protected]:11] Goto("SIP/299-00000000", "startrec") in new stack
-- Goto (sub-record-check,recordcheck,16)
-- Executing [[email protected]:16] NoOp("SIP/299-00000000", "Starting recording: out, 123") in new stack
-- Executing [[email protected]:17] Set("SIP/299-00000000", "AUDIOHOOK_INHERIT(MixMonitor)=yes") in new stack
-- Executing [[email protected]:18] Set("SIP/299-00000000", "__CALLFILENAME=out-123-299-20150214-175649-1423936609.12") in new stack
-- Executing [[email protected]:19] MixMonitor("SIP/299-00000000", "2015/02/14/out-123-299-20150214-175649-1423936609.12.,ai(LOCAL_MIXMON_ID),") in new stack
-- Executing [[email protected]:20] Set("SIP/299-00000000", "__MIXMON_ID=0x7fc9d8001ae0") in new stack

== Begin MixMonitor Recording SIP/299-00000000
[2015-02-14 17:56:49] WARNING[31202][C-00000006]: file.c:1242 ast_writefile: No such format ‘’
– Executing [[email protected]:21] Set(“SIP/299-00000000”, “__RECORD_ID=SIP/299-00000000”) in new stack
[2015-02-14 17:56:49] ERROR[31202][C-00000006]: app_mixmonitor.c:583 mixmonitor_save_prep: Cannot open /var/spool/asterisk/monitor/2015/02/14/out-123-299-20150214-175649-1423936609.12.
– Executing [[email protected]:22] Set(“SIP/299-00000000”, “__REC_STATUS=RECORDING”) in new stack
– Executing [[email protected]:23] Set(“SIP/299-00000000”, “CDR(recordingfile)=out-123-299-20150214-175649-1423936609.12.”) in new stack
– Executing [[email protected]:24] Return(“SIP/299-00000000”, “”) in new stack
– Executing [[email protected]:6] Return(“SIP/299-00000000”, “”) in new stack

Following on from this

I have found that if I edit extensions_additional.conf and find the line

exten => recordcheck,n,MixMonitor(${MIXMON_DIR}${YEAR}/${MONTH}/${DAY}/${CALLFILENAME}.${MON_FMT},ai(LOCAL_MIXMON_ID),${MIXMON_POST})

if I change ${MON_FMT} to gsm then call recording works again
So for some reason ${MON_FMT} is not getting picked up correctly from the database!

Looks like this line is missing from extensions_additional.conf under sub-record-check

exten => s,n(check),Set(__MON_FMT=${IF($["${MIXMON_FORMAT}"=“wav49”]?WAV:${MIXMON_FORMAT})})

If you edit the extensions_additional.conf it will be overwritten with the next apply changes as in my opinion. So I realy hope this bug is getting repaired as soon as possible.