Bug#873402: Radio: frequency can get reset to preset #1 on startup

[Maximiliano Curia]

¡Hola Ben!

El 2017-08-27 a las 06:59 -0700, Ben Wong escribió:

Package: radio
Version: 3.103-3+b1
Severity: normal
Tags: patch



Dear Maintainer,



The radio program incorrectly changes the frequency on startup under
certain circumstances because it does not correctly calculate the band.



To recreate:



1. Create a file called "~/.radio" with contents like this:



   [Buttons]
   1= 8955
   2= 9035



2. Tune in a frequency that is not one of the presets.
  For example, 'radio -f 94.9'  (then 'q' to quit)



3. Run 'radio' again and note that the frequency gets changed to the
  first preset.



(Note: This bug doesn't occur if the radio is set to a frequency that
is one of the presets).



The problem is that the radio program converts the current frequency
to a band by looking at frequencies that are listed in the presets. It
ought to look at the frequency ranges of the available bands.



I have included a patch which does that.


Sorry that it took me so long to reply your email.

You are reporting an upstream issue, and it seems to me that it would be 
better if you send this kind of patches upstream directly. You can contact 
upstream through the linux-media mailing list: linux-me...@vger.kernel.org


Although the project is no longer in active development the still accept 
patches/fixes.


Happy hacking,
--
"Seek simplicity, and distrust it." -- Whitehead's Rule
Saludos /\/\ /\ >< `/


signature.asc
Description: PGP signature

Bug#873402: Radio: frequency can get reset to preset #1 on startup

[Ben Wong]

Package: radio
Version: 3.103-3+b1
Severity: normal
Tags: patch

Dear Maintainer,

The radio program incorrectly changes the frequency on startup under
certain circumstances because it does not correctly calculate the band.

To recreate:

1. Create a file called "~/.radio" with contents like this:

[Buttons]
1= 8955
2= 9035

2. Tune in a frequency that is not one of the presets.
   For example, 'radio -f 94.9'  (then 'q' to quit)

3. Run 'radio' again and note that the frequency gets changed to the
   first preset.

(Note: This bug doesn't occur if the radio is set to a frequency that
is one of the presets).

The problem is that the radio program converts the current frequency
to a band by looking at frequencies that are listed in the presets. It
ought to look at the frequency ranges of the available bands.

I have included a patch which does that.

-- System Information:
Debian Release: 8.4
  APT prefers oldstable-updates
  APT policy: (500, 'oldstable-updates'), (500, 'oldstable')
Architecture: i386 (i686)

Kernel: Linux 3.16.0-4-686-pae (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages radio depends on:
ii  libasound2   1.0.28-1
ii  libc62.19-18+deb8u10
ii  libncurses5  5.9+20140913-1+b1
ii  libtinfo55.9+20140913-1+b1

radio recommends no packages.

radio suggests no packages.

-- no debconf information
--- console/radio.c.orig	2013-04-18 04:18:43.0 -0700
+++ console/radio.c	2017-08-27 06:45:44.456665505 -0700
@@ -300,6 +300,22 @@
 
 /* -- */
 
+static int band_from_freq(int ifreq)
+{
+unsigned int v4l2_f = ifreq * (freqfact / 1e6);
+int i, largest_band = 0;
+
+for (i = 0; i < no_bands; i++) {
+	if (v4l2_f >= bands[i].rangelow && v4l2_f <= bands[i].rangehigh) {
+	if ((bands[i].rangehigh - bands[i].rangelow) > largest_band) {
+		largest_band = bands[i].rangehigh - bands[i].rangelow;
+		return i;
+	}
+	}
+}
+return -1;			/* No band found for frequency */
+}
+
 static int check_band_n_freq(int *band, int ifreq, const char *extra_msg)
 {
 unsigned int v4l2_f = ifreq * (freqfact / 1e6);
@@ -890,8 +906,7 @@
 }
 
 if (band == -1) {
-if ((i = find_station(ifreq)) != -1)
-band = p_bands[i];
+	band = band_from_freq(ifreq);
 }
 
 if (band == -1 && !newfreq && fkeys[0]) {