Unable to customize menu 3.13 on (SanDisk Sansa) Clip+

[gordonmcdowell]

We're using some Clip+ in school, and would like to disable FM Radio by removing the menu option.

Have been creating config.cfg (in .rockbox) which contains...

root menu order:wps,files,bookmarks,settings,plugins,database,system_menu

...and have loaded that .cfg via Settings > ManageSettings > Browse.cfgFiles > config

See no change. Reboot. See no change.

Have also tried...

root_menu_order:wps,files,bookmarks,settings,plugins,database,system_menu

...just in case that was an issue, does not work either.

I've even only tried "settings" as an option, just to confirm I'm not messing up any of the options. I see no difference.

Can someone confirm this is working on Clip+ devices? Maybe the existence of hardware supported FM Radio makes this an unusual device and that somehow bypasses the custom menu support?

Thanks for any help! (Love this firmware I've deployed to about 50 Clip+ devices so far. Used it to capture audio for a documentary too.)

[[Saint]]

You are attempting to use a feature on a build that vastly predates said feature's inclusion.

This feature was added a great length of time after the binary you are using was released, if you wish to make use of this feature (and a host of other bug fixes and improvements), I highly suggest updating to a current binary.


[Saint]

[gordonmcdowell]

You are attempting to use a feature on a build that vastly predates said feature's inclusion. This feature was added a great length of time after the binary you are using was released, if you wish to make use of this feature (and a host of other bug fixes and improvements), I highly suggest updating to a current binary.

Isn't 3.13 the latest stable build? I should be using a daily build then?

3.13 was released 2013-03. I thought this was a 2012 feature.

I'll certainly try a daily build. But please correct me if I'm mis-understanding what you're telling me to do (use a daily build).

[saratoga]

I think menu customization has been in since before 3.13 but I still wouldn't recommend running such an old build.

[gomezz]

But 3.13 is the latest stable release build (according to the information on here)?

[saratoga]

Correct. We haven't gotten around to marking a new build stable in a long time now.

[[Saint]]

You'll have to forgive me for not pointing this out earlier, but I answered from a mobile device in haste.

This is a way forward for you, but I honestly don't think it is the "right" way forward.

Anything you disable in this fashion can be very easily re-enabled. This feature offers no security whatsoever.

Depending on the age of the intended users of these DAPs, I wouldn't be surprised if any number of them figure out how to re-enable any feature(s) you disable, on the device itself, very trivially. Almost certainly within a matter of minutes.

All the user would need to do to re-enable any and all menu items you disable is reset the device configuration, this can be done trivially in several (at least three different ways I can think of, one of them impossible to guard against in a standard build) ways from the device itself. Even the use of a "fixed.cfg" (this config file is functionally identical to config.cfg, but is executed _last_, and ensures a known configuration is applied) would only have an effect on repairing the desired device configuration if the device is rebooted also, it is possible to clear the configuration and not reboot, ...what this basically means is that with any of the builds that come from us unmodified, any of those intended to use them can circumvent whatever restrictions you want to put in place in a matter of seconds.

And kids these days are savvy. Heck, they could ask Google how to avoid your restrictions on their smart phones and do so in a matter of minutes, without having any prior knowledge or experience with the operating system before.

To recap, the way forward here, if you don't want anyone to be able to undo your modifications with extreme ease, is a full custom build. One that doesn't just remove the FM main menu entry, but instead removes the feature from the build entirely.
This is a lot simpler than you may expect it to be, depending on your exact requirements, you may already be perfectly capable of this yourself. Or you may be able to come to some form of arrangement with a member of our community to do the work for you.

I know some of us have a special soft spot for the education sector.

Above all else, I would like you to achieve this in the "right" way, and a massive part of going to this effort relies on ensuring that that effort cannot be trivially undone with a few minutes of asking Google how to.


[Saint]

[gomezz]

Correct. We haven't gotten around to marking a new build stable in a long time now.

Then please explain further why you recommend to the average user that they run a newer but unstable build?

[gevaerts]

Correct. We haven't gotten around to marking a new build stable in a long time now.

Then please explain further why you recommend to the average user that they run a newer but unstable build?

You're using the wrong meaning of "unstable". In some contexts, that means "crashes often", but in software release terminology it tends to mean "changes often".

[gomezz]

in software release terminology it tends to mean "changes often".

Not in the software release terminology with which I have been familiar my whole working life.

Rockbox Development Builds
 
These builds are provided fresh after every source code change. If builds are not currently showing, wait 5-10 minutes and then refresh the page.
 
Since these builds are generated from actively developed source, at times they may be buggy or even unusable. We appreciate your feedback on any issues you may encounter.
 
For a stable build, download the latest stable release.

What am I supposed to make of that then?   

[[Saint]]

in software release terminology it tends to mean "changes often".

Not in the software release terminology with which I have been familiar my whole working life.

We define the terminology clearly on the main page.

Rockbox Development Builds
 
These builds are provided fresh after every source code change. If builds are not currently showing, wait 5-10 minutes and then refresh the page.
 
Since these builds are generated from actively developed source, at times they may be buggy or even unusable. We appreciate your feedback on any issues you may encounter.
 
For a stable build, download the latest stable release.

What am I supposed to make of that then?   

I'll give you that.

This presents some non-small area of confusion, granted. Perhaps adding further to the confusion in this case is that we're not talking about the differences between stable/unstable/unusable in this instance, but rather (or perhaps as well as) release/development.

The targets with a stable release are also expected to be largely functional in the development builds, the fact that it is a development snapshot doesn't detract from the fact that the port achieved a status of stable. Once one is aware of what we mean when we use the terms stable/unstable/unusable, it becomes quite a bit clearer. Sure, it is possible that a development build will unearth some new bug, that is always a risk, but a development snapshot is also going to include some two years worth of additional bug fixes and any bugs unearthed are usually dealt with rather swiftly.

Much more swiftly than, say, the release cycle. Which at this point, as you may well be aware, has ground to a halt.
The fact that we haven't released in ages isn't due to us not being able to offer a stable release, it more of a communication and community breakdown, but that is a topic for another long winded post I believe.

I hope I have made things somewhat clearer, it should fall into place when one has an understanding of our port classifications (stable/unstable/unusable) and what they mean, but if I've just managed to dig up more questions I'm happy to take a stab at answering those too.


[Saint]

[gomezz]

Thanks for that considered response.  I appreciate better now how things are done here being very much a newcomer to the Rockbox world.

[gordonmcdowell]

I'll look at recent (stable) builds. Thanks. I'm not really worried about a student trying to re-enable the radio... will deal with that if it comes up rather than presuming it will be an issue... it does not seem like disabling radio hardware is a feature most people would want.

Um... but I do have a more generic issue for Clip+ hardware. I don't want to try resolve it on this thread, but I am wondering how RockBox coders would perceive a "bounty".

I use the Clip+ to capture audio for a documentary. The timing is off a bit... I need to speed up the audio to 100.04% when editing for a steady sync. (And that value is an approximation!)

That could be addressed by either fixing the timing... maybe not possible... or simply altering the meta-data on the WAV so that the Hz is an accurate number... it seems most editing packages will then interpret the audio correctly.

Is offering a bounty a socially ok approach? I should I just throw a small amount of money at RockBox and hope someone will deal with it? I mean if it could result in a new, "stable" build for Clip+ which includes newer features AND addresses this problem then the school is helped and I'm helped... but I don't want to offend anyone by going the bounty way... but I don't want to donate money hoping it will be addressed only to find it ignored and then thing to myself ("darn I wish I'd tried the bounty approach").

So is bounty socially acceptable? (And I don't see a mechanism... is the idea I just post the wish-list to Support forum, and if anyone names a price I can consider the generic PayPal Donate button as a way of unofficially getting-it-done?)

[saratoga]

I use the Clip+ to capture audio for a documentary. The timing is off a bit... I need to speed up the audio to 100.04% when editing for a steady sync. (And that value is an approximation!)

Thats normal.  Unless you use the same clock for audio and video they will not line up exactly, and the difference will change over time.

[gordonmcdowell]

It does not change over time... and it is consistent across the 50-or-so Clip+ I've used since using them for this purpose. Maybe there's some fluctuation down at the smaller decimal values, but I've never had a better fix than by adjusting rate to 100.04% in the editing package (Premiere Pro CC... for many revisions... and this also happens in Sony Vegas). And I've ordered from 3 different refurbished-vendors on 3 different years.

Maybe it won't be perfect, maybe it will drift a tiny bit on top of this issue... some a tiny bit faster some a tiny bit slower. But there's a substantial timing problem there that I'm certain is consistent in the hardware, bigger than the small drift you might be predicting.

And... I see the 1.4.0 installer now allows me to automatically install a fresh (non-"stable") build! That's great but loading a tweaked config.cfg file seems to have no impact on menu, even though I'm using the latest dev build, edb0c6c-141.