Rockbox

I put up the three patches (before they expire on pastebin.com) that correspond to the three proposals of how the behaviour of PREV/NEXT could/should be changed. Note that only the situation described in the “subject” of this task is considered and changed.

The IRC discussion is at http://www.rockbox.org/irc/log-20090406#21:35:42

The start of the discussion on the mail list is at http://www.rockbox.org/mail/archive/rockbox-dev-archive-2009-04/0057.shtml

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.

This should hopefully make beatbox compile and run on any target with enough buttons.

All it needed was some key mappings (and some typo fixes). I’m assuming the function declaration for synthSamaples() simply changed over time, as the original code was missing an ‘s’ on the end of function name and looked like this:

  synthSamples(&synthtemp[0], &synthtemp[1]);

The second param should be the sample size or something, but it was passed an address.

If it doesn’t work on a particular target due to lack of a key map, please add one, or tell me the target and i’ll stick a keymap in

Patch from within root rockbox source folder.

Hopefully this works for you all, its many hours of fun =D

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 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?

Hi,
There is a problem in the Chinese voicing. It says "number, bai fen ji" (number %), but it's supposed to say "bai fen ji number) (% #). I don't know if it happens in text because I'm blind. Could this be fixed?

A couple of config file options are missing from the manual appendix:

e.g.

backlight fade in: 2000
backlight fade out: 10000

How to reproduce this:-

Use the remote to turn on the player while the hold switch is set to lock on the player. Backlight on both the player and the remote stay on constantly (timeout is set to 5s presently).

If you set the hold switch to unlock the backlight goes off after the timeout has expired and thereafter will turn off however the hold switch is set.

[EDIT: Attached patch for experimenting with AS3543 settings.]

When playing back audio on a Sansa ClipV2 player, there is a regular background noise that’s audible with sensitive headphones and that’s quite annoying during quite music passages. The background noise is a hissing sound that repeats about 4 times per second. The noise can be heard when there is no disk activity and even at very low volume or when playback is muted. It stops as soon as audio is paused.

The noise is not present in the original firmware (OF).

This is a long-known issue, but hasn’t been formally tracked before. It is related to FS#11907, but different in that the background noise is present when there’s no disk (SD) activity. However, I did have the impression that disk activity intensifies the noise.

This item serves to collect the various approaches people have tried to eliminate the noise, and ideas for future exploration.

I ran a series of experiments on the assumption that the audio hardware is misconfigured is some way. I worked through various settings of the AS3543 component based on its datasheet. Here is what I have tried; but nothing helped to eliminate the noise:

