This is the first step of being able to use the pictureflow plugin from a database search. The database now indexes the path to the coverimage for each audio file. In the database browser you can select “Cover by...” genre, artist, composer, year or all and will be presented with a list of cover image paths. (Imagine a call to the pictureflow plugin at this stage, so instead of a list of boring paths you get nice and shiny images). After selecting a path it will display the list of files that would be queued when a cover image is picked in the plugin.

Next step is to work out how to safely call the plugin without losing the context and utilise the return value from it to queue the files.

Issues so far are:

- the preferred size of 100×100 is hardcoded (this should be configurable or at least be consistent with the value in the pictureflow
the db update for covers has the same restrictions as the other tags, i.e. it will only detect changed cover art on
the coverflow plugin needs to work while music is playing (or stop playback if needs
since there is no guaranteed relation between album name and image file, the album name can’t be displayed

Build 20399

The database_changelog.txt is corrupted in that the wrong filename is associated with a track, this has happened before (pre v3.0), I had to write ascript to correct it.

Exampe row from log:

artist=”Teach Yourself” album=”Polish Conversation (Disc 3)” genre=”Books & Spoken” title=”Conversation 1: Booking A Hotel In Krakow” filename=”/iPod_Control/Music/Blur/Blur - Blur/14 Essex Dogs.mp3” composer=”<Untagged>” comment=”<Untagged>” albumartist=”Teach Yourself” grouping=”Conversation 1: Booking A Hotel In Krakow” year=”2006” discnumber=”3” tracknumber=”2” bitrate=”71” length=”640824” playcount=”0” rating=”0” playtime=”0” lastplayed=”0” commitid=”12” mtime=”955689818”

This patch decouples playlist editting from the play/stop state. So,
you get the same playlist menu independent of whether rockbox is
playing or stopped (and all the commands do the same things). Also,
editting the playlist while stopped does not restart playback.

The idea behind this is that now the current playlist appears to
the user to be ‘still there’ when stopped (ie you can view it and
resume it), it doesn’t make sense for an insert while stopped to
insert to an empty playlist.

I have done two patches, the first just makes the current playlist
menu available when stopped (no changes to the menu). The only changes
are to onplay.c and most of the changes were deletes, so the new code
is ~30 lines shorter than the original.

The second patch does the same as the first, but also:

1) it renames “Play Next” to “Replace” 2) it adds a “Replace shuffled” command
3) it renames “Insert” to “Insert in order” (and the same for queue)
4) it does not show the “Insert in order” order command until it is

   useful: after an "Insert next" has already been done.

I think these changes make the playlist editing much easier to
understand for people new to rockbox (and easier to remember for those
not so new). In particular, the current “Insert” can do one of 3 different things (add to empty, insert next or insert after previous insert/ insert next). With the second patch all commands always do the same thing, and the renaming makes it a bit clearer what that thing is.

Anyone who wants to test this should probably also install http://www.rockbox.org/tracker/task/7898 - which fixes a bug in the “Insert next” code.

I created the following fonts from DejaVuSans.ttf using ttf2bdf.

I use them as an alternative for unifont, which is fixed-width.

Attached are a screenshot and a tarball with 8 to 12pt versions of the font.
Perhaps they could be included in the official distribution, if others like them.

Tested on r31173:

Deleted tracks are still visible after the automatic database update when the player boots. These tracks vanish as soon as I add some files. It also doesn't seem to matter if the dircache is enabled or not. Manually updating the database from the menu works as intended.

Rockbox version 3.13
Wenn I delete a file being played, it continues to play (which is OK for me). But when I rewind in this file while playing, Rockbox hangs and does not respond to any key presses. The screen light stays on. I have to press the hard reset or wait until the battery is empty.

This also sometimes happens when I press fastforward, but it always happens when pressing rewind.

Desired behavior:
- Preferred: permit rewinding/fastforwarding (and really delete the file only after stopping the replay)
- ignore rewind/fast forward; alternatively
- skip to the next file immediately after deleting.

Thanks for reading, and please contact me if you cannot reproduce this! I have a Iriver H140 and I must say that all my recordings are in wavpack (recordings made using SPDIF-IN), so I do not know whether this also happens with other file formats and with other players.

-Stefan

Steps to reproduce:

1. Start listening to a series of podcasts, say 1-5
2. After listening to >1 plug player into computer during playback of subsequent podcast
3. Delete the podcasts you have already listened to (not what your currently listening to)
4. Eject/Unplug player from computer
5. Attempt to resume playback

