Bug #298
closedOSX_VX5_pythoncrash>dailybuild_20120906
0%
Description
A couple of days ago successfully downloaded entire memory contents on Yaesu VX5. Have been making incremental edits. After one edit, found entire radio memory wiped. Unable to upload and do a full restore. Cloning dialog/progress window would come up momentarily then disappear. Started a fresh file via download and started cutting ad pasting to restore. Thought the original download had become corrupted somehow. Noted that I can not open the base download file past the 50 to 75 range using either of the last two daily builds. Consistently crashes. Apple crash log with chirp debug log appended iincluded in the attachments. Also attached is the original .img file so you might review to see what got chewed or is out of spec? Python crash is reproducable with the .img file. I do see an invalid UTF-8 string error warning in the chirp debug log. If you can give me an idea what to look for, I can fire up one of my text editors and try to query and manually fix -- as a workaround.
BTW, the previous build and this build have been flawless so far with Baofeng UV-5R
Regards
Phil mc
Files
Related issues
Updated by Tom Hayward over 11 years ago
- Status changed from New to In Progress
- Assignee set to Tom Hayward
- Model affected changed from (All models) to vx5
- Platform changed from Windows to All
As far as I can tell, this is not a new bug (you should be able to reproduce it on old daily builds too). It's crashing after failing to read memory 111. It says the tuning step is out of bounds on 111. What does the radio report as the tuning step for memory 111? I'll need to add this value to Chirp. Apparently you're the first person to use it.
Updated by Phil McNamara over 11 years ago
Hi Tom,
Interesting.
Well, unfortunately somewhere in the crash sequence of events, all the original channels on the radio were wiped. All I have now for baseline data is what is in the original .img (may be chewed) file sent with the bug report. I did a factory reset, and have been trying to restore the VX5 since. Have managed to cut and paste from the original file up through channel 90. I kinda figured something was out-of-spec somewhere after channel 90 in the base .img file. So you have a tool that can view/parse the .img without crashing?
phil
Updated by Tom Hayward over 11 years ago
- Platform changed from All to MacOS
I've looked into it more and a tuning step of 0xf in the VX-5 is indeed invalid, and Chirp is catching the error properly. The data from your VX-5 must have been corrupted.
Testing on Linux, Chirp reports the error fine. I think this is a bug in pygtk for Mac OS X.
Updated by Phil McNamara over 11 years ago
Hi Tom,
I could believe that Python is less than perfect on OSX :) OK, If I am reading between the lines correctly, you were able to open and view the .img in a linux environment. Could I then open the original file in a daily build on linux or windows, clear memory record 111, save a copy, and then move the copy back onto OSX and hopefully open the file without crashing? Of course, this is presuming that record 111 is the only corruption in the file.
phil mc
Updated by Tom Hayward over 11 years ago
- File VX-5_freqs_fixed.img VX-5_freqs_fixed.img added
Yes, that would work. And to save you the trouble I just did it for you.
Updated by Phil McNamara over 11 years ago
Thanks very much Tom,
I'll give it a shot. Letcha know.
It's sad that Apple lags behind in a lot of areas on open source updates. I am concerned about the latest unpatched java exploits. I am presuming it's because they need to have a good QA review ; )
phil mc
Updated by Phil McNamara over 11 years ago
Trying to open the fixed file with range 91 to 116 crashes again. Guess I will need to open it elsewhere and do a manual cut and paste to recover what I can.
Updated by Tom Hayward over 11 years ago
- File VX-5_freqs_fixed2.img VX-5_freqs_fixed2.img added
Ah, there's more than one issue here. I only fixed the tuning step corruption, but memory 96 had some corruption in the Name. Now the error message makes sense! Here's another fixed file. I'll try to see if there's a good way to avoid the crash on OS X now that I see the corrupted name.
Updated by Phil McNamara over 11 years ago
Thanks Tom, That was a huge help - above and beyond!
OK, I can see the range up to 220. Huge improvement. I saw the message that one channel was NG and it opened as empty.
I haven't been able to see the whole dataset since the first download. I am suspecting it came from the radio that way.
Many thanks. I'll work on the full restore to the VX-5 shortly.
phil mc
Updated by Phil McNamara over 11 years ago
- File error_after_paste.tiff error_after_paste.tiff added
Hi Tom,
OK, the raw file (fix2) as fixed by you wouldn't upload - saw just a quick flash on the upload progress bar window. I cut and pasted the missing channels into the new file I have been rebuilding. Got the attached incompatible frequency dialog box on a large number of channels. See attached. The new built file uploaded fine. Not sure of why the out of range stuff came up, but essentially restore is complete now.
The original programming of the radio was not done with chirp. Another ham took care of it for me when the radio was new. Possibly there were some options in that software unsupported by chirp. I recall reading something about an extended range/MARS bit that can be set. I believe I had that done since I have been active in MARS for years.
Thanks again.
Phil Mc
Updated by Tom Hayward over 11 years ago
I suspect the failed upload is due to the soft mod. I believe this bit is cleared when the radio is reset, and the radio will only accept images with matching bits.
Updated by Tom Hayward over 11 years ago
- Status changed from In Progress to Closed
As far as I can tell, this issue has been fixed as much as possible. It is an issue with corrupt data in the VX5, and bad name data from VX5 is now filtered before display.