* Higher-quality audio settings as proposed in  FS#11304  (AUDIOSET2_HPH_QUALITY_HIGH,
Disabled DAC gain control
Bypassed mixer and disabled mixer gain control (HPH_OUT_R_HP_OUT_DAC, AUDIOSET2_AGC_off,
Mute SDI data
Enable and control DAC attenuation
Disable common mode buffer (phantom ground)
Disabled various unused mixer components (AUDIOSET3_MICMIX_off, AUDIOSET3_ADCMIX_off,
Used external clock source for DAC
Enable headphone detection
Resetting all reserved audio registers to 0

[EDIT: I have attached a patch that allows experimenting with these settings by uncommenting the relevant source lines at compile time or extending the provided debug function to toggle the setting at run time.]

Possible next steps (suggested by various people on IRC):

* As the noise is not present on the other AMSv2 targets (Clip+, FuzeV2), a dump of the AS3543 settings (as3514_regs[] array) on these targets would be helpful. I have attached a patch that adds a debug-menu function for doing this (needs a logf build).

* Someone with a JTAG could read the AS3543 configuration set by the OF.

* The issue could be unrelated to the AS3543; it could be a power-management or frequency-scaling issue.

Also attached: A dump of as3514_regs[] (logf.txt; all values in
I’ve removed the patch to dump these settings; see a later comment in this task for a more up-to-date patch to do this.]

Other ideas?

I’d like to suggest the following new WPS feature(s):

1. A viewport can be assigned an image as a “backdrop”.

 a. A viewport may be assigned an image dynamically via the WPS tag "%VX<identifier>"
   (i.e. %VXa for image a, %VXZ for image Z, etc.)
  b. As a viewport is being processed and drawn, its backdrop would be drawn "first", followed by any other normal images/characters.

2. Viewport may define FF00FF as a background color, which would then be “transparent”. This would allow overlapping viewports.

3. Fonts drawn in a viewport with a backdrop would automatically be drawn with DRMODE_FG.

Notes on the attached patch file:
+ It was created from the SVN revision 18997 on Nov 3, 2008.
+ Although I stubbed in the new functions for all the LCD drivers, I’ve only flushed out the 16 bit driver so far.

Cheers!

Split out from  FS#11748 .

This patch adds an option to prevent rewinding to the beginning of a track to avoid losing the current playback and resume position by accidentally pressing the Left key. Instead, Left always directly skips back to the previous track. This behavior can be enabled for all tracks or only for those tracks that can be autoresumed on automatic track change (which already is separately configurable).

I'm dropping this patch here for now because I see little chance right now of this being accepted into the trunk. Some developers have complained about the considerable configuration complexity of autoresume as it is, and although this additional behavior can be convenient, there is no ultimate need for it because the resume position prior to the rewind to 0:00 is preserved as long as another skip occurs within the first 15 seconds of the rewound track's playback (for example, by pressing Left again to skip to the previous track).

This change was originally contributed by Dave Slusher in  FS#11748 . I just added the configuration logic.

Patch relative to r29484.

I've found a problem with the new autoresume feature in 3.8. I use it when listening to podcasts and sometimes find that it resumes from near the end of a new episode - e.g. on a 30 minute podcast it will resume from 28 or 29 minutes - usually about the place where a previous epidsode finished and I skipped past the end credits.

What I think is happening is that there is some code in the database that tries to resurrect the runtime statistics for files that have been deleted and then restored - as the last offset is in this data, it is reusing the last offset from an old episode.

I've put some more logf()s in tagcache.c in build_numeric_indices(). I can see that if the filenames don't match (line 2306) it then tries to match any 2 tags out of the 3: artist, album or title. For the podcasts, the artist and album are always the same (i.e. the producer and which one of their podcasts it is), but the title is different (i.e. "Episode 100", "Episode 101", etc). So if I've listened to Episode 100 and then deleted the file, and then add Episode 102 to the player, it matches the artist and album and so resurrects the wrong data from Episode 100.

I've disabled the resurrection based on tags (just commented it out) and the problem seems to have gone away. A better fix would be to ensure that all 3 tags or matched or to ensure that title is one of the matched tags

This is an attempt to automate the setting of $PATH in tools/rockboxdev.sh, tools/configure and the generated Makefile.

The directory prefix of the cross compilers is stored in ~/.config/rockbox.org/RockboxCompilerPrefix. As the default path (in tools/rockboxdev.sh) is /usr/local, if that file is empty, then $PATH won’t be modified. Otherwise, the value stored inside that file will be read, the target platform type appended, and lastly /bin appended. The resulting string will be appended to $PATH.

This patch doesn’t break existing configuration. But it’s most probably incomplete, so please provide feedback on which files need to be modified as well.

These two scripts will, if you run them appropriately generate a few screenshots in an automatic fashion. Execute it like this, from inside a simulator: ./genscreenshots e200.xte /path/to/output

There are a few pitfalls:
* The simulator window MUST gain focus when it is run. If this doesn’t happen, everything breaks. Horribly.
* The method is rather timing sensitive. I had to put a pause of 250ms between each keypress to make sure they registred (too fast, and the sim/SDL would discard them). 250ms may not be the right amount for your computer.
* Rockbox itself is also timing sensitive. If you “push” a button at the wrong time, it may not register, so use plenty of sleeps to make sure things are settled.

Edit: Oops, the first version had a hardcoded filename. Hopefully of such things.

This may be all players; I have only had experience with the Sansa Clip+ and Clip Zip. On version 3.13 the Automatic Resume feature works inconsistently, especially on the 2nd+ file of a playlist.

In version 3.11.2, the feature worked correctly on my Clip+. If I paused the player and the player turned off due to the timeout, when I turned the player back on and pressed the “Home” button or “Resume Playback”, the entire playlist would be back in place and playback would resume at the spot I paused. If I was 30 seconds into the third file in a playlist, playback would resume at that point. When that file finished, the next file in the playlist would start. Pressing “Previous” or “Next” would play the previous or next file in the playlist.

In version 3.13, this feature does not always work correctly. In fact, it rarely works correctly when playing a file that is not the first file in a playlist. Some times it works fine. Most times when I try to resume playback, it instead plays the beginning of the first track in the playlist. Some times when that happens, if I manually navigate to the track I was in when I paused, it will resume that track from the correct position rather than starting it over from the beginning.

This behavior is seriously agitating. I use my player to listen to multi-hour podcasts broken into separate files for each hour. If I get a phone call and pause my player I expect my player to automatically shut itself off after a few minutes, and it does. When I start the player again, I want to be able to pick up just where I left off. On versions prior to this, I could. In 3.13 it does not work 9 out of 10 times.

When the option “Auto-change directory” is enabled, my Ondio crashes at the end of the current folder’s playlist when it would have to create a new one.

The error it shows is “I09: CPUAdrEr at 09010FF8”. The address varies a bit with the actual revision, this example is with r26246 and an OndioFM backlight build (but the problem is present in plain SVN builds too). Looking at the map file shows that the crash happens in the cue_find_current_track function.

Bisecting build turned up that the error was introduced with the cuesheet rework in r21978/9 and the fix in 21982 fixed usual folder playback but not auto-change directory. It is reproducible on the Archos Recorder so I assume a general hwcodec problem.

Hi there,

first of all: this is my first contribution to rockbox and I tried my best to make myself familiar with the way things work there. I am sure, not everything is where it belongs. Please help me to get things in order :).

second: thanks to the author of Patch  FS#1803  that made this possible.

The purpose of this patch is to watch the tuner reported field strength (estimate) and mute, when it drops below a customizable threshold. Wether muting or not as well as the threshold are customizable in the fm tuner menu. It should not interfere with manual muting and should not affect recording (i didn’t test that yet). THe threshold is specified in pseudo-dBuV.
It also adjusts frequency display to display as MMM.KKK instead of MMM.KK. This is for people who adjust region settings and channel widths.

My testing conditions were limited to the sansa c250.  FS#1803  reports to work on the tuner chips LV24020LP (e.g. sansa c250) and TEA5767. I only tested the first. Please report back possible field strength values you see on devices using these chips.

This code should not break anything. I did a testbuild for some iPods (without tuner) that compiled cleanly. Simulator also works.

Currently only english and german translation are done.

User guide:
This patch conditionally adds 1 or 2 lines to the tuner main window that look like this:

Sig: [-M] -235dBuV
Automute below -555dBuV

The second line is only displayed if automute is enabled. The first line shows the status of the tuner. The 2 characters in the braces exlain as [ab]:

a: either 'O' or '-' 
   'O': current field strength is above threshold
   '-': current field strength is equal to or below threshold
b: either 'M' or '-'
   'M': will mute on or below threshold
   '-': automute disabled.
(both are only updated on field strength change)

The second line should be selfexplaining, same for the menu entries.

Request for comments!

There is different level audio between Radio and Music Playback with the same db value. Level audio on Music Playback is too low.

Experienced Results:
I have 2 folders(lets call them FolderA and FolderB) each containing audio files.
FolderA and FolderB are both on the root of my drive
Neither one has a database.ignore file in it.
I go to settings → general settings → database → update now
All files are added to the database as expected
…But i realize i dont want FolderB to show up in the database.
I add a database.ignore file at /FolderB/database.ignore
Then I go back in and update the database again(settings → general settings → database → update now)
all of my audio files still show up in the database(including the ones in FolderB with the database.ignore file)

Expected Results:
After adding the database.ignore file to FolderB and updating the database(settings → general settings → database → update now) the audio files in FolderB should no longer appear in the database

Summery:
Any files in a folder containing a database.ignore file should be removed from the database on update

Rockbox Info:
Build Version: daily / e3cddc2-120701

I have RockBox version 3.9 on my Sansa Fuze v2 and so far I love it, but I have one problem. On a few tracks in my library, when I play them, the first few minutes of the song will be strangely distorted. Most of them are songs where the music starts off in just one of the speakers before moving into the other one. There will be bursts of loud, crackly noise in the other speaker during these first few seconds (that seem to be in time with the music) and then it will fix itself and the rest of the song will play perfectly. When I boot the default Sandisk firmware the songs play perfect like they should, it is only in RockBox that this glitch happens. I’ve messed with the settings a bit and even reset them completely, but nothing has worked thus far.

Attached is one of the songs that this happens with, from about 2 seconds in to about 7 seconds in. Any help would be greatly appreciated. I really want to enjoy my music without that crap in it.

I'm decided to make myself useful today and hammered out most of the rest the code needed to move http://www.rockbox.org/tracker/6048 along.
I'm starting a new entry since the old one is closed.
I'm hosting all the work I do at http://foolsh.no-ip.org/projects/atari2600/wiki/Wiki

2600box Plugin

* Added the .make file
* Added keymaps for most color targets
* Added to viewer.config loads *.bin files
* Fixed screen resizing for smaller screen targets
* Compiles against HEAD/master

I'm still testing sim builds at the moment.

There is some bad news, it crashes in the sims after a minute or two, and the buttons on my fuze+ don't work for some unknown reason but they do in the sim.

Everything else is looking pretty good. I'd like to hear back from people who have real hardware and can test the keymaps.

I have an upgraded iPod 5.5 with CF 32Gb installed in CF-ZIF adapter.
Both iTunes & Rockbox are working fine with this setup.

Then I tried to increase the storage space by using mSata SSD 64 GB + mSata-ZIF adapter. iTunes recovered the iPod successfully and it is working just fine. I installed Rockbox latest stable (non-stable latest = same thing) version & after the Rockbox boot-up it reporting an ATA error -11.

I wonder if this can be solved.

Thanks!

This patch modifies hardware registers for pclk & fclk in one instruction.

I’m currently testing it on Clipv2 to see if it gets rid of crashes

I didn't like that the "Backlight on first keypress" function ignores the first keypress no matter which key was pressed. For example, I want the volume keys to work normally even when the backlight is off (that is, they should turn on the backlight *and* change the volume).

This patch restricts "Backlight on first keypress" to certain buttons only. in other words, these buttons work normally only when the backlight is on; otherwise, they just turn on the backlight. As a proof of concept, it changes the Clip and Clip+ behavior to filter out only the Home key when the backlight is off, allowing the other keys to function normally.

It works by allowing button-target.h to define the buttons that are filtered by the "Backlight on first keypress" function. If left undefined, the function filters all buttons when the backlight is off, as in the status quo.

[EDIT: Clarified that there is no overlap with  FS#9305  - Context sensitive backlight on key press]

r30804
The rockbox (r30804) Can't play ape files with CUEsheet (APE + CUE files).

Hardware: Clip+ 8GB using internal memory
Problem: Playback of most APE files results into passages of loud noise during playback. The music is totally gone and noise is ear deafening loud. When rewinding, till music is heard, and replaying the problem part, error can be reproduced _sometimes_.
In other cases it either runs fine, or the problem occurs elsewhere in the file.

Since the problem does not always occur in a specific part of a APE file, it is hard to attach a sample file.

Problem persisted between ape files encoded in high and normal setting.
Using winamp + monkey audio 3.99 APE plugin, these files never shown problems.

Playing APE 24/44.1 with harsh noise in different parts of the track. If you decode APE file to WAV using the codec console, then there are no problems. So the matter is in the player’s APE decoder.

At 24/48 everything is fine.

Hardware: iriver H140, iriver H340, Sansa Clip+

Rockbox version: 3.10 downloaded from http://www.rockbox.org/download/byhand.cgi I have also reproduced bug on official firmwares as old as 3.5.1, and on my own builds.

Settings: 100% default except for enabling EQ and setting an EQ i.e. using graphical EQ to set LS -0.5 at 60Hz or LS +1.5 at 60Hz

Expected behaviour: music track, however loaded, starts in normal way, with no sounds other than those decoded from file. Restarting the track results in the same normal playback.

Actual behaviour: music track starts with an obvious and intrusive click. This happens whether the track is loaded individually, or if it is the first track of an album loaded via .m3u playlist. When using playlist subsequent tracks play normally, without a click. But restarting any track causes the click.

It makes no difference if the EQ Low Shelf Filter settings are a big change from flat, or a tiny difference. To induce the bug it’s enough that EQ is enabled and LS is not set to be flat i.e. just an increment of +/- 0.5 dB is enough, and changing the cut off frequency or the Q factor made no difference.

This bug is noticeable with any track that starts quietly, and especially with tracks from CDs that are not mastered to modern high levels.

The Clip does tend to make its own small click on manual track changes and some button presses; I am not confusing this with the bug I describe. On the irivers I get a single click, while on the Clip I get a very unmusical double click.

I’ve attached my H140 config to illustrate that the config is unremarkable and that apart from the EQ it is at default. If anyone needs me to try stuff or make any changes or try a patch that is fine, but I would prefer it to be on an iriver because the Sansa OF database refresh is so annoying.

This is a variant of an the classic Paratroopers.

It lacks the particles, planes and stacking men. Instead of solders, They're just falling bombs.

For more details about the source of inspiration:
http://en.wikipedia.org/wiki/Paratrooper_(video_game)

Problem found in versions r29044-110113 to r29143-110126. I could not test 3.7.1, because it did not recognize my 16 GB Transcend flash card (fixed in above versions).

At the beginning of tracks and during rebuffering of longer tracks there is a short humming sound (like a bumblebee) mixed with a fast sequence of random high frequency tones. The sound differs as a function of data format and content. It is very homogeneous with WAV tracks (only humming) and different with lossy and lossless codecs. The same file encoded with FLAC and AAC leads to different short distortions. It is only audible for tracks with initial silence or very dynamic content, for example classical music with quiet passages or audio books. With sensitive headphones, this can be quite annoying.

The original firmware does not show this behavior!

It only happens while reading from the SD card, not from the internal storage.

Initially I thought this might be a CPU throttling issue. But now I think it might also be related to the controller driver.

There is a thread on Hydrogenaudio with independent confirmations of the issue:

http://www.hydrogenaudio.org/forums/index.php?showtopic=86306

If I can provide any additional information to help, please let me know.

After upgrading from 3.13 to 3.14, when playing most of the ogg vorbis files in my library, a "beeping" sound sporadically occurs.

The sound is random (2 consecutive playbacks of the same track will beep on the same time).

All the files played fine with 3.13.
MP3 files play just fine (I have not tested other formats yet).

Possibly interesting facts :
Vorbis files with a lower bitrate (<100kpbs) seem to be less subject to this beep.
It seems beep never occurs when screen is on.

This patch was meant to add a DJ type feature, that would announce each song if a “.talk” clip exists for it. Unfortunately, it’s not as simple as calling talk_file() each time the track changes, because that breaks playback because of CPU inadequacy. Works mostly fine for WAV files though.

The solution is probably to halt playback until the clip has been played, but that’s beyond me.

I have not added a settings interface to this, since the feature is really very incomplete. I’d love if someone would pick it up from here though.

1. tested devices: Samsung Galaxy Tab 7" and Android 2.3.3 AVD
2. tested revision: custom r30556 and rasher's unmodified r30562

3. condition: goto home screen by pressing 'Home button', then return to rockbox

4. symptom : any action that calls yesno screen(rename, delete, or 'Erase dynamic playlist', etc) will make rockbox unresponsible.
The only thing I can do is go to home screen then kill rockbox service.

5. If I go to home screen from main menu by 'Back button', the problem doesn't occur.

On build 30622 and previous builds, there is an issue with resuming playback.

When "Resume Playback" is selected from the menu, you transition into the music control screen but there is no output aside from some crackling noises.

Occasionally, the song would play for half a second before silencing.

The play/pause button during this situation shows a pause symbol which suggests that the song is supposed to play. However, the song progress bar remains at 0:00.

Currently on Cyanogenmod 7.1 nightly, Android version 2.3.5.

Our tick timer eats CPU even when the app is closed and music is stopped. To fix this, I added a tick_pause() and tick_resume() to kernel-android.c, to be called from java when appropriate.

I've figured out where to call pause, but the current location of resume is inadequate. The app wakes up to a black screen.

A clue, anyone?

I’m using revision 29572 of android port. Host system is Samsung Galaxy 3 i5800, with 240×400 resolution display, with version 2.2 (Froyo) of Android.

The problem is as follows. When trying to start playback of OGG or SPX files, the playback does not start occasionally (the change is maybe less than 20% to have playback). By rewinding randomly it is possible to get it start playback. The same behaviour occurs when starting from bookmarks and from file explorer. The problem occurs with default config file.

Tried with MP3 and had the same problem. The problem may be with other codecs as well but I have not tried it so extensively.

Best

On my newly purchased (but used) Archos Internet Tablet 70 250GB with Android Version 2.2.? (Froyo) I installed the daily build of rasher. Everything works so far, but playback of MP3 (mostly 160 Kbit CBR and ~200 Kbit VBR) pauses briefly every 2 to 3 minutes. I just reformatted the drive, which now has ext3 and that seems to end the pause which I got on FAT32 after ~4 Seconds of every new song, but every 3 minutes or so the playbacks stops for about a second - very annoying. Don't tried other codecs as I don't own any files other than MP3.
I was in the developers menu during one of this pauses, looking at the list of the contributors. The old names fly away to the right, but this was frozen also during this one second timespan - as if the rockbox-process was paused entirely or so.

This patch introduces 2 new activities, one which lists available themes for a specified target and another which lists more details and the option to install the specific theme. Currently this is more a proof-of-concept, as the communication with the theme server is handled by the same API RBUtil uses, which isn't perfect for the intended usage (e.g. offers no possibility to filter by screen size, only uses INI as output format, ..).

(this also includes some minor unrelated changes to the main Rockbox extraction functionality which won't be in the final patch)

TODO:
- make translatable
- better UI
- uninstall/update functionality
- show only themes fit for the displays' resolution
- use different protocol to communicate with theme server to get rid of iniparser dependency (XML, JSON, .. ?)

Android:
The Notification bar which use "Remoteviews" may be not suitable for some ICS Roms (see Attachment).
So I change the Remoteviews to "Notification.setLatestEventInfo" to display the track information.

The patch may have some offsets.

I've hunted this down here is what I found out.

from
http://developer.android.com/reference/android/view/KeyEvent.Callback.html

public abstract boolean onKeyDown (int keyCode, KeyEvent event)
Since: API Level 1

Called when a key down event has occurred. If you return true, you can first call KeyEvent.startTracking() to have the framework track the event through its onKeyUp(int, KeyEvent) and also call your onKeyLongPress(int, KeyEvent) if it occurs.

We need to return true and call KeyEvent.startTracking() from /android/src/org/rockbox/RockboxFramebuffer.java then set the interrupt flag from /firmware/target/hosted/button-android.c and find out what is passed back after a key release and handle that. I may not be a great programmer but this looks like the ticket to removing the BUTTON_REL work around from /firmware/target/hosted/android/app/button-application.c

Amend the sleep timeout behaviour to pause when the timeout matures.

This allows the idle timeout to power off the player if it remains untouched, or the sleep / pause timeout to recycle if the user unpauses before idle timeout kicks in.

This is a 3D maze done in vector graphics. I ported David Leonard’s program, which was done with the curses library. Initially, I wrapped the curses functions he used in order to draw the maze with putsxy().
This code is not used at the moment, as the vector graphics are easily scaled and more pleasing. The only issue I see is with the user map, which may be harder to draw on a smaller screen. I developed this on the iPod Video.

This is my first attempt at an open source project, and is a refresher in C for me. I apologize for style. I have tried to make the code as clear as possible.

This patch implement alternative hold mode, mentioned in FS#10698.
To enter this mode you must:
1) switch hold button to on position(this results in normal hold mode).
2) press menu button.
3) switch hold button to off position
4) release menu button
To leave alternative model:
1) switch hold button to off position
2) press menu button
3)switch hold button to on position
4)release menu button(now you in normal hold mode)

