CHIRP

Cannot reproduce. Given steps worked fine.

Thanks for trying to reproduce. A bit odd that you're not seeing this problem but not unexpected. Getting field problems reproduced by developers is one of the most challenging aspects of testing. And the one that chases QA people away.

So what about the error in the log? Am I really stuck having to fix this myself?

I should add that you do not have the same memory contents in your D72 as what I have. Looking at the log something about the memory contents made it break.

Doing 1
Doing 2
PC->RADIO: ME 800
D7->PC: ME 800,0145050000,ÿ,0,0,0,0,0,0,08,08,000,0,00600000,0,0000000000,0,.
-- Exception: --
Traceback (most recent call last):
File "chirpui\editorset.pyo", line 316, in do_export
File "chirpui\editorset.pyo", line 214, in do_import_locked
File "chirpui\importdialog.pyo", line 610, in __init_
File "chirpui\importdialog.pyo", line 525, in populate_list
File "chirp\kenwood_live.pyo", line 174, in get_memory
File "chirp\kenwood_live.pyo", line 902, in _parse_mem_spec

ValueError: invalid literal for int() with base 16: '\xff'¶

Traceback (most recent call last):
File "chirpui\mainapp.pyo", line 1244, in mh
File "chirpui\mainapp.pyo", line 1036, in do_export
File "chirpui\editorset.pyo", line 321, in do_export
File "chirpui\common.pyo", line 249, in show_error
TypeError: parent should be a GtkWindow or None
Closing 0
RadioThread exiting

Yeah, it's definitely something in your radio. What is stored in channel #800? The radio is clearly returning a non-printable (not even ASCII) character instead of one of the fields. I can definitely throw something in to avoid that from crashing the export, but AFAIK, this isn't supposed to be possible. I guess we should at least handle this somehow more gracefully...

If you could look at what is in #800 and see if it looks problematic that would be help.

Thanks, I was just going to request your mcp file. Let me experiment with this.

Thanks Tom. Removing item 800 using MCP-4 allowed the export to complete. This was not a relevant channel so it was no problem to delete it. Perhaps when you or others have time you could determine why entry 800 caused this problem and if that would be recoverable in a different way than just hanging. Luckily the log had great information!

Thanks Tom, will retest soon.

Tom, I'm using version daily-20130107 and it's not working at all it seems. I attempt to read from the radio and nothing seems to happen. The GUI remains empty. When I attempt to load again it says the port is in use so it appears there is still a thread running that has the port open. I used 'live' mode.

I waited a minute or two which I think should be sufficient to load all 1000 memories. I don't think it's really reading anything.

Clone mode reads all memories just fine, including the corrupted entry that caused this bug to be logged in the first place.

If it's reading something, it will say so in the debug log.

There have been a number of D72 changes lately (like addition of the clone mode driver), so it would simplify things greatly if you tested this issue with the version released immediately after I submitted this fix: http://trac.chirp.danplanet.com/chirp_daily/daily-20130104. All I did was fix the error reporting, so you would see an error message instead of a hang. Without a debug log I can't determine what problem you're seeing now, but I suspect it's different than the issue you originally reported.

I added the clone mode driver because I know you prefer it over the live mode driver. If you're going to use the clone mode driver, please be very observant because I think there are some bugs. Open issues for these bugs if you find them.

OK, I went back to the indicated build. Generally developers insist on always using the latest build so that's what I did.

Data was read fine from the radio. Item 800 was listed as 'error' even though most fields should have been readable. MCP-4A happily reads and writes this memory item so I'm curious what's so special about it. Line 800 was not exported.