Rockbox

I think this is good since now the plugins in the list appear in the order of their occurrence in viewers.config which is rather random.

The patch allows to set the delay after which the button repeat event is generated. Since this event is used to detect a long button press, it effectively sets this 'threshold.'

Slow fingered users may often hold the select button too long and (unintentionally) get the context menu. For instance, from the WPS screen. But they actually wanted to go to the file browser.

The patch adds a setting for that delay. Its default value is 30 ticks (=0.3s). The menu entry is in Settings → General Settings → System → Long Button Press Duration.

Some improvements for voicebox on windows. Mainly an option to voice file extensions. Not perfect yet. Instead of an option to voice file extensions there are two voice files options in the hta file. Anyone know what is wrong with this?
Thanks

Over the past month? the radio menu has been disappearing. When I reinstall the menu comes back and the radio works and the debug screen shows the radio.

When it re-initializes the DB, the radio disappears and the debug screen said that there's is no hardware.

If I manually deleted the DB files, the radio comes back…

A few other people on anythingbutipod forum have mentioned the same issue.

Still an issue August 1, 2007: r14133-070801

Simple patch to add RBBLver prefix + suffix to the bootloader version string. rbutil can scan the binary bootloader file to locate this string to determine the bootloader version. download.rockbox.org can now be updated to include bootloader.version files alongside the binaries (e.g. extract the bootloader version from the binary using od -S 6 | grep RBBLver )

Dumb patch but introduces handling for non triangular faces (by triangulating them when rendering). Vertices courtesy of http://mackayj.doosh.net/eliteships.html (in particular I hand-converted http://mackayj.doosh.net/files/vrml/eliteships/cobra3.wrl)

Only filetree.c should be allowed to call opendir(), anything that needs to recursively scan directories should be calling ft_load() which can smartly open, scan and close a directory.

The problem with this is that the filename buffer could get corrupted easily if its misused.

as of r18234 the following is using opendir() in the core
filetree.c:133: dir = opendir(c→currdir); ← not recursive
filetree.c:257: dir = opendir(tempdir); ← in ft_load() so ok
filetree.c:259: dir = opendir(c→currdir); ← “” “” “” misc.c:164: dir = opendir(pathlen ? buffer : “/”);
misc.c:1059: dir = opendir(BOOTDIR);
misc.c:1142: DIR* d = opendir(path);
onplay.c:466: dir = opendir(dirname);
onplay.c:817: srcdir = opendir(src);
tagcache.c:4075: dir = opendir(dirname);

the tagcache and the onplay.c ones are dangerous… the 3 in misc.c are not recursive so safe.

the following are uses in plugins, havnt checked them so I only know for sure that stats, disktidy and properties are unsafe
plugins/disktidy.c:203: dir = rb→opendir(name);
plugins/disktidy.c:270: dir = rb→opendir(name);
plugins/md5sum.c:78: dir = rb→opendir( path );
plugins/md5sum.c:113: DIR *dir = rb→opendir( newpath );
plugins/md5sum.c:209: dir = rb→opendir( arg );
plugins/properties.c:79: dir = rb→opendir(tstr);
plugins/properties.c:151: dir = rb→opendir(dps→dirname);
plugins/properties.c:276: dir = rb→opendir(str_dirname);
plugins/random_folder_advance_config.c:70: dir = rb→opendir(fullpath);
plugins/random_folder_advance_config.c:165: dir_check = rb→opendir(formatted_line);
plugins/rockpaint.c:740: d = rb→opendir( bbuf );
plugins/rockpaint.c:754: d = rb→opendir( “/” );
plugins/rockpaint.c:915: d = rb→opendir( FONT_DIR “/” );
plugins/sokoban.c:925: if(!(dir = rb→opendir(dirname)))
plugins/stats.c:139: dir = rb→opendir(fullpath);
plugins/test_codec.c:763: dir = rb→opendir(dirpath);
plugins/test_disk.c:356: dir = rb→opendir(testbasedir);
plugins/test_disk.c:359: rb→splash(HZ, “opendir() failed.”);
plugins/test_disk.c:421: if 1) == NULL)
plugins/wavrecord.c:3774: if 2) == NULL)

so,
The bad calls in the core should be changed to use ft_load, and the plugins should either get a new function in the lib to grab some ram and manage the whole thing, or maybe its safe to just call ft_load there also?

