Rockbox

WOW! i have been waiting for this featuer since day 1!,. when
do you rockbox implementors( sorry, but i dont know your
names) think that this will be installed into the daily builds?
any time soon? also, Craig Sather, could you maybe post a
compiled version of this patch on the site? (crossing fingers!).

Thanks alot!! This patch just made my day!!
-A

yeah it would be nice to get the binary

Nice feature, I like it.

But please move it from firmware/ to apps/. This is not a
firmware (operating system) feature and should thus not be
located there. Call car_power_management() from status.c
instead, it knows when the plug is connected or disconnected.

Hi Bjorn,

Thanks for taking a look at my patch. There are a few
reasons why it ended up in the firmware power_thread.

1) I sought guidance on the mailing list, and Linus
and I agreed that the power thread was a good place to
put the functionality.

2) Another similar system setting support function –
handle_auto_poweroff() already resides and executes in
the power thread, so it seems to follow current
convention on what types of functionality already
exists there on the firmware side.

3) Placement of the function in the power_thread
insures that the external power status is monitored
and the car adapter mode function works regardless of
what state the “application” side was left in by the
user while an mp3 is playing. Monitoring the external
power status from a place such as inside status_draw()
means that it will not function if the application
side is in a state where it is not periodically
calling status_draw(). Currently a Rockbox user can
do things on the application side that stops the
periodic calls to status_draw(), and leave it in that
state (while playing an mp3 file) which would
inadvertently disable the function if it was part of
the status code as you suggested.

4) This new function has little relation to the status
bar updating functions, but is more closely tied to
and more logically matches the functionality of things
that are already being done in the power thread.
Putting it in the status code just because there is a
function there that gets called periodically most of
the time (but not always) seems to be somewhat of a
hack. There is currently no requirement for the
application side to periodically call status_draw() if
they are doing something which makes status bar
updating unnecessary, and using status_draw() as a
place for calling functions that must always execute
periodically adds that new requirement on all
application code.

5) The line between application and firmware code is
already somewhat blurry as shown with the example in
#2 above (and additionally with existing firmware
functions that have hard-coded calls to application
functions), so an argument can be made that better
functionality & cleaner design has and should continue
to take precedence instead of enforcing rules that the
current code does not follow.

6) You have not suggested that I do so, but I
considered and then decided that it would be a waste
of resources to create a new thread on the application
side to poll the external power status just to get
around the problems stated in #3 above.

Well, that’s my long winded argument. If you still
want me to put this function in the status code, I
will, but it will work more consistently and be a
cleaner implementation if left in the power thread.

Hello. Can you please post a compiled version of this patch,
so all of the people can enjoy your hard work?

Thanks

Hello. Can you please update this to make it work with the
flashed rockbox firmware files? - it would solve alot of the
problems there. - as i understand it, you cannot have a
firmware that is before a certain date when using a flashed
jukebox.

Thakns

I don’t understand your concern. There is nothing in this
patch that has anything to do with the ability to flash. If
this patch is applied to the current bulid, it can be
flashed to your Roclbox flash memory.

exactly - “if it is applied to the current daily build, it can be
flashed to your Roclbox flash memory.” Right now, it cannot
be flashed, because it is applied to the daily build from june
2nd.

Warning: Undefined array key "mailguard" in /home/rockbox/flyspray/plugins/dokuwiki/inc/common.php on line 929 Warning: Undefined array key "mailguard" in /home/rockbox/flyspray/plugins/dokuwiki/inc/parser/xhtml.php on line 697

This patch as it currently exists isn’t “applied” to any
build. The patch stands by itself. Patches do not have to be
applied only to the build from which they were made, they
can be applied to subsequent builds. Patches applied to
subsequent builds may or may not still apply cleanly. If
they don’t apply cleanly, the patch utility indicates what
parts of the patch it could not apply, so that those changes
can be applied manually.

