Closed andrewfer000 closed 1 year ago
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.
You got the All Clear from me to start cleaning the code. I think where the program is now is good for a release.
Cool. Now I just need to review the procedures for doing a release so I don't screw it up.
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.
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.
As Levon Helm once sung with Bob Dylan... I shall be released... and so it was.
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...
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.
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.
Reverted the fix I put in to the window resize event until I can find a more consistent way to do this.
Ok... Think it's fixed for real.
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)
Nevermind this was caused because my SDR was not plugged in properly.
General Testing Notes to continue on from #6