Bug 7271 - Can't change FM TX radio station name
: Can't change FM TX radio station name
Status: VERIFIED FIXED
Product: Multimedia
FM Transmitter
: 5.0/(1.2009.42-11)
: N900 Maemo
: Medium normal with 1 vote (vote)
: 5.0/(10.2010.19-1)
Assigned To: unassigned
: fmtx-bugs
:
:
:
:
  Show dependency tree
 
Reported: 2009-12-23 17:46 UTC by Fabrice Crohas
Modified: 2010-03-15 20:55 UTC (History)
6 users (show)

See Also:


Attachments


Note

You need to log in before you can comment on or make changes to this bug.


Description Fabrice Crohas (reporter) 2009-12-23 17:46:28 UTC
SOFTWARE VERSION:

Nokia N900
Maemo 5
Version 1.2009.42-11

EXACT STEPS LEADING TO PROBLEM: 
1. Open Shell 
2. fmtx_client -s test
3. result is fmtx_client: ERROR: Unable to set RDS station name (Invalid RDS
station name)

This problem occurs everytime , with my application i do the call over DBus and
got exactly same error

EXPECTED OUTCOME:

This should change the Radio station name from Nokia to test

ACTUAL OUTCOME:

Keep Nokia as station name

REPRODUCIBILITY:

Always

EXTRA SOFTWARE INSTALLED:

none

OTHER COMMENTS:

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; fr; rv:1.9.0.5)
Gecko/2008121300 Firefox/3.0.5
Comment 1 Valério Valério maemo.org 2009-12-24 01:49:54 UTC
Seems to work fine with 51.1


Nokia-N900-51-1:~# fmtx_client -s test
Usage:
------
-f<uint>    Set frequency (in kHz)
-s<string>    Set RDS station name
-t<string>    Set RDS info text
-p<uint>    Turn fmtx on (1) or off (0)

Current settings (Frequencies in kHz):
--------------------------------------
version=1
frequency=88100
freq_min=88100
freq_max=107900
freq_step=100
state=disabled
rds_ps=test
rds_text=
Comment 2 Thomas Perl 2009-12-26 21:24:53 UTC
I can confirm that I had the same problem with 1.2009.42-11 and that it has
been fixed (the error message, that is) in 2.2009.51-1. I have not been able to
get my custom station name to display on the radio, but that could be something
else.

As Valerio wrote, the "Current settings" output of the command is properly
updated to reflect the change.
Comment 3 Aldon Hynes 2009-12-28 05:50:32 UTC
The docs that I had read said that the station name must be eight characters.

e.g.

fmtx_client -s test 
will fail
however
fmtx_client -s "test    "
works properly, at least on my machine.
Comment 4 Thomas Perl 2009-12-28 14:52:58 UTC
(In reply to comment #3)
> The docs that I had read said that the station name must be eight characters.

Thanks, that's helpful. In this case, we might change this to a feature request
where the fmtx_client automatically pads shorter strings with spaces, which
shouldn't be too much of a problem, and eases CLI usage (and avoids bogus bug
reports, because there is no error if the station name is shorter than 8
characters).

(Should we close this bug as "fixed in 51.1" and open another feature request
or is it okay to turn this bug into a feature request that deals with padding
shorter strings, as described above?)

Also, I guess it's okay to set a station name longer than 8 characters,
correct? At least I have seen that the media player generates long strings and
these are then "scrolled" in the RDS display (but it could be that the FMTX
code simply rotates the string then, and the length still has to be a multiple
of 8).
Comment 5 Fabrice Crohas (reporter) 2009-12-28 15:08:31 UTC
hello,

  There is some strnage thing, ok with 8 characters, but why 8. Actually as a
workaround i use /sys/class/.../rds_ps_name and i set it by hand manually.

My Radio display is 9 long not 8, i don't understand this limitation.

Ok to close this issue as solved in 51.1.

Thomas Perl wrote :

Also, I guess it's okay to set a station name longer than 8 characters,
correct? At least I have seen that the media player generates long strings and
these are then "scrolled" in the RDS display (but it could be that the FMTX
code simply rotates the string then, and the length still has to be a multiple
of 8).


In 42.11 the text is never displayed on RDS radio system, i ve done an
application called FM RDS Notify available in extras-devel which do that and
more feature.

Can you confirm me that feature you say is in 51.1 ? 

Thanks all for your  answer
Comment 6 Andre Klapper maemo.org 2009-12-31 18:46:59 UTC
(In reply to comment #4)
> (Should we close this bug as "fixed in 51.1" and open another feature request
> or is it okay to turn this bug into a feature request that deals with padding
> shorter strings, as described above?)

Yes, please (with severity == enhancement). :)
Comment 7 Thomas Perl 2010-01-01 17:20:50 UTC
(In reply to comment #6)
> (In reply to comment #4)
> > (Should we close this bug as "fixed in 51.1" and open another feature request
> > or is it okay to turn this bug into a feature request that deals with padding
> > shorter strings, as described above?)
> 
> Yes, please (with severity == enhancement). :)

Done: https://bugs.maemo.org/show_bug.cgi?id=7552

Please, anyone who is interested in getting this fixed, subscribe to that bug
and eventually vote for it :)

(BTW: I can verify that this has been fixed in 2.2009.51-1, so I'm marking this
bug as verified.)
Comment 8 hex 2010-01-23 02:18:00 UTC
This bug (7271) seems to reference a couple issues so will start here because I
think some might want to check this.

The original bug driving this ticket is fixed (error when trying to change),
but am I the only one that can successfully change the text (via fmtx_client or
editing rds_ps_name) - padded appropriately and the name doesn't stick (IOW,
goes back to "Nokia   " usually w/in minutes)?

fmtx_client -s "01234567", run fmtx_client again to check (sometimes back to
back). Looks fine and at some point (I can't tell what triggers it), it reverts
back to "Nokia   ". rds_radio_text also does not stick (using fmtx_client and
manually changing). It also reverts to nothing (default).

Sometimes I change the text, run fmtx_client a couple times and all looks fine,
do nothing and a few minutes later check again and it's reverted. I've changed
then a -p 1 and it reverted, sometimes it doesn't. Same with -p 0. I can change
then enable, disable and it is fine, but a few minutes later it reverts.

I've also noticed that after a restart, I check power_cat and it is at 0, which
it should be since it's disabled. Once I enable, it goes to 113, drops to 88 as
mentioned when USB plugged in, then back to 113 when unplugged so that is
working as it should. But, if I disable, power_level stays at 113 even if I let
it sit for a while (have left it for 2-hours). It goes back to 0 only on
restart. I haven't let it sit all day though.

I know the power_level is not part of this bug, but providing some additional
information that may or may not apply and others can check. Didn't want to open
a bug unless directed.

I don't think the transmitter draws much power, but with some of the battery
complaints I've seen pop up, I thought it might be of interest. If not as
designed and the radio is still drawing power, every little bit helps.

I don't find anything related to either of these issues in bugs.

I am on pretty close to a fresh flash:
OSSO_VERSION='RX-51_2009SE_2.2009.51-1.002_PR_002'. Nothing installed from
devels and only Storage Usage from testing. Just a couple apps from Extras.
Comment 9 Andre Klapper maemo.org 2010-03-15 20:55:43 UTC
Setting explicit PR1.2 milestone (so it's clearer in which public release the
fix will be available to users).

Sorry for the bugmail noise (you can filter on this message).