or alternatively, we can go on ignoring the issue.

It’s still a bit rough around the edges, but I’ve written a new game plugin called NBackBox. It’s an implementation of the dual-n-back exercise, discussed in this Wired article: http://www.wired.com/science/discoveries/news/2008/04/smart_software . In short, it’s a game that improves your brain’s working memory. I’ve tried to keep it as close to how the game was described in the original paper.

Any feedback/bug reports/code suggestions much appreciated :)

Joe

I have just now installed the latest stable version of rockbox (that would be 3.0) on an iriver h340. Unfortunately, it’s unusable at the moment due to some serious screen corruption. It sort of looks like this picture: http://img54.imageshack.us/img54/2263/iriver3qs.jpg, but is so much worse that it’s impossible to navigate the menus. If I wait for the backlight to go off, and then press a button, the screen looks fine until I start navigating, at which point the corruption resurfaces.

I’m really excited about rockbox, but this bug is a showstopper for me at the moment.

Thanks for looking into it!

Regards.

This patch adds a new playback option, Pause Between Tracks. It pauses the playback automatically after each track, and the user must press Play to play the next.

This is useful for e.g dance classes, sound effects etc.

There is a noticeable lag in the simulator, where it starts the playback of the next song before pausing, but who cares? It seems to work fine on the target anyway.

Try it!

Holding the Pause button (to move/paint down) will shut down rockbox.

This shutdown combination should be disabled for Rockpaint!

While I’m at it (and you can put this in a different Flyspray if you want), I suggest that we make use of the iPod scrollwheel somehow in Rockpaint, maybe to change the size or shape of the brush or something and/or in the menus.

I would also like to be able to set the colour of the background to start with.

