maemo.org Bugzilla – Full Text Bug Listing
|Summary:||Can't change FM TX radio station name|
|Product:||[Maemo Official Platform] Multimedia||Reporter:||Fabrice Crohas <fcrohas>|
|Component:||FM Transmitter||Assignee:||unassigned <nobody>|
|Status:||VERIFIED FIXED||QA Contact:||fmtx-bugs|
|Priority:||Medium||CC:||aldon.hynes, andre_klapper, deusmalo, fcrohas, m, vdv100|
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:220.127.116.11) Gecko/2008121300 Firefox/3.0.5
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=
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.
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.
(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).
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
(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). :)
(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.)
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.
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).