-
Notifications
You must be signed in to change notification settings - Fork 10
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
GUI fails sporadically #36
Comments
Pure speculation: this sort of mystery error can sometimes happen if GUI operations are performed from outside the GUI thread. At a glance it looks like that could be happening in some places (e.g. |
I'll try that tomorrow. |
I was also going to suggest switching on the logging feature in Settings if it's not already set. That may also give a clue where it's happening. What also may be helpful is if I can get a snapshot of the Settings tab, so I know what other features are being used. The musicbrainz feature that attempts to download album art that is not provided by the station can sometimes be a problem. I mostly run this on a Mac, but I'll run it on Fedora 39 to see if there's a similar problem there. |
I'm still checking in Linux, however, as I was preparing it, something else occurred to me: Admittedly, the formal release 2.2.2 is quite old and several changes have been made since then. I've just been too busy to create an updated release package. What you might do is pull down the latest nrsc5-dui.py from the repository and replace the one from v2.2.2, as well as to update some of the Python requirements listed in requirements.txt with pip3 and see if it doesn't improve things. In particular, I see you're using Pillow 9.x. That really should be updated to 10.x. That's where all the image processing is for album art and station logos, as well as traffic and weather images. |
Update - running from gdb (now I know how) produces no issues in this morning's testing (multiple runs). Of course LOL I'll keep working at it to try and get you useful data. Q: what is the gdb command that will save such useful data for upload to this report? I'll review your other comments. I'm happy to run a nightly, though I thought that's what I was running. And, while I have you, thanks to you and all the developers who've worked on this application. I love finding something unexpected that gives me something I've missed. I moved into a condo that is about 200 yards from a local television station and its antenna. My condo is also built into a ridge, with the station SE of me, and my unit faces west. So, I've my whole building and the ridge between me and it. This situation causes lots of radio/em issues. Though I live easily inside the 5G AT&T coverage area, I only get 1 bar of cell reception and no 4G, 4G LTE, or 5G at my unit. That ridge and building between me and the tower where the cell antennas are mounted. But being so close to that tower means that radio reception is awful because of bleed over. Interestingly, the one radio that gets good reception is an old Sony handheld "transistor" radio. All of my fancy radios, including my Pioneer AV Receiver, get awful reception, even with powered antennas. But this SDR? Amazingly, the software filters, etc. just mostly work. I've mapped nearly 2 dozen stations, and with HD nine additional channels, I can listen to. Amazing!! So, thank all of you!! |
You're certainly welcome and someone's already working to make this a lot better as I've been quite busy with other things over the past year. One thing I can say is that the new interface, which will be Qt-based, looks just fantastic. I too echo the frustration of living in an area with poor cell reception. As for gdb - and it's been a long time since I've used it. That said, if I'm not mistaken, I think you can just pipe the output that normally goes to the screen to a file. |
Welp. Added a print line to the py code to determine if running in the venv, and no, it is not:
Output:
So don't consider that in your deliberations. |
To keep it current, you just need to go to the main directory (in this case, where nrsc5-dui.py is), and run Settings look fine, and musicbrainz wasn't being used (Download Album Art option) so that should be ok. I think once you get the Python sorted you should be ok, but let me know if there continues to be any issues. And yes, better Arsenal than ManU... My daughter has a new boyfriend that has DC United season tickets. I asked her to ask him who he supports and to answer very carefully... |
Will update here when I have something. Thus far today it hasn't horked once. l |
Update: nrsc5 and/or nrsc5-dui issue. What I hear. Normal output, then, in this specific instance, Frank Sinatra singing "Or she could laugh" that repeats every 12 or so seconds. What I see. Then the nrsc5-dui GUI freezes, is unresponsive, then redraw fails (see image): Forced to pkill it. Log output extract from within nrsc5-dui:
To tshoot, run nrsc5 from terminal. Console output extract:
Then same 12-second repeat. But note the difference in the outputs. The second correctly shows Artist: Frank Sinatra. But the first shows Herb Alpert & The Tijuana Brass, which is interesting. If I let it run, the INFO in the stream changes, but the audio is stuck on this repeating fragment, about 1-2 seconds. This fragment is persistent across runs of both nrsc5 standalone and nrsc5-dui. Could be something at the source, but figured I'd check here as well. Is there a cache somewhere that I've horked with my starts and pkill stops? Or something I need to delete when I do that? |
Interesting. Usually what nrsc5 reports is correct, so the Tijuana Brass thing could just be an info delay at the station. I've seen that in a few instances. The audio is a different issue. Just wondering if there's something in your audio interface that's not quite right (I've not trusted anything ALSA-based for decades). Thinking this may be an additional/independent processing problem to what you were reporting here as well as over at nrsc5. Just curious: Did you build nrsc5 using either the NEON or SSE options, and, what architecture are you running? |
Architecture in the first post. I used no additional build options, so built with the defaults. And just to confirm, I just ran
The audio for this frequency and channel is still glitched. I can run
and shift between the three channels for this station, and it's only channel 1 that exhibits this glitch despite the updated INFO. If there is no cache or anything that can be local, I'd assume this must be at the source, right? I didn't mean, by putting this in this report that it's related to our previous posts. I perhaps should not have mentioned it. But thought it easy to ask if there were local caches, etc. I could easily delete. |
No problem. nrsc5-dui does no caching, but nrsc5 might have some buffering in order to make the packet streaming seamless. |
Incidentally, Most of the year's gone by and I've been remiss in updating the versioning and dates in the py file. I've just fixed that. |
FYI. While exploring use of pulseaudio to stream the audio from ncrs5 and SDR++, I horked pulseaudio. To fix that I attempted to upgrade/reinstall packages using MXLinux's package tool. The system now will not boot. I may revert to kubuntu. Will be a few days to get this fixed. |
Ugh. Good luck. |
That took WAY longer than I'd hoped, but system now functioning. The update failed to successfully reconfigure installed packages. That has led to issues with the i915 GPU system. I've now had to put nomodeset in the boot params to get to a working system (about 8 hours to figure that out with single user mode restarts, etc.). But sound was still hosed. After lots of re-installing, removing/reinstalling pulseaudio, still nothing. Last ditch effort - install pipewire and see if that rejiggered configs and, presto-chango, I now have working sound AND working pulseaudio. No idea about pipewire. Not even going to touch it. So, after all that, one app I ran to check things was nrsc5-dui. I ran it, this time, from a saved script I used to get it on my KDE Panel Multimedia menu. It runs, then fails after I start playing a channel. The spawned nrsc5 continues to play after the GUI dies. On Wednesday the GUI ran hours without issue when I run it from a terminal prompt. I think (?) that somehow KDE is not playing nice when it's launched from within the Plasma UI like this rather than from a terminal. I'm going to do some testing to see how it fares when launched multiple ways. For now, I'm thinking that this is NOT a nrsc5-dui issue. |
Linux HOLLIN 6.1.0-10-amd64 theori-io/nrsc5#1 SMP PREEMPT_DYNAMIC Debian 6.1.38-2 (2023-07-27) x86_64 GNU/Linux
MX Linux MX-23.1, KDE Plasma 5.27.5, Debian 12.2
NRSC5-DUI 2.2.2, newly downloaded and installed.
nrsc5 revision theori-io/nrsc5@80ab64e, RTL-SDR v3 receiver, using the dipole attenna.
Often, but not everytime, the nrsc5-dui gui will crash. The nrsc5 process it spawned to play the SDR feed continues. As I type this, the GUI is gone, yet I'm hearing the Channel. This is the output for this event (note that I'm starting it in the background, which is what the &! is for, a ZSH shell command; the behavior occurs whether I do this 'start in the background' or not):
I can restart nrsc5-dui, but it does not recognize that nrsc5 is currently running and was started by it before it crashed.
The text was updated successfully, but these errors were encountered: