This very well may be intentional, and I've patched it on my end, but want to toss this out there before I consider a pull request in case this is entirely intentional.
If a startup DMR talk group is set for YSF2DMR, a * disconnect takes it back to TG 9 (local by convention) instead of the startup talk group.
Part of me agrees with this behavior as a disconnect should be a disconnect, however, considering '9' is still just another talk group outside of convention, the other part of me thinks it should just go back to the programmed startup.
In our case, our default talk groups is 6 digits (based on repeater DMR ID), so the only way to get back to it is through the startup (unless there's another direct entry way I'm not aware of). So for us, it makes sense to default it back there or you won't be able to get it back there again remotely. I get that is not the case for everyone.
My local solution was to just set it back to m_conf.getDMRDstId() on disconnect.
This very well may be intentional, and I've patched it on my end, but want to toss this out there before I consider a pull request in case this is entirely intentional.
If a startup DMR talk group is set for YSF2DMR, a * disconnect takes it back to TG 9 (local by convention) instead of the startup talk group.
Part of me agrees with this behavior as a disconnect should be a disconnect, however, considering '9' is still just another talk group outside of convention, the other part of me thinks it should just go back to the programmed startup.
In our case, our default talk groups is 6 digits (based on repeater DMR ID), so the only way to get back to it is through the startup (unless there's another direct entry way I'm not aware of). So for us, it makes sense to default it back there or you won't be able to get it back there again remotely. I get that is not the case for everyone.
My local solution was to just set it back to m_conf.getDMRDstId() on disconnect.
Thoughts as to if this is a bug or not?