Additionally I implement simple keymap which working only in wps contex:
if hold button off:

 Plus button increase volume

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.

It would be useful to change the configure and voice.pl files in order to allow the user to choose also the Loquendo and ViaVoice TTS

Since FM stations list may require that the FM region is set to a certain value, it would be good if the FM region could be set along with the station list. The patch does just that.

The region is set by putting the line “region:N” into the FMR file (at any line there). N can be one of the values allowed for the fm_region setting.

The patch does not work on the simulators for e200 and h120 (the only two I tried) because, for some reason, the symbol HAVE_RADIO_REGION is not defined for them. Could anybody tell why?

Saving the region along with the station list is not implemented.

This patch adds an option to disable the speed limiting that slows down seeking as you approach the end or beginning of a track.

It defaults to limiting enabled, to maintain compatibility. Personally, I prefer the fast seeking without the limiting.

The manual is not included, I can't compile them still…

By default, whenever you choose the <All Tracks> option from the database menu, the list of results returned defaults to the standard track name format, i.e. “%02d. %s” tracknum title. What I wanted was to be able to define the format that gets applied to the <All Tracks> option, dependent on the current menu level. So for example, if I had browsed to genre→artist→<All Tracks> it would return the list of all tracks for all artists for the given genre and I wanted the track names to be formated with:

       	"%s %s %02d. %s" artist album tracknum title

