Unable to capture data (from file)

[a9e78rauijasdf]

Issue Type

bug - IO error

Expected Behaviour

Expected to be able to add data to Dspectrumgui without crash :o)

Actual Behaviour

Input/output error @ io_fillbuf - fd:24 /dev/pts/10

unable to add recorded file. Inspectrum opens up just fine, but when selecting data and closing the Inspectrum window, DspectrumGUI ends up on a crash page, not adding the data file.

What commit were you running?

You are currently running: || c0719ed

[Très Acton]

What crash page? Can you describe what actions you are taking?
And when you say closing the inspectrum window, do you mean that you are closing it, or that it's closing itself once the data is sent to stdout?

[Mark Cooke]

I get a similar issue. Following your pdf example, Inspectrum has 2 extract options now
Extract symbols: 1. To stdout, 2. Copy to clipboard

Selecting To stdout closes Inspectrum (it does close) then opens a new instance of Inspectrum. Closing this second instance produces the following error:

Errno::EIO at /devices/1/units/1/captures/new
Input/output error @ io_fillbuf - fd:21 /dev/pts/6

At line 42 from captures_controller.rb, spawned from line 36

app/controllers/captures_controller.rb
36 PTY.spawn(cmd) do |r, stdin, pid|
37   begin
38     got_it = false
39      
40      loop do
41        if !got_it
42          line = r.gets
43          raw = line.chomp.strip.split(',')
44          puts "\n[*] Data as array: #{raw}" 
45          if raw.count > 1
46            demod = ''
47            arr = raw

[midas]

I'm having this same problem, anyone knows how to fix it yet?

[Très Acton]

hey sorry for the delay. I need to figure out why the code is behaving like this on some systems. as a workaround for now, it seems if you close the first inspectrum that spawns, and use the second one, it works as intended. I'll do some troubleshooting soon and see why this is behaving like this. I'll leave this issue open until properly resolved.

[Amir reza Irani ali poor]

I had same problem and inspected rail log. In many systems when you run inspectrum, it produce some warning about the qt!

In Qt 5.4, there was an experimental implementation of high DPI scaling introduced via the QT_DEVICE_PIXEL_RATIO environment variable, that you could set to a numerical scale factor or auto. This variable was deprecated in Qt 5.6. (source)

It just goes to stdout and rail collect it as data array! You may see the output i post here and match with your one

[*] Data as array: ["Warning: QT_DEVICE_PIXEL_RATIO is deprecated. Instead use:"]

[*] Data as array: ["QT_AUTO_SCREEN_SCALE_FACTOR to enable platform plugin controlled per-screen factors."]

[*] Data as array: ["QT_SCREEN_SCALE_FACTORS to set per-screen factors."]

[*] Data as array: ["QT_SCALE_FACTOR to set the application global scale factor."]

[*] Data as array: ["Gtk-\e[1;32mMessage\e[0m: \e[34m02:01:53.674\e[0m: GtkDialog mapped without a transient parent. This is discouraged."]

So i tried to set environment variable of qt in my profile path /etc/profile and added this lines to the end of it.

export QT_DEVICE_PIXEL_RATIO=0
export QT_AUTO_SCREEN_SCALE_FACTOR=1
export QT_SCREEN_SCALE_FACTORS=1
export QT_SCALE_FACTOR=1

But still same error! It's not just about inspectrum, but many programs with qt under-hood suffer the same problem :(

As @tresacton said before, we can just close the first inspectrum window for now and do our work with second one (on every new capture submit).