Testing Notes 3

[andrewfer000]

General Testing Notes to continue on from #6

[markjfine]

Last call for testers / testing input before I start code cleanup and attempt to birth a release. Would like to button this up within the coming week.

[andrewfer000]

You got the All Clear from me to start cleaning the code. I think where the program is now is good for a release.

[markjfine]

Cool. Now I just need to review the procedures for doing a release so I don't screw it up.

[markjfine]

Not so sure sox is really needed. Think I just included it as a holdover from someone's earlier build requirement, kinda like PIL was.

[markjfine]

Did a preliminary code cleanup to clear out extraneous commented code. Haven't done the full thing yet, bringing the code style and variable usage closer to what's in v2.0.

[markjfine]

As Levon Helm once sung with Bob Dylan... I shall be released... and so it was.

[andrewfer000]

Ah, it's nice to see an official release. I will continue to test and discuss (or implement depending on complexity) new features/improvements/bug fixes as time goes on. I really hope we can find people to help with the Broadcast AM/FM/SW implantation. It's too bad nrsc5 itself does not work like a real HD Radio where it could switch to either using analog or digital. It's probably due to some stupid patent restriction or something...

[markjfine]

Had been thinking about the broadcast part, and there's so much common code for doing this even without a graphical spectrum display that it shouldn't be too hard to leverage something. It's just a matter of creating an nrsc5-like command line module that detects the receiver, then have the user select the frequency, mode, and appropriate bandwidth - setting a default sample rate and direct sampling mode depending upon that. Of course you'd have to play/stop whenever the frequency changes, just like in nrsc5, so scanning might be a small problem. But - it really shouldn't be too hard to keep the frequency widget unlocked while playing, then just simulate a stop/start when/if the frequency changes - like the stream change initially was before implemented the pipe to simulate a 0-3 keypress. Kinda always wanted to implement something like that in dui anyway.

[markjfine]

Realized I never updated the screenshots so I went into Linux to do them. Got to the maps tab and saw the images weren't expanded. Resized and found I couldn't re-shrink. Weird stuff. Everything worked as planned under Darwin...

So apparently check-resize works very differently under Darwin than it does in Linux. I always love finding bugs after a release.

[markjfine]

Reverted the fix I put in to the window resize event until I can find a more consistent way to do this.

[markjfine]

Ok... Think it's fixed for real.

[andrewfer000]

Just pulled down the latest code to test and when I click the play button I get this message and a crash. Gdk-Message: 16:06:20.947: nrsc5-dui.py: Fatal IO error 11 (Resource temporarily unavailable) on X server :1.

and this

[xcb] Unknown sequence number while processing queue
[xcb] Most likely this is a multi-threaded client and XInitThreads has not been called
[xcb] Aborting, sorry about that.
python3: ../../src/xcb_io.c:260: poll_for_event: Assertion `!xcb_xlib_threads_sequence_lost' failed.
Aborted (core dumped)

[andrewfer000]

Nevermind this was caused because my SDR was not plugged in properly.