and then sorted into order, since I already know what genre the tracks are for.

Similarly, if I simply browsed to genre→artist→album→<All Tracks>, it would return the list of all tracks for the selected genre and artist, but I want the track names to be formated with:

"%s %02d. %s" album tracknum title

so when it’s sorted, I get the tracks grouped only by album and tracknumber, since I already know what artist the tracks are for.

This patch attempts to address this issue by allowing users to define custom <All Tracks> formats in the tagnavi_custom.config file. Thus, sort order can be controlled by how you format the track names, just as it works in base Rockbox.

The premise behind the code is that if the <All Tracks> menu option is chosen, Rockbox will look for formats with a certain naming convention defined by concatenating the tag names of the parent menu levels with “.” characters and finally appending an “.All” identifier. So in the first example above where we had browsed to genre→artist→<All Tracks>, Rockbox will look for all formats called:

"genre.artist.All"

and then cycle through them to see if the appropriate clauses defined on the format are met. Similarly, for the second example where we had browsed to genre→artist→album→<All Tracks>, Rockbox will look for the format called:

"genre.artist.album.All"

As in base Rockbox, it will cycle through all applicable formats and apply the first format it comes across that meets all the clauses defined on the format. One minor change I had to make to get the relevant tags loaded for the search results was to add the tags defined in the clauses of all matching format names to the tagcache search, but not add the clauses themselves.