This fails for both resume and Recent Bookmarks functionality. I assume this is somehow tied in with playlist support as files from the playlist have been deleted.

Where does Recent Bookmarks keep it's information? Should the bookmark also keep the individual file referenced so it can resume in this case?

Tested on R21184M-090604

Will test on latest version once my main machine is back on internet.

There’re many dictionaries for http://stardict.sourceforge.net/Dictionaries.php as many of them are GPL‘ed I would like to request for converter for those so it’ll be possible to use them with RockboxDictionary

Rockbox versions: all from 3.7 to 3.12

There are really loud and annoying digital squeaks during playback on some tracks only (wma 64-96kbps). Usually the noise occurs when one channel is silent or almost. The problem doesn't occur with the OF. It makes no difference where the song is stored (sd or internal memory). The same tracks play fine on the pc. I attach a portion of a song I've recorded while playing on the device where the noise can be clearly heard.

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 IS a duplicate of  FS#6904 .

My iaudio x5 hangs when changing directories via short+long direction button presses. It switches to the next directory, but no audio plays, and the WPS shows that it stops at 0:02 of the track.

during my research on FS#10883 i found out that it would be better do disable slide actions on ipods for yes no decisons. slides are too easy done and often cause an unwanted abort.

this patch solves this issue by only accepting pressed keys for abort actions. the solution for FS#10883 has been appended on the bug report seperately.

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.

Creative ZEN simulator build 9d0c0e3-170115
Creative ZEN device build 8fec364f6-170125

Steps:

(Using attached config.cfg)

1 Ensure Settings > Playback Settings > Shuffle is No
2 In Files, move to a list of tracks and press Select
3 In Files, move to a different list of tracks and do long Select > Current playlist > Insert
4 View the playlist e.g. http://i.imgur.com/xR0WMQm.png 5 Set Shuffle Yes and then Shuffle No
6 View the playlist

Expected e.g. https://archive.is/41khH#selection-1007.0-1007.44 , https://archive.is/nypDH#selection-1079.0-1092.0:
Playlist order restored.

Observed: Playlist changed, but not restored - http://i.imgur.com/DBW9wSI.png

Video at https://www.youtube.com/watch?v=2_s27g_FwXg

When turning on my Sansa with Rockbox 3.10, the display sometimes goes all white and stays that way until the screensaver kicks in. The player works fine during that time and can be controlled blindly. After the screen turns off and I turn it on again, the screen works as expected. This does not happen all the time, but very often.

On the Official Test Build for the Sansa Fuze, when playing Doom, in middle of playing, Rockbox gives a Data Abort Error. If it doesn't happen in middle of playing, it is always reproducible by entering the second Map. The most recent error i got is "Data Abort at 307B32D4". My Version is "r21704-090707".

It happened once just browsing through the Menu, but is only reproduced every time by playing Doom, which is why I filed it under Doom.

I will try to try a later revision and see if it fixes the bug.

While I am playing some song on my iPod classic 2G, and scrolling through a list (even the main menu, but the glitch there is somehow different), if I unplug and then replug the headphones, some of the WPS UI gets drawn over the current view. I'm attaching a screenshot to make it more clear. It only happens while playing a song.
I'm using build bf6abf7 (most recent at the moment).
Also attaching my config.

