LoTW import fails with 60M band

[OH1KH]

LoTW import drops all 60M imports to error file.
The reason is fImportProgress line 849:

band := dmUtils.GetBandFromFreq(dmUtils.FreqFromBand(band,'CW'));

dmUtils.FreqFromBand is horrible hard coded list of frequencies versus modes. And there is a typing error with 60M band's
frequency that leads all LoTW imported qsos to be "not found in log" as the "band" above gets empty result.

There is already database table cqrlog_common.bands that holds user editable band start/end/cw/rtty/ssb frequencies.
So why not use that instead of hard coding?
In that table the column "cw" is just pointing at the end frequency of cw slice, but that does not matter. It gives good enough response, I think.

I have done fix that uses database instead of hard coding and in first test all qsos, including 60M, were imported ok from LoTW.
It still needs more testing as dmUtils.FreqFromBand is used from few other places.

While doing tests this issue is open. Test branch is https://github.com/OH1KH/cqrlog/tree/lotw_60m_rcvd_err

[OH1KH]

Found dmUtils.FreqFromBand used in three places:

1. LoTW import.(fImportProgress) I can not understand the meaning there. LoTW is returning BAND in qso record. How ever after debug printing qso record (where band is ok) the band is recreated with
   band := dmUtils.GetBandFromFreq(dmUtils.FreqFromBand(band,'CW'));
   Meaning ?

2. Adif import. I f there is no freq from adif, or its value is 0 freq is created from dmUtils.FreqFromBand. It is needed later in dmUtils.IsAdifOK. Reasonable.
   But after that the BAND is recreated from frequency with dmUtils.GetBandFromFreq before new entry is saved.
   Why??

3. Wsjtx monitor. Freq is created from current band and mode and used in dmDXCC.DXCCInfo to see callsign worked status. OK, freq is needed there once and not used for recreating back the band.

So it seems that replacing hard coded version with band table lookup does not break anything.

While checking this I looked also to default frequencies. They are set with prefrences/TRXcontrol/Change default frequencies button.
Unfortunately they do not cover all bands and can so not be used for this purpose. In addition they are even stored in config file items.
This is a good place to refer again to issue #397.
Perhaps also those default frequencies should be moved from config file to cqrlog_common.bands table ?
And perhaps new, more user friendly layout of that table would be:
band
band_start
band_end
cw_start
cw_default
cw_end (former cw)
data_start (former rtty, to cover all digital modes)
data_default
data_end
ssb_start (former ssb, to cover all phone modes)
ssb_default
am_default
fm_default
ssb_end

That would not be very big change after all and would make the preferences/bands/frequencies editing more user friendly.
If I remember right the mode slices definition is used only in DXCluster spot double click.
The band start and end are used also elsewhere. And now also dmUtils.FreqFromBand uses this table.

[OH1KH]

Error is now fixed by commit, but I still leave this open to remind the suggestion of new bands table format.

Using begin and end of modes could allow mode slices appear in different order in band than current and only CW->RTTY(data)->SSB order.