So now, in the tagnavi_custom.config file to illustrate the first example, I have defined 4 formats called “genre.artist.All” to format the final display name based on whether the artist/album tags are actually defined on the mp3’s in the database.

%format “genre.artist.All” “%s - %s - %02d. %s” artist album tracknum title ? artist !~ “<Untagged>” album !~ “<Untagged>” tracknum > “0” %format “genre.artist.All” “%s - %02d. %s” album tracknum title ? album !~ “<Untagged>” tracknum > “0” %format “genre.artist.All” “%s - %02d. %s” artist tracknum title ? artist !~ “<Untagged>” tracknum > “0” %format “genre.artist.All” “%02d. %s” tracknum title ? tracknum > “0”

The downside of this approach is that in order to have this style of functionality for every <All Tracks> menu option, I defined a lot of formats. As such, I had to increase the maximum number of formats from 32 to 96 in order to cope with my formatting schemes. I also increased the maximum number of tag filters from 4 to 8. Now this obviously increases the amount of memory allocated for formats, which will have an impact on available audio buffer size. The attached tagnavi_custom.config file shows the various “All” formats I’ve added and it’s pretty comprehensive in the way it handles missing tags, so technically, if your music library is properly tagged, you should never need all of the formats so you could easily reduce the maximum number of formats.