The patch reorganizes Rockboy to use the same method for storing GB frame buffer data on greyscale targets as color targets. As a result, support for greyscale iPods is much easier and has been implemented (inspired by FS #5282).

Some other changes include:
- Enable the menu for iRiver H100
- Ability to “Show Stats” on all targets
- Screen is redrawn all at once on greyscale instead of line by line
- Elimination of fb.mode (all targets use options.scaling for scaling options)
- Elimination of fb.cc on non-color targets
- Minor variable renaming
- Unification of LCD variables (vdest vs frameb)
- Move greyscale LCD code into lcd.c
- ifdef out vid_update() on greyscale and color targets

Since I don’t have an iPod, I’m curious to see how well this works. It should be fine since the patch my work is based on seems to work for people.

I really need iRiver H1X0 users to test this. There are significant changes to the LCD code and I’d like to know if the is any speed change, whether its an improvement or not. I’d guess that it’s slightly faster or the same as SVN but there’s always a chance that it is slower.

It is a patch that can automatically output the result of logf to the
file.

The setting of default doesn’t output the result of the logf to the
file.
Please set and do the following when it is effective.

System > Debug > logf auto file output: select "Yes"

When the dc jack is plugged in to charge while the player is not running (switched off), the display says ‘ATA Error -11’. It can’t be reset except by removing the batteries and dc jack. I ran an older build from last year and it works fine.

This patch is a proof-of-concept for an adaptive runtime estimation.

Reason to implement such behaviour is that different user settings and user behaviour have large impact to the power consumption and – as a result – to the runtime. E.g. disabling LCD will save lots of power, but some users do not want to disable the LCD to keep readability in daylight.
This patch therefor adapts the estimation of runcurrent() based upon real measurements of the current consumption. The algorithm starts with a default (CURRENT_NORMAL which is defined in the config-file of each player) and uses a weighting scheme with a large time constant to adapt the estimation of the current consumption. The time constant is 1024, which should equal ~20 minutes as the runcurrent()-function is called once per second. With a smaller time constant the runtime estimation is “pumping” too much when the HDD is active.

This first version is just a hard coded experimental solution. Nevertheless something like an actual_current()-function can be implemented for each player in its own powermgmt-file. Players with capability to read the current will return this measured real current, all others still return the fixed default CURRENT_NORMAL.

charging isn’t monitored on ipod 3G. it just goes up to 100% very quickly and stays there.

URGENT/HIGH PRIORITY: Rockbox Firmware 3.7 installed with iRiver H300 1.29J.

Charging when in Rockbox mode (player switched on):

When Rockbox is running and the charger is plugged in, Rockbox can be seen charging the battery in the top left hand corner. When it is fully charged, it shows a full battery.

Charging when iRiver is powered off (player switched off):

When the charger is plugged in, the iRiver begins charging in Original Firmware mode. This is okay as the player charges correctly until Complete.

Booting into OF mode, shows a full battery charge so I can be sure it is fully charged.

However, boot back into Rockbox mode and Rockbox seems to be misreporting the battery charge as depleted - I say misreporting because at this point I know it is actually full/complete. (Booting back into OF mode would also confirm again at this point that there is indeed a full battery charge).

But run Rockbox 3.7 and after a few minutes, a false message - "Low Battery - Shutting Down" appears, after which Rockbox powers off.

I know this is inccorect, because if the battery was so low in OF, the iRiver OF would not even allow you to attempt to power back on (instead it would display a "Low Battery" picture on the display), but I can boot back into OF mode easily with no problems even after this message from Rockbox, again the OF shows a full battery and I can run it for hours with no problem so I know somewhere here there must be a miscommunication/misreading from the battery charge to the Rockbox 3.7 firmware.

Have tested this a number of times to ensure it is a fault and yes it presents itself everytime.

The rockbox behaviour when plugging in a firewire cable is to automatically reboot into disk-mode, preventing charging whilst running rockbox.

Version: 3.13

Variable ‘tmp’ on line 565 is possibly not initialised (found by cppcheck).

There is a bug with the clip zip that when you plug a device in for the first time it doesn't install succesfull the driver and when i unplug it the device crashes and needs a hard reset

External/USB adapters are not correctly detected on my Classic 80Gb, this patch detects it so car mode functionality now works, also the iPod is powered-up when USB cable is inserted.

The function power_input_status() returns USB charger when both external and USB chargers are present. It is possible to detect the external adapter when USB cable is plugged but it is necesary to poll the PMU (not IRQ safe), and i think this information is not currently used at all.

when i pressed the fm radio it’s. but when i press off it sounds like it’s still on and beeping. i’ve got all the settings of for beeping and it’s still on the fm radion i mean. this weird bug i know. please do fix this bug thanks

This very small patch simply plays a beep when a charger is removed or plugged in.
I know  FS#7910  voiced this but that was a bit annoying.

The charger stuff will be removed from p7910. I could have added this to it but it isn’t really that related.

Adds runtime calibrated from (numerous) battery_bench runs on ipod 5g 64mb (60gb)

When I connect my Sansa Clip Zip with most recent Rockbox version to my pc (Windows 8) while it’s paused or not playing a song at all, pc gives message ‘Device not recognized’.
When a song is playing, and I connect the player to the pc, the song will pause (expected behaviour of course), and I can access the internal and sd storage on the device.

The filename cover.jpg works ok. But {album}-{artist}.jpg doesnt wokr. Also the albumart appears on the WPS, but not in the Pictureflow

Currently running r19940 but there doesn’t seem to have been any chage in the power code for the gigabeat S recently.

The issue is that there is a regular clicking noise heard if DC power is connected while the battery is fully charged. This noise is not heard while the battery is charging. The same power adapter doesn’t cause the same noise on an F.

I think commit 1654efc31339972d0e6bd41a499fcffc0a45822e introduces the following error:
storage_init in firmware/storage.c does not return an rc error code in case !CONFIG_STORAGE_MULTI
because its discarded here:

#else /* ndef CONFIG_STORAGE_MULTI */
+ STORAGE_FUNCTION(init)();
+#endif /* CONFIG_STORAGE_MULTI */

+ storage_thread_init();

   return 0;

First, thanks for existing …

I just bought a 8GB Sansa Clip+ and had issues when trying to listen 24 bit Flacs, which was instantly solved using RockBox. Well, the issue I’d like to report is that it freezes when I plug it into my Mac while having the SD card on it; to avoid this I have to remove the SD card, but this is kind of unconfortable.

Any advise?

Thanks in advance

When booting rombox or rockbox from flash on h1x0 with dircache enabled, chances are good that the thing will freeze. This started with r30393 / 7e14b935dfdcd808cfb0703d19a43efd11eeef16.

This still happens with d2f97da668836f5d825c9aaef0d58dea64fc4dd5

This patch modifies the CPU and peripheral bus clocks to hopefully gain some battery life. With this patch the CPU frequency can be either 31 or 186Mhz and the pclk is boosted from 31 to 62 Mhz while the CPU is boosted. The power draw of the CPU is proportional to the clock frequency and setting the frequency at or below what is required for playback keeps the power usage to a minimum because boosting to a frequency below 200Mhz is inexpensive. (Keeping the boosted CPU frequency below 200Mhz eliminates the need to wait for a voltage rise.)

I would appreciate feedback on battery life if anyone has the patience to run a battery bench.

After setting the “Charge During USB Connection” Rockbox setting to “no”, the battery in my iPod Classic still gets charged whenever connecting the iPod to my PC via USB. From the iPod Video manual:

“This option lets you control whether the player should charge during the USB connection and hence draw the full 500 mA. Turning it Off is recommended if the player is connected through an unpowered USB hub or a laptop port.”

I would expect the battery NOT to get charged. Running Rockbox dev build 9576134.

When the battery is low, Rockbox is unable to charge iPod. When booting into Rockbox, the charging icon is displayed, but after a while the device shuts down.

Booting the OF and charging under it for few minutes is required.

this patch adds a setting to choose what to do on a usb connection. default is to connect. options are charge only or connect..

holding *any* button will swap the outcome…

it works, but not perfectly… and the manual patch needs to be checked

When my Fuze+ is charged and it's still connected to the charger, it seems it keeps toggling between charging and discharging.

I think the problem is that it reacts to some voltage to stop charging. When it's charging it measures up to 4.35 V. But when it stops charging it changes to 4.25V, and says something like 96-99% charged, and which point it changes to charging again, and so on.

So it's basicly toggling between charging and discharging very often, and I don't think that's very good for the battery. Once it's charged it should stop charging as long as the charger is connected. (This might apply to other devices too.)

This was with version 2ef7a54-130111

Kurt

Pure i20 does not charge the iPod classic with OS rockbox.
I feel like Rockbox can not recognize interface pure i20 (drivers?)
Through Pure i20 will not play music even if it is in the installed Rockbox in the iPod.(only apple Flash = possible charging/playing via Pure i20)

I own Ipod classic 6G 160GB (flashed rockbox)

This patch adds detection of the charger connection. Not tested on a 1G, but should work if the ipodlinux GPIO documentation is correct.

NOTE: 'Charging' is not detected, just the presence of external power. See http://forums.rockbox.org/index.php?topic=18196.0 for forum topic.

Hi there,

  this is another WIP plugin that I wrote last year.  It plays videogame streamed music
  using the UADE library.  Original homepage here: sourceforge.net/projects/vgmstream/

  I'm a bit new to git so please forgive me for not uploading a proper patch.

  To test the plugin, simply copy the rockstream folder to the plugins folder in
  rockbox sources.  And you have to extract the data.zip file in the .rockbox folder.

  The formats.db found in data.zip is basically a list with all vgmstream supported
  extensions (at least "all" by the time I wrote the plugin).  You can add  or remove 
  new or unwanted extensions there.  The plugin will only handle the extensions found
  in the formats.db.

  Currently the plugin works as a viewer plugin, and there is only one extension associated
  with the plugin in viewers.config for testing purposes, but you can always use the 
  'open with' option from rockbox.  Once you open a file the plugin will parse all supported
  files found in the same folder.

  The vgmstream project is updated quite often, if someone wants to
  update the core library, I believe that would be very easy, since I only changed a couple
  of things to it.

  I'm not going to work on this anymore, so I decided to upload it here, and hope someone
  can make a proper patch and maybe some dev would be interested in testing it, make 
  the necessary changes and upload an stable release.

  As a last comment, I have only tested the plugin in the simulator, samsungypr0, fuze+
  and ipod nano. It only worked in the simulator and samsungypr0, so hope someone can 
  fix that.

  Please read the README file for some additional info about the plugin.

  Working on:  simulator and samsungypr0
  Commid ID: e1ea08417bca57c607df6686472fa0a86f38b6d1

When the battery is nearly empty and the iriver H10 is about to shutdown, the volume sometimes suddenly increases progressively, as if the volume UP button was pressed and held down, all the way up to the maximum.

This has happened to me about 3-4 times so far. Pressing the volume DOWN button somewhat counters this bug, but only for as long as the DOWN button is used - the volume keeps increasing.

This occurs with Rockbox Release 3.5 (not 3.4 as the Report Version field of the ticket says).

This may represent other players as well.

I installed a new battery on my iriver, a 2100 mAh that is working perfectly. The problem however, is that when fully charged, the voltage holds up to 4.12 volts, and until it drains to somewhere under 3.9 volts, Rockbox thinks that it is powered via USB, so naturally Rockbox gets stuck in USB mode until the battery is drained enough for Rockbox to realize that it IS a battery. With this problem at hand, I have to charge my iriver to only less than seventy percent of its battery life, or else wait for an hour or so to drain it to that point. I HAVE tested it in its original firmware, like I said, works perfectly. The problem lies with Rockbox thinking that the battery is a USB charger. I am asking for a fix around this. Is there a way that I can modify Rockbox so that it may understand that it is running off of a battery that will get up to 4.12 volts and not mistake that for USB power? I just now thought to turn off the “Charge During USB Connection,” maybe that will solve the problem; I will get back when I find out whether or not that works. However, I would still like to request a work around for this problem. Any help is much appreciated. Thanks.

sometimes when i click on next(or previous) button a couple of times , rockbox gets stuck and then anfter 3 or 4 secs ,it restarts .then when loaded the battery is empty.
i am not sure if this is a rockbox related issue or hardware realated cause i use my ipod for file transfer mainly .and this issue existed from version 3.3 till now( i cont know or remember about before that).

is there a way that i can somehow debug (trace) this issue?

The remaining time estimate shown under System>Rockbox Info reports just “0h -1m”.

The battery indicator on the status line works OK… maybe it’s just a display bug?

When plugging in an AC USB charger, the ipod shows rockbox's disk mode instead of just changing the "external power" icon. Is it possible to make it detect if a charger is connected, or an usb host (for example, a computer)?

Doing the same test (with the same charger) on an ipod color/4g shows the expected result (not going to usb mode, just a charger icon appears)

Using the latest revision (r20001 - but its been broken since I started using Rockbox) the iAudio M3 does not recharge the battery using either the USB or the Power adapter.

The only way I can get the iAudio M3 to charge is to use Cowon’s firmware.

Alarm wakeup doesn’t work reliably. It is unclear whether the setup is wrong or the wake up is. It might be that the player wakes up before time because of a small press on the power button and thus somehow forgets about alarm.

   I've update my ipod nano 2G to r23629. I found the clickweel would remember the last point my finger leave. And next when I touch the clickwheel, it will make a farward/backward move according to the last point I left, even click the button. Now it is not convenient to type a word with the keyboard inside or setting.
   And my Mac doesn't launch my ipod when I connect my ipod with USB until I change to disk mode. Seems that the USB driver doesn't work.

The Idle Poweroff only reboots my 1G iPod. I assume it should power it off or put it into a power saving mode. This forces it to use up the battery faster then normal unless I set the Hold button to boot into the iPod firmware to do a proper suspend when Rockbox reboots.

When using the H300 non-lcd remote to turn on the player (iriver H340) I get the following error message “hold switch on, power off…” (the hold switch is not on).

I used the official toshiba updater to get an “original” fresh install on my beast and then attempted to run through the install procedure for a single boot rockbox install. After a (seemingly) sucessful install I’d end up in recover mode after any reboot.

Fatal error when attempting to install nk.bin (rockbox only bootloader) using sendfirm in Windows to an updated (v1.2) Gigabeat S player.

After install of both bootloader and rockbox the Gigabeat S, once rebooted, goes into recovery mode (toshiba) and requires an update/restore. This is the Number 3 Triangle.

Notes:
Gigabeat was first updated using the official toshiba MESV12US updater. “gbs_update_1_2_us.exe”

Using SVN revision 19741 to compile nk.bin under WinXP and Cygwin.
Using MTP.zip of 7/4/2008 found on the wiki to send over the bootloader.

I suspect most devs updated their bootloaders using the sendfirm utility *before/without* updating the entire player with the updater utility from toshiba. Thus they started from a v1.1 OF and never updated any part of that.

Maybe the updater changes something in the bootcode. I don’t know.

This isn't a big problem because the MR-100 won't turn on if the hold switch is already engaged.

But if the user turns on the MR-100 and then engages the hold switch while the M:Robe logo is on the screen, a "Hold switch is on Shutting down…" message is displayed, but it does not shut down.

A reset is required at this point - disengaging the hold switch and holding down the power button in this state does not shut down the MR-100.