Rockbox

  • Status Closed
  • Percent Complete
    100%
  • Task Type Patches
  • Category User Interface
  • Assigned To No-one
  • Operating System All players
  • Severity Low
  • Priority Very Low
  • Reported Version
  • Due in Version Undecided
  • Due Date Undecided
  • Votes
  • Private
Attached to Project: Rockbox
Opened by rasher - 2006-09-29
Last edited by jdgordon - 2007-08-04

FS#6088 - Remove debug menu for regular builds

This patch removes the debug menu from regular builds. The following has been done:

apps/debug_menu.c is only compiled when DEBUG_MENU is defined, which it is on when selecting a (D)evel build in configure

a new file, apps/debug_functions.c has been created, which contains functions that used to be in debug_menu.c, but are called from elsewhere: dbg_partitions() and dbg_ports().

The screendump option has been moved into the display menu, since I believe that is the only option semi-regularly used by ordinary users (it should be, at least). dbg_screendump() has also been moved to debug_functions.c.

The result:
rockbox.iriver size before: 343364
rockbox.iriver size after: 325948

I have not yet compiled any Archos build (haven’t got a crosscompiler handy).

Closed by  jdgordon
2007-08-04 14:43
Reason for closing:  Rejected

Previous patch broke simulator builds, this version fixes that.

I don’t like the regular daily / cvs builds not including the debug menu as it can help tracking down user problems, e.g. as being able to look up the current status of tagcache etc. But how about converting the debug menu into a plugin? (no idea if this is feasible, just as an idea)

Hrm, I forgot about the tagcache status, but if that’s the only other thing regularly used, I still think that completely removing the Debug menu is worth considering, simply moving the Tagcache menu somewhere else (directly under info, probably).

I don’t think making the debug menu a plugin is very feasible, since pretty much each and every function needs access to a different piece of hardware or rockbox internals. Exporting all the necessary functions to the plugin struct would probably not be worth it.

That’s not the only thing ever used. Some examples:

Frequently I’ve had people complain of buttons doing irregular things, and having them watch values in the debug screen can tell me if their button is returning abnormal values, or an abnormal range.

As well, the debug screen can be useful for, as previously mentioned, both TagCache and DirCache status.

Thirdly, when people are experiencing playback skipping or glitches in a new situation, having them watch the audio thread to see how many buffered songs there are, and whether various things happen around a rebuffer or under certain other conditions can definitely shed light on things.

I don’t really see the benefit of removing it out of dailies and CVS builds. I think the only build it shouldn’t be in is a version numbered on. Maybe.

I disagree with Paul’s last point there - it’d be more professional without it, but for a build that so many people will be using, you should really be able to access that information. Maybe it could be hidden somehow, like… to access it, you go to the info screen and tap a key or a combo, for example. *shrugs*

For what it’s worth, *every* *single* *time* I boot Rockbox on my 5G I go into this menu before anything else and boost the CPU because things are horribly slow at 30MHz. Manual CPU boosting should *not* be removed from any build.

Paul: The benefit is saving space, which I have a feeling the Archos builds would benefit greatly from (probably less than the nearly 20kb of iriver, but still significant)

Zakk: The fact that you in any way need manual CPU boosting is a bug and hardly a good reason to not remove the menu.

Maybe the debug menu could be hidden only on Archos, where it’s much less needed, and the savings are much more needed.

Maybe daily builds could be available in “regular” and “debug” (don’t know how feasible that is).

Anyway, I could create a patch that simply adds checking for NO_DEBUG_MENU or something like that, so it can be removed in the future if desired.

I still think the screendump function doesn’t belong in the debug menu (but should probably explain somehow that usb gets disabled to avoid confusion) though it’s really a different issue to be honest.

Jonas: Well, no, it’s not really a bug, Rockbox just runs very poorly on the 5G without boost.. more than likely because of its LCD size, it takes much longer to navigate and scroll through lists at 30MHZ and this also makes the decoders run slower and much more prone to causing button input to be slowed majorly or even stopped by the new scheduler. It’s not like you can simply say “oh, right, here’s what’s wrong” and “fix” the fact that the LCD’s huge and takes a while to update..

I honestly rather doubt this will do very much on Archos. I haven’t tried it, it will certainly affect the filesize but not nearly as much as the 20kb difference on iriver. Also - why haven’t you tried it yourself? Just compile an Archos copy of it and compare the AJZ and UCL sizes with a daily build.

Loading...

Available keyboard shortcuts

Tasklist

Task Details

Task Editing