My principal concern with this patch is in terms of the memory usage of increasing the maximum number of formats and number of tag filters allowed. I’m not aware of a memory profiler for cygwin, but then I hadn’t used cygwin before playing with Rockbox - so any pointers would be helpful.

The second piece of functionality I wanted was in the handling of the “strip” functionality. Base Rockbox has an all or nothing approach; if the global format found for the list of tracks contains a strip modifier, then it applies the strip to ALL track names, even if the subsequent formatting of the track does not contain a strip modifier. I wanted Rockbox to only strip tracknames if a strip modifier was defined on the format that is applied to the track. This patch fixes this problem.

This works fine on my Sansa e280 with a full 8Gb drive and a full 2Gb micro-SD card. It’s formatted close to 1000 tracks with no noticeable difference in processing time, and I’ve not come across any out of memory errors on my e280, but I haven’t tested it on any other mp3 player so I would recommend you test this first using the appropriate simulator.

Note that this patch incorporates the year album patch  FS#8051  as the code is all tied up in the same files.

Rockbox’s file viewer has a global sort setting.

It would be nice to have a default global sort setting, but also persistent per-directory sort settings.

For my use-case, it makes sense for me to sort my podcast directory by date, but I wouldn’t want that to affect my music directories, which should play files sorted by name.
Whenever I wish to play music, I need to go back to the general settings, and change the sort settings. And when I’m done and wish to listen to podcasts, I have to change it again.