Bug #10262
openKenwood TS-2000 problems deleting memories
0%
Description
As a test to look for bugs I tried to delete 33 memories and some of them did not delete and the numbering in the left column got messed up. After closing Chirp and doing another download from the radio the numbers in the left column are sorted but some memories I tried to delete are still there. After trying to delete the remaining memories they do not delete and it says "Refreshed memory 112" at the bottom. Only option now is to clear radio memory and recover from CSV file.
Files
| Capture.JPG (74.8 KB) Capture.JPG | |||
| debug.log (1.03 MB) debug.log | |||
| debug.log (299 KB) debug.log | |||
| debug.log (271 KB) debug.log | |||
| Capture.JPG (71.6 KB) Capture.JPG |
Updated by Chris Williamson almost 2 years ago
Not sure if I attached the latest log so here it is
Updated by Dan Smith almost 2 years ago
- Assignee set to Dan Smith
- Target version set to chirp-py3
Thanks for the debug log(s). They show me that you're doing more than just small edits, which helped lead in the right direction. The delete-and-shift and insert-row operations are very laborious for live radios like the TS-2000, as they generate a ton of traffic back and forth from the radio. Not saying you shouldn't use them, just saying they're like worst case scenario ;)
I found a pile of issues, most of which are specific to live radios like this, so those will be queued up for tomorrow's build. I tested using a Kenwood VHF live radio (a TM-281) and was able to replicate a lot of what I see in your log. It's still quite possible there are other issues specific to the TS-2000, which will be harder for me to squash, but I think the stuff I have for tomorrow should help a lot.
The issue with deleting a chunk of memories where the shift-up is used was actually broken for everyone, and I've got that fixed for tomorrow as well.
Out of curiosity, have you used the legacy build of chirp with this radio before with success? The driver has basically not changed between the two, so anything specific to your radio that didn't work well in the legacy build will still be a problem in chirp-next, and knowing the difference will help to narrow down the proper fix.
Thanks a lot for your patience and help - a bunch of the issues fixed as a result of chasing this down apply to all chirp users, so tomorrow will be better than today for everyone :)
Updated by Chris Williamson almost 2 years ago
Hi
Thanks for incorporating the TS2000 module, that works
Tried deleting the 33 entries and only a few deleted but this time the memory numbers in the left column did not get messed up
Updated by Dan Smith almost 2 years ago
Okay, could you try to capture a small clean debug log? So,
- Start chirp, download from the radio, wait until it is finished filling
- Try to delete whatever memories, wait until all the activity stops
- Help->Open Debug Log
- Attach that
Also, can you answer my earlier question: did you ever try the old legacy chirp and did that work better or has it always been flaky with the ts-2000?
Updated by Chris Williamson almost 2 years ago
- File debug.log debug.log added
- File Capture.JPG Capture.JPG added
Hi
Even the old Chirp had bugs with Kenwood TS-2000
So this time I just deleted a few entries and that worked but when I started deleting and moving blocks up I ran into problems - Look at the screen shot the numbers for the rows mixed up
Updated by Dan Smith almost 2 years ago
Okay, yeah, I still see many errors there where the radio refuses our commands, mostly to delete things, and then stops talking to us for a while, which causes things to get out of sync. Dang, that's a bummer, but it sounds like deeper analysis by someone with access to a radio will be required in order to progress from here.
Updated by Chris Williamson almost 2 years ago
Thanks Dan
Not a problem - I am happy updating offline then resetting my radio and restoring.