search

AlexandreRouma / SDRPlusPlus

Cross-Platform SDR Software
GNU General Public License v3.0
4.12k stars 571 forks source link

Completely unable to run on Mint Vanessa #1056

Closed wittend closed 1 year ago

wittend commented 1 year ago

Full Build/Run detail in:

SDRPlusPlus-1.04_build failure_latest.txt

Hardware Machine: Type: Desktop System: 6-core model: AMD Ryzen 5 5600G

Software

Bug Description Any attempt to run sdrpp Segfaults.
RtApiJack::getDeviceInfo: error determining Jack input/output channels! Segmentation fault (core dumped)

Steps To Reproduce

  1. Build
  2. Install (or not)
  3. Run

Only If SDR++ fails to lauch or the SDR fails to start: Run SDR++ from a command line window with special parameters: On Linux: Open a terminal and run sdrpp -c: Doesn't work. Dies. sdrpp -s:

sdrpp -s [2023-05-04 21:58:18.062] [info] SDR++ v1.0.4 [2023-05-04 21:58:18.062] [info] Loading config [2023-05-04 21:58:18.150] [info] Using OpenGL 3.0 [2023-05-04 21:58:18.209] [info] Loading icons [2023-05-04 21:58:18.214] [info] Loading band plans [2023-05-04 21:58:18.216] [info] Loading band plans color table [2023-05-04 21:58:18.216] [error] Menu element is missing name key [2023-05-04 21:58:18.219] [info] Loading modules [2023-05-04 21:58:18.219] [info] Loading /usr/lib/sdrpp/plugins/radio.so [2023-05-04 21:58:18.220] [info] Loading /usr/lib/sdrpp/plugins/hackrf_source.so [2023-05-04 21:58:18.221] [info] Loading /usr/lib/sdrpp/plugins/airspy_source.so [2023-05-04 21:58:18.221] [info] Loading /usr/lib/sdrpp/plugins/spyserver_source.so [2023-05-04 21:58:18.225] [info] Loading /usr/lib/sdrpp/plugins/network_sink.so [2023-05-04 21:58:18.242] [info] Loading /usr/lib/sdrpp/plugins/airspyhf_source.so [2023-05-04 21:58:18.259] [info] Loading /usr/lib/sdrpp/plugins/recorder.so [2023-05-04 21:58:18.275] [info] Loading /usr/lib/sdrpp/plugins/rtl_sdr_source.so [2023-05-04 21:58:18.292] [info] Loading /usr/lib/sdrpp/plugins/frequency_manager.so [2023-05-04 21:58:18.309] [info] Loading /usr/lib/sdrpp/plugins/audio_sink.so [2023-05-04 21:58:18.328] [info] Loading /usr/lib/sdrpp/plugins/discord_integration.so [2023-05-04 21:58:18.342] [info] Loading /usr/lib/sdrpp/plugins/plutosdr_source.so [2023-05-04 21:58:18.359] [info] Loading /usr/lib/sdrpp/plugins/meteor_demodulator.so [2023-05-04 21:58:18.376] [info] Loading /usr/lib/sdrpp/plugins/weather_sat_decoder.so [2023-05-04 21:58:18.392] [info] Loading /usr/lib/sdrpp/plugins/rigctl_server.so [2023-05-04 21:58:18.409] [info] Loading /usr/lib/sdrpp/plugins/soapy_source.so [2023-05-04 21:58:18.426] [info] Loading /usr/lib/sdrpp/plugins/rtl_tcp_source.so [2023-05-04 21:58:18.442] [info] Loading /usr/lib/sdrpp/plugins/file_source.so [2023-05-04 21:58:18.459] [info] Initializing Airspy Source (airspy_source) [2023-05-04 21:58:18.479] [info] Initializing AirspyHF+ Source (airspyhf_source) [2023-05-04 21:58:18.495] [info] Initializing Audio Sink (audio_sink) [2023-05-04 21:58:18.509] [info] Initializing Audio Source (audio_source) [2023-05-04 21:58:18.525] [error] Module 'audio_source' doesn't exist [2023-05-04 21:58:18.525] [info] Initializing BladeRF Source (bladerf_source) [2023-05-04 21:58:18.542] [error] Module 'bladerf_source' doesn't exist [2023-05-04 21:58:18.542] [info] Initializing File Source (file_source) [2023-05-04 21:58:18.558] [info] Initializing Frequency Manager (frequency_manager) [2023-05-04 21:58:18.575] [info] Initializing HackRF Source (hackrf_source) [2023-05-04 21:58:18.597] [info] Initializing Hermes Source (hermes_source) [2023-05-04 21:58:18.608] [error] Module 'hermes_source' doesn't exist [2023-05-04 21:58:18.608] [info] Initializing LimeSDR Source (limesdr_source) [2023-05-04 21:58:18.625] [error] Module 'limesdr_source' doesn't exist [2023-05-04 21:58:18.625] [info] Initializing Network Sink (network_sink) [2023-05-04 21:58:18.642] [info] Initializing PlutoSDR Source (plutosdr_source) [2023-05-04 21:58:18.659] [info] Initializing RFspace Source (rfspace_source) [2023-05-04 21:58:18.675] [error] Module 'rfspace_source' doesn't exist [2023-05-04 21:58:18.675] [info] Initializing RTL-SDR Source (rtl_sdr_source) [2023-05-04 21:58:18.695] [info] Initializing RTL-TCP Source (rtl_tcp_source) terminate called after throwing an instance of 'nlohmann::detail::type_error' what(): [json.exception.type_error.302] type must be string, but is null Aborted (core dumped)