The OF ide_power_enable routine sets some GPIO _ENABLE bits to zero when enabling power and sets them to 1 when disabling power. This makes a difference of about 1 in 4066_ISTAT ( FS#9728 ) on my 30 gig iPod, which probably means saving about 0.75 mA. But if 1 is enable, why does enabling pins save power?

This plugin searches in the .rockbox/rocks/apps/drumkit directory for .raw sound files, loads them into memory, and assigns the keys to play them, creating a drumkit /sample trigger / instrument out of the player. Currently only designed for the Sansa e200.

Room for improvement:

- Add keymaps for all
Allow multiple samples to be played at the same time (by using
Allow for a variety of sound file types to be
Find a better name

I don't know whenever it happens with other versions or not, all I got is Sansa Clipv1 to test with.
My configuration is Initialize once and auto update working.

It seems like the database items got duplicated for unknown reason. I seem to have up to 7 entry's of the same item inside the database. I am not sure what causes it, but that is what I've noticed.
[At first I thought it's a shuffle bug 'till I was going to debug it only to find the database is full of clones]

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.

This patch converts LCD_{WIDTH,HEIGHT} into variables, allowing Rockbox to change screen size at runtime.

I’ve tried to make the changes as less intrusive as possible, but still, there will be some binsize increases.

Most of the #if’s were converted to C if()’s which should be functionally equivalent (and if the compiler is smart enough, no increase in binsize should occur).

In order to use this, just define DYNAMIC_LCD_SIZE in your target config and compile without plugins (if the preprocessor spits errors, try clearing ENABLEDPLUGINS in your Makefile).

What still needs to be done:
* figure a way out how to compile several rockbox logos into the binary and choose the correct one at runtime
* do something about the hacks in apps/bitmaps/SOURCES and apps/settings_list.c
* get the Android port working

These experimental patches dynamically add new tracks to the database when they are played. This allows users who (for various reasons [1]) prefer to not fully initialize the database to take advantage of database-based features such as autoresume (remember a resume position for each file), runtime statistics, or track ratings.

The current patch set is only a prototype. It's still somewhat inefficient because it does a full database commit and reload for each new track that is played.

The actual database-extension patch (patch 0002) works by refactoring tagcache_build to create a new interface, tagcache_add_file, that adds a single file to the database. This new function runs in the database thread and takes a dircache_entry pointer, which is provided by way of a Q_UPDATE event. The audio thread generates this event in tagtree_buffer_event when the initial DB lookup fails, and later checks the database again in tagtree_track_finish_event. If the DB commit and reload have succeeded in the meantime, this second lookup will succeed and the runtime information the user is interested in (stats, resume info) can be stored in the DB.

Patch 0001 changes the DB commit's buffer-allocation preference from using the dircache buffer to using the RAM DB's buffer. (This used to be the preference until r10003 reversed it, supposedly because the dircache buffer typically is bigger. I don't know yet how valid this argument is today.) This reversal avoids needlessly flushing and refilling the dircache and makes the Q_UPDATE event-passing mechanism more robust (because in-flight update events contain dircache_entry pointers, which would have to be invalidated when the dircache is flushed – which is not done yet).

Current limitations/caveats:
* Requires dircache and Load-DB-to-RAM enabled (and only works on targets that include these features)
* tagcache_add_file does not respect any database.[un]ignore files in the directory hierarchy above the added new file.
* DB needs to be initialized to begin with. There's no UI function for a basic DB initialization (without scanning and adding all files) yet.
* Not very thoroughly tested (mostly in simulator, with small file sets)

Possible improvements:
* Delay committing DB changes if more track-add events are in the tagcache queue
* Incremental commit: Could be optimized for add-one-track case
* Incremental load_tagcache: Avoid flushing and reloading full database
* Add function to initialize an empty DB

Comments welcome!

Footnote:
[1] Reasons for not using the database, or not keeping it up to date, include: metadata parser instability; prefer not keep tags up to date; prefer file browser over database browser

Since r30937, the e200v2 bootloader is too large and mkamsboot errors with:

[ERR] Packed data (120926 bytes) doesn't fit in the firmware (120860 bytes)

Steps to reproduce:
1. build e200v2 bootloader
2. cd to rbutil/mkamsboot
3. run make to create the mkamsboot utility
4. run mkamsboot <path-to-e200pa.bin> <path-to-bootloader-e200v2.sansa> <path-to-output.bin>

This is a beginning of support for line out and dock connection detection for the e200v2 (and possibly fuze).

The first patch enables line out in as3514.c. Line out is always enabled at this point, so battery life may suffer. Line out volume is set to 0dB and does not change unless the volume is set below -40dB at which point the DAC volume begins to decrease. This patch does not support as3525v2 at this time.

The second patch detects a connection to a dock on e200v2 (and possibly Fuze) and prevents switching to USB mode and rebooting to the OF. For this to work properly, you need to have Rockbox already booted. There is no need to press any button on connection. If a normal USB cable is attached, the OF will be booted.

TODO:
1. Only enable line out when connected to a dock and disable line out when the dock is disconnected.
2. Provide support for additional as3525 and as3525v2 devices. Information on IO port changes when connecting a dock is needed for this.

This bug already stands for a while and was reported in IRC but since nothing happened so far, I’m going to report it here.

On targets with early USB (”usual” looking USB screen when plugging from off-state and probably only hardware bridge USB) the statusbar that should be there in the screen is missing and when you disconnect the player so that the “rest” of Rockbox would start, it crashes.

The address where the crash happens with the build currently flashed to my Ondio is in “lib/libskin_parser.a(skin_parser.o)” - more exactly “9035954: 8b fb bf 903594e <_skin_parse+0×152>”. I pastebinned the complete disassembly of the _skin_parse function here: http://pastebin.com/LZMNW96a .

I will also try to find the exact revision that introduced the bug but that’ll take a while. If I remember correctly it came with some statusbar skinning commit which is already a while ago now and crept up twice in a row (first was fixed, then it came back). Plus it is not the easiest and no quick task testing flashed builds on the Ondio….

Hello,

empty menu items crash rockbox due to NULL pointer access.
Easily reproducable with the "LCD settings" in RaaA / SDL app build.

The resulting valgrind trace looks like this:
==22619== Invalid read of size 4
==22619== at 0x407FDA: do_menu (menu.c:555)
==22619== by 0x41B198: miscscrn (root_menu.c:323)
==22619== by 0x41B377: load_screen (root_menu.c:520)
==22619== by 0x41B72A: root_menu (root_menu.c:688)
==22619== by 0x406DFA: main (main.c:196)
==22619== Address 0x0 is not stack'd, malloc'd or (recently) free'd

Question:
Should we protect against "menu→submenus" being NULL or
should the menu system hide empty menus without any items at all?

Cheers,
Thomas

Emuriver is an emulator (not simulator) for iriver ifp-7xx series. It’s part of the http://www.rockbox.org/wiki/IriverIfpPort and has until now been hosted at the main author’s (Tomek’s) site http://www.mimuw.edu.pl/~tmal/rockbox/ It includes a tool to create flash images for use with the emulator, and a tool to mount such images and do basic file management on them.

This version is almost identical to the last version from Tomek’s site, but I had to fix a few bugs to make it usable on my system. Changes are as follows:

flashimgtool.c: Outputs usage information on errors. (I didn’t do this; I don’t know where this code came from but it’s useful.)

hardware.c: Bug: Arguments were missing in a function call which would sometimes cause segmentation faults, and (I don’t know why or how) slow down the emulator.

main.c: Changed a default file name from prog_flash.bin to prog_flash.img (I didn’t do this)

main.c: Bug: Added explicit return value to nonvoid function. The implicit return value was sometimes -1 which indicated an error so emuriver aborted.

make_flash_img.c: Optimizations: “if” replaced with “else if”. (I didn’t do this)

uicurses.c: Rename a variable into someting more unique. (I didn’t do this)

The reason I’m submitting this patch is that I think the emulator could be useful as it is for those trying to build the ifp port from SVN, that it could (maybe) be worked on to support other players, and that my bugfixes should be included for those building emuriver.

There are a few issues: The flashimgtool subdir in emuriver duplicates a few (three years old) files from RB, disk.c, fat.c, and some more. You might not like the directory structure. It uses an ancient version of autotools. I haven’t been able to create flash images that actually work with flashimgtool. I haven’t built the RB port for ifp yet, so I don’t know if it will run in emuriver or not.

Yes I have discussed the patch in IRC.

This patch puts the pacbox emulator onto the cop, leaving the main cpu for audio codec. The COP behaviour is controller by a #define in pacbox.h

If PACBOX_ON_COP is defined, then all iram usage is also turned off, to prevent interference with audio thread.

Additionally, this patch adds an Audio menu (using the playback_control library), which is enabled for all PACBOX_ON_COP and GIGABEAT F-Series builds.

Patch from directly within the apps/plugins/pacbox directory.

Adds “Binary Skip” to the skip length menu,

This allows navigation by means of binary search within a track.

If no search key is pressed for 5 seconds, the current binary search is considered as having “finished” and pressing a search key subsequently initiates a new binary search.

Changing “Enable EQ” setting does nothing until the player is restarted. However, selecting an EQ preset does enable the EQ and take affect within a few seconds. With the new 3.13 presets I am working around this issue by simply selecting the “Flat” EQ config file to “Turn Off” the EQ. I have tried stopping playback and skipping around to other tracks forcing the buffer to refill. That doesn’t work.

I don’t know when the bug was introduced except that testing 3.11 on my Gigabeat F proved it WAS NOT present in 3.11.

I have verified the bug in 3.13 on all of these targets, so at this time I’m saying this affects all players.

Confirmed on Fuze v2, Clip v1, Clip +, Clip Zip, Gigabeat F

This patch is a continuation of FS#9879 and includes it (but adds something more). It adds the possibility to switch the lamp on and off without leaving the plugin.

Key mappings were taken from FS#8934.

EQ settings changed via Touchscreen WPS action setting_inc & setting_dec are not reflected in the sound output of the device even though they display having been changed in the menus. The changes are also not written to the main config file on disk so they do not "stick" after Rockbox has been rebooted.

example syntax to toggle EQ on/off (display DOES get toggled):
%T(148,520,54,46,setting_dec,eq enabled)
%T(148,520,54,46,&setting_inc,eq enabled)
%xl(E,eq.bmp,0,0)
%V(148,520,54,46,-)
%?St(eq enabled)<%xd(E)|>

I'm not sure if this problem is specific to Android or if the problem applies to all targets.
APK Build: Feb 4, 2011

The (software-)equalizer is adding high noises to the playback.

I made a recording, the first part with eq enabled the second one with disabled equalizer.

I could also make a test on my older H110, on which I never used the sw-eq though.

Current developer build (2012-06-10), on Sansa Clip Zip
While audio is playing, connecting USB and disconnecting it again causes a splash with message “Error accessing playlist control file”. Sometimes followed by a hard crash (like undefined instruction).

Initial analysis shows that the problem occurs in playlist.c:get_filename. An lseek in the playlist control file fails. This lseek fails because the file descriptor (fd) was closed during USB connection. On receiving a SYS_USB_CONNECTED event in apps/misc.c, function system_flush() calls playlist_shutdown().
So the playlist subsystem seems to have been de-initialised during USB connect, but not completely, causing problems when the playlist subsystem resumes during USB disconnect.

This is reproducible on the simulator.

There is something wrong on my iPod Video 5.5 with ROCKBOX 3.9.1. Because I change my ipod's HDD to Samsung's 32G ssd as my rigid disk, I can not enter my rockbox system.
Rockbox boot
leader version v 4.0
ipod version )x000B0011
ATA-82
partition 1 : 0x0B 15598843 sectors
loading Rockbox … Error!
can t load rockbox, ipod:
file not found

Is there something wrong with my new SSD? Or it is just a bug with rockbox which can not support my SSD

EXTM3U is a format based on the standard m3u format. It adds a comment line before filename in .m3u or .m3u8 file in the format of
#EXTINF:xxx,yyy
where xxx is track length in seconds, yyy is the title.

For more info, see: http://hanna.pyxidis.org/tech/m3u.html

Supporting EXTM3U format has several potential benefits:
1. Instead of displaying filenames, track title and length can easily be viewed when viewing playlist (currently I think there is a patch that does it by opening each file).
2. Length of playlist can be readily calculated by summing, which can have some interesting applications such as finding how much time is left in current playlist. (Currently this is not possible yet with this patch, but I’m still thinking of possible solutions).

Of course, you have to have playlists in EXTM3U format to get the benefits. There are widely available tools to generate EXTM3U or add information to existing normal m3u playlists. In the future I might add functionality to Rockbox to save EXTM3U playlists (only if database is enabled and ready) or a plugin.

The current patch is able to parse EXTM3U information and use it in playlist viewer. To see it work, you have to set your track display option in the playlist menu to display EXTM3U information; otherwise, filename will be displayed. Two display options are added: title only and title plus track length.

This patch should have very minimal impact on normal playlist usage. A parse function and a few booleans values to existing structures are added, but the parsed title and filename share the same buffer (since they won’t be displayed at the same time). Specifically, beside a quick initial reading of header to determine if a playlist is EXTM3U and a few boolean checks, current playlist parsing/viewing routines are not changed if playlist is not EXTM3U or EXTM3U information is not needed for display.

Enough of me babbling :D Here is the patch. I did some limited testing, so it probably is not foul-proof yet.

When utilizing the database on the iPod Photo (as well as other 4G iPods I have used), on occasion when entering a directory or going to the parent directory, any button on the iPod will need to be pressed before the others will have effect. I.E. before I can scroll to select a song, I must press Select or one of the other wheel buttons. It is severely annoying, in part because it is too sporadic to even be assumed to be a “feature”.

When I try to build rockbox, I get the following error:

=⇒ make: execvp: /bin/sh: Argument list too long
⇐=

My build path is a fairly long path. Building it at a location with shorter path it works. Details:

Steps to reproduce:

* Create a location where you want to have the sources; use a fairly long path name, e.g.

  mkdir -p /home/myuser/download/mediaplayer_hardware/SanDisk/Sansa_Fuze_v2/rockbox/firmware/source/

* Change to that directory:

  cd /home/myuser/download/mediaplayer_hardware/SanDisk/Sansa_Fuze_v2/rockbox/firmware/source/

* Download git sources (Tried with version from 2014-09-22, 10:55:11 GMT+1, Commit by "Marcin Bukat marcin.bukat@gmail.com", Change-Id: "Ie3aa9b208e3f4f17d4d02f11f69839e9b381217d") to a long path:

  git clone git://git.rockbox.org/rockbox 

* Make a build directory and change into it:

  mkdir -p /home/myuser/download/mediaplayer_hardware/SanDisk/Sansa_Fuze_v2/rockbox/firmware/source/build_FuzeV2
  cd /home/myuser/download/mediaplayer_hardware/SanDisk/Sansa_Fuze_v2/rockbox/firmware/source/build_FuzeV2

* Configure the build:

  ../rockbox/tools/configure --target=63 --type=N

prodces the output

==>

Using temporary directory /tmp
Platform set to sansafuzev2
Normal build selected
Using source code root directory: /home/myuser/download/mediaplayer_hardware/SanDisk/Sansa_Fuze_v2/rockbox/firmware/source/rockbox
Using arm-elf-eabi-gcc 4.4.4 (404)
Using arm-elf-eabi-ld 2.20.1.20100303
Found and uses ccache (/sbin/ccache)
Automatically selected arch: arm (ver 5)
Created Makefile

<==

* Running "make":

  make

produces the output

==>

Generating dependencies
make: execvp: /bin/sh: Argument list too long
make: *** No rule to make target '/home/myuser/download/mediaplayer_hardware/SanDisk/Sansa_Fuze_v2/rockbox/firmware/source/build_FuzeV2/make.dep', needed by 'all'. Stop.

<==

and returns with exit code 2.

Workaround:

Building it in a directory with shorter path, e.g. doing everything in "/tmp", works.

But that is only a workaround; it should not fail when building in arbitrary locations, and especially not with a message not making it clear _what_ the underlying problem ist. (I had to do a long internet search to get to the idea that the build place can be the problem).

to reproduce:

1. set playback settings–>fade on stop/pause to on.
2. play some music.
3. press the pause button to stop the music, and again to restart it. repeat that a few times, because this bug does not always occur.

you will notice that both “time-displays” sometimes change very to the previous second and then back to the normal one, e.g 3:32, then very short 3:31, and back to 3:32. the progressbar sometimes get smaller for a fraction of a second, too.

maybe i’ll search for the revision which introduced this in the next few days

I noticed that when filling the buffer my Video iPod (32MB RAM) does noticeable seeks at semi-regular intervals even if reading from a single non-fragmented file. It seems this is due to having to read the next FAT sector. In firmware/drivers/fat.c there is a FAT cache but no read-ahead of the FAT.

I created fat_preload( struct fat_file *file, long sectorcount ) in firmware/drivers/fat.c to preload the FAT cache. In firmware/common/file.c I created file_preloadfat(int fd, size_t count) because calling a fat_ function directly would be too much of a kludge. I use file_preloadfat in apps/buffering.c just before filling the buffer.

This got rid of that regular seeking and it seems to it can remove about two seconds from the time needed to fill the buffer when reading a single non-fragmented file. Currently the code is quite simple and unintelligent. Fragmentation or other activity can overwrite the pre-loaded FAT sectors in the cache, and in such cases the pre-load leads to needless extra reads. More work is probably needed before this can be included in Rockbox.

Currently this patch is for SW-codec only. I think file_preloadfat could be called from HW-codec buffering code also, though few seeks would be prevented with 2MB of RAM. This patch is also probably useless with flash storage.

3.7.1, r29372, tested on Sansa e270

The idea is that when connected via USB, devices with button/wheel lights will indicate disk activity using the light, similar to a USB flash drive.

This works, sort of.
One real problem has been encountered:
The calls to buttonlight_on() and _off() seem to override the backlight_timeout_plugged setting, preventing the backlight from shutting off when this is enabled.

Initial support for showing input in the fft plugin. Now, on targets supporting recording, instead of quiting when no track is playing, fft starts monitoring the audio input (using the settings under Recording Settings).

The first patch is just the functional changes, the second patch fixes the indentation of the entire file.

I’m not sure if it works at all since I don’t have a device that can record.

build 00a3658. files dont list or play alphabetically regardless of setting in file view menu.

Various users on IRC recently reported cases of filesystem corruption. I have seen them as well, especially when using USB mode (I'm using a Sansa ClipV2, USB-enabled through  FS#11664 ).

One strangeness I've experienced is that when my system has detected filesystem corruption, it is often enough to remove the player from USB and then replug it, without repairing the filesystem and without rebooting Rockbox; on the next USB mount, the filesystem is clean. This might indicate that some buffer is flushed too late for the USB host to see.

[EDIT: Removed previously attached patch, which is now tracked separately as FS#11883.]

FingersOfRock is a DDR variant where by arrows pass over the screen, and the player must press the corresponding buttons in time.

I don’t know how to use the cpu boost, so if someone has some time, please boost when the game begins and un-boost when it finishes.

It is called FingersOfRock from: FretsOfFire and rockbox.

For more details on the source of inspiration:
http://en.wikipedia.org/wiki/Dance_Dance_Revolution

This was reported in the past as part of another bug (FS #6707), and although the other one hasn’t happened anymore, this one still does.

Happens only from time to time. Scenario:

- player is playing song (in WPS), backlight off
- press stop
- only backlight goes on, playback continues

I attach this to H300 series but this may not be player specific

The attached patch fixes a minor compiler warning on 64 bit platforms.

Hi all,

Currently for all models, the Morse Code input method can only type lowercased letters. Here I provide a patch which enables people to switch between lower cased and upper cased letters, I implemented this for Fuze and Fuze v2, and further fixes will be provided soon (or someone else want to add some key mapping options into your keymaps?)

The patch (also attached):

Index: apps/action.h

   ACTION_KBD_DOWN,
   ACTION_KBD_MORSE_INPUT,
   ACTION_KBD_MORSE_SELECT,

   /* the following are helper actions for touchscreen targets,

   "abcdefghijklmnopqrstuvwxyz1234567890,.?-@ ";

                       state.morse_code |= 0x01;
               }
               break;

           case ACTION_KBD_SELECT:

                   /* turn off hangul input */
                   state.hangul = false;

               }

               break;

           int morse_code;

           outline[0] = morse_alphabets[i];

           sc->putsxy(x, y, outline);

           morse_code = morse_codes[i];

   { ACTION_KBD_DONE,         BUTTON_UP,                        BUTTON_NONE },
   { ACTION_KBD_ABORT,        BUTTON_HOME|BUTTON_REPEAT,        BUTTON_NONE },
   { ACTION_KBD_MORSE_SELECT, BUTTON_SELECT|BUTTON_REL,         BUTTON_NONE },

   LAST_ITEM_IN_LIST

The patch fix the multiple-language feature, maintaining the same behaviour in interactive and batch mode and with “make reconf”. Now it’s possible to build more than one voice language at once, specifying different engine and option set for each one.
So, running “make voice”, all the selected languages will be built.

To help the comprehension, here it is a batch mode sample:

../tools/configure –target=ipodvideo –ram=64 –type=av –language=italiano,espanol –tts=f,e –voice=lp_diphone –ttsopts=, –encopts=’-q 10 -c 10,-q 5 -c 5’

This is like to run:

../tools/configure –target=ipodvideo –ram=64 –type=av –language=italiano –tts=f –voice=lp_diphone –ttsopts=’ ' –encopts=’-q 10 -c 10’

../tools/configure –target=ipodvideo –ram=64 –type=av –language=espanol –tts=e –voice=lp_diphone –ttsopts=’ ' –encopts=’-q 5 -c 5’

In the first case, I set the language to italian, using festival with voice lp_diphone (female), no further festival options and some manual encoder options.
In the second case, I set the language to spanish, using espeak. Even if I set the voice, the value is ignored, since the selected TTS engine doesn’t use it.

I also added some cosmetics, like some very circumstantial indentation, blank check in rootdir too, simpler numbered menu generation, some terser command pipes.

The patch is applied to r22250.

I don’t know if it’s a really wanted feature, but the word in the script hurt me!