Conventional recorder info for MQTT and status-server plugins

[taclane]

Conventional recorders are not displayed in plugins such as MQTT or status-server, or in console logs.

This is addressed by giving each type of conventional recorder (P25c, Analog Conventional, DMR) a separate vector that will be represented in such functions as: get_recorders(), print_recorders(), digital_recorder_count(), and analog_recorder_count().

Analog conventional recorders are currently listed in analog_recorders along with trunked recorders. While it seems unlikely that a trunked system would be able to preempt an idle conventional recorder, a separate vector for conventional analog addresses any potential overlap between system types.

To differentiate conventional recorders from their trunked counterparts, make_xxxx_recorder() functions accept a type string instead of relying on a hard-coded value when the recorder instance is created. This way, status plugins will not not only display conventional recorders, but can show "P25" or "P25C".

Conventional recorder types are now visible in the periodic console message, along with the center frequency of each source. This status message has also been indented to match the Currently Active Calls display immediately above it.

(info)   [ Source 0: 455.562500 MHz ] rtl=01,bias=1
(info)   	[ 9 ] P25C	State: idle
(info)   	[ 10 ] P25C	State: idle
(info)   	[ 11 ] AnalogC	State: idle
(info)   [ Source 1: 770.068750 MHz ] rtl=02
(info)   	[ 0 ] P25	State: available
(info)   	[ 1 ] P25	State: available
(info)   	[ 2 ] P25	State: available
(info)   	[ 3 ] P25	State: available
(info)   	[ 4 ] P25	State: available
(info)   	[ 5 ] P25	State: available
(info)   [ Source 2: 771.506250 MHz ] rtl=03
(info)   	[ 6 ] P25	State: available
(info)   	[ 7 ] P25	State: recording
(info)   	[ 8 ] P25	State: available

Any installed MQTT plugins will need to be recompiled after these changes, but no further action is required to display conventional recorders in messages.

[robotastic]

I like this approach - I think this could eventually help with #725 and #726 I might try making an edit so ENUM are used with a function to convert them to a string output. That will help prevent errors around mistyping the string.

[robotastic]

I made a few edits to add in ENUM - lets give this a try

[taclane]

Ah great! Using an ENUM is probably the better way to go, though it seems to be causing problems downstream with the MQTT and status-server plugins.

status-server seems like it just needs in recorder.cc:

boost::property_tree::ptree Recorder::get_stats() {
...
  node.put("type", get_type_string());

But I can't quite put my finger on where the switch from a type string to enum is causing the MQTT plugins to hang on launch.

[robotastic]

Ah - let me go give things a try.... I didn't test as well as I should have

[taclane]

Might have just been an issue rebuilding the MQTT plugins. They seem to be working again after cleaning all the build directories and reinstalling...

The above edit is still needed so that the plugins don't just show an integer in the type field.

(and it looks like it's already in, thanks!)

[robotastic]

Awesome - I just checked and it looks like the MQTT plugins are working for me too. I also just cleaned the up a bit, prob worth getting a new copy.