If you are not able to apply the patch yourself and still
want this feature in flash, I would suggest that you contact
the project admins (notably Bjorn Stenberg
bjorn@haxx.se)and ask them to put this patch in the CVS baseline. There is quite a bit of demand for this patch,
but unfortunately it has just sat here for 3 months waiting
for a response from the project admins.

I did what you asked, and e-mailed bjorn, but still no
response. It looks like a while before we will have this in the
CVS. In the meantime - could you please patch this file to a
daily build, so more people can use it, and comment on it to
the administrators - thus making implementation faster?

Updated patch file to apply cleanly to daily20030811

Cool, thanks! but i meant to make it so that it was an
ajbrec.ajz file - or a rockbox20030811.ucl file.

Sorry for the misunderstanding

If you email me privately (rb_dev@yahoo.com) I can get you
the .ajz file.

I haven’t played around with doing any flashing or even read
the docs so if you need any help getting from the .ajz file
to flashing your recorder, I would suggest that you ask the
people on the mailing list who have been working with the
flash stuff.

after a few bugs in the code, i patched in my source and it
worked…..

but, after i turned the feature on and after the jukebox
turned totally off, the jukebox doesn’t turn on again when the
ignition switch is turned on.

Question: is there temporary and absolute RAM place?????

after a few bugs in the code, i patched in my source and it
worked…..

but, after i turned the feature on and after the jukebox
turned totally off, the jukebox doesn’t turn on again when the
ignition switch is turned on.

Question: is there temporary and absolute RAM place?????

answers to: LordRG125 AT web dot de

after a few bugs in the code, i patched in my source and it
worked…..

but, after i turned the feature on and after the jukebox
turned totally off, the jukebox doesn’t turn on again when the
ignition switch is turned on.

Question: is there temporary and absolute RAM place?????

answers: lordrg125 AT web DOT de

If you think that you have found bugs in the code please be
specific, as people have been using this patch on both
recorders and players without any problems.

Also, as the initial patch description states, playback will
only resume if external power is applied BEFORE the idle
poweroff function has shut the recorder off. Once the unit
is turned off, the Rockbox code can’t be used to control
anything, because reapplying the power at that point only
causes the default Archos firmware charging code to execute.

hi

I’m newbie on patching rockbox … and I would like to patch the standard 2.0 version with
your, but I can’t find the right command to patch succefully
… Could you right here, the command to apply it, or could
you send it to me ?

geo_fr at hotmail dot com

Could someone email me the .ajz with this patch. This is just
what I’ve been looking for but l can’t work out how to patch.

richard.a.walker@btinternet.com

What about a auto on??
I used it for a couple of weeks and it disturbed me that
everytime i switch the jukebox on, I have to go through
menus and switch the carmode on… Isn’t there any way to
permanently switch it on??? Is it?

Please think about it before implementing it.

The last setting restored after a power off/on cycle,
however since this setting is saved to disk only if the disk
is spun up after the setting is changed but before the unit
is powered off, the setting (and some other settings also)
will not be saved if the unit is powered off before doing
some operation that spins up the disk.

As long as some operation that spins up the disk (such as
browsing the directories or loading the buffer while playing
an mp3 file) is performed before the unit is shut off, the
latest setting will be restored when the unit is powered
back on.

This behavior is documented in the user manual on page 10,
however the manual incorrectly states that this is true only
on Player models, but on Recorders this is also true for
some of the settings that are only stored on disk by the
Recorder (as opposed to the RTC memory area where there is
limited space for the Recorder to store some settings).

could auto-on be implemented when firmware is flashed?

The problem might be that settings are stored into disk. So
this feature would have to be ‘hard’

One other solution would be to reserve one flash sector for
storing settings.

Too bad I only have a player which is actually not working
with flashable rockbox!

Could anybody store the patched binary for the player
somewhere on the web and make the url available? That
would be great.

Thanks

Yes it can.

What’s stopping it from working already is the fact that we
enter the battery charging screen instead of booting up when
DC is connected to a turned off recorder.

This (car auto stop) feature is now in Rockbox. You don’t need
a patched binary to use it.