See attached file for more detail with forced -r pointing to a setup 'root_dev' file. (Where is this thing supposed to go - couldn't tell from DOCS)

Screenshots Dies too fast for that.

Additional info Spent 2 days trying to make this thing work!

AlexandreRouma commented 1 year ago
  1. You're still running 1.0.4, as asked in the template, use the nightly (this is why the arguments you're trying don't work...)
  2. The json error you're getting is caused by all the crashing corrupting the config file, delete ~/.config/sdrpp or whatver root directory you're using (don't use a custom root directory if you're not doing development)
  3. For the original JACK issue, duplicate of https://github.com/AlexandreRouma/SDRPlusPlus/issues/878
wittend commented 1 year ago

Alexandre,

I am trying to follow the instructions on the SDRPlusPlus Github. I download the release 1.0.4 because it is marked as the release version. I (try to) follow the instructions in the readme.md there for Linux. If this is not the correct way to do this, how am I supposed to know that?

And where (for non-dev use) is this config.json file supposed to be? I see nothing that explains that, though it is semi-mentioned in the case for development use. make install does not seem to address it.

I have seen some hints that others have had similar problems in 'issues' marked closed. But ones marked 'closed' normally mean that they were resolved in some way. That is why they are not shown by default.

Clearly my problem has not been resolved, but you mark it 'closed'. This is a novel way of responding to unresolved or undocumented issues. I have never seen anyone manage a public Git repo this way.

And from long experience I usually avoid 'nightlies' as if (and they DO) they carried plague. Even when I know that they exist.

Dave

On Fri, 5 May 2023 at 11:19, AlexandreRouma @.***> wrote:

Closed #1056 https://github.com/AlexandreRouma/SDRPlusPlus/issues/1056 as completed.

— Reply to this email directly, view it on GitHub https://github.com/AlexandreRouma/SDRPlusPlus/issues/1056#event-9178511512, or unsubscribe https://github.com/notifications/unsubscribe-auth/AACSMIWIFFVNO6OGXG3ZOATXEUSC5ANCNFSM6AAAAAAXWSFZ7M . You are receiving this because you authored the thread.Message ID: @.***>

AlexandreRouma commented 1 year ago

I am trying to follow the instructions on the SDRPlusPlus Github. I download the release 1.0.4 because it is marked as the release version. I (try to) follow the instructions in the readme.md there for Linux. If this is not the correct way to do this, how am I supposed to know that?

The template you filled out when creat!ng the issue instructs you to first switch to the nightly version because there would be no point in reporting an issue that potentially has already been addressed.

And where (for non-dev use) is this config.json file supposed to be? I see nothing that explains that, though it is semi-mentioned in the case for development use. make install does not seem to address it.

As my initial response said, the config files are located in ~/.config/sdrpp.

I have seen some hints that others have had similar problems in 'issues' marked closed. But ones marked 'closed' normally mean that they were resolved in some way. That is why they are not shown by default.

Always search for closed and open issues before opening another issue. Having to go around giving the same solution multiple times wastes a lot of time and creates duplicate entries for the same problem. The GitHub issues are a bug reporting system, not a forum.

Clearly my problem has not been resolved, but you mark it 'closed'. This is a novel way of responding to unresolved or undocumented issues. I have never seen anyone manage a public Git repo this way.

The issue linked in the original gives you the corrective actions to fix the problem you are having. Other people have had this problem and the solution has always worked, I am not gonna leave an issue open when it has already been addressed.

And from long experience I usually avoid 'nightlies' as if (and they DO) they carried plague. Even when I know that they exist.

This is a good default assumption but in the case of this project (and this project only) they are explicitely stable, they just don't have a fixed module API. This is why the issue template tells you to use them to check if the bug is already fixed.