All Projects

The action has been setted correctly in the keymap file.
FM_RECORD is defined for the fuzeplus in the apps/radio/radio.c file

I tried to take out all side reference to another context at the end of the radio section in the keymaps file to see if it was not a context messing up that was blocking the keymaps. Still no luck

I’ve been having this bug for over mouths and mouths without being able to square it clearly (i.e. even before the new radio implementation).
Way to reproduce:
- Lock the device in WPS while playing music
- put your finger on the touchpad and let it there for more than 6 sec.
- the music stop playing, player seems to be frozen.
- press the lock key or hard volume’s keys: player won’t unlock but will let playback continue and will then act as normal (i.e. second press unlock the device)

A very rare issue but confirmed by at least 3 different users:
The clock get resetted “by itself” to some default value (12:00 if I remember correctly) Setting a new time works but the clock get resetted again upon each reboot.
Booting into original firmware and setting the time there solves the issue.

While compiling Rockbox Utility ones get the following error:
base/system.cpp: In static member function ‘static QMap<unsigned int, QString> System::listUsbDevices()’:
base/system.cpp:249:9: warning: variable ‘res’ set but not used [-Wunused-but-set-variable]
base/system.cpp:250:13: warning: variable ‘count’ set but not used [-Wunused-but-set-variable]

count and res are just used to take the return values of libusb_init() and libusb_get_device_list but do not get used later…

the following patch let those fonction being called without saving their return value in any variable.

this is a try for a PLA integration of lamp.
The purpose is to simplify manual and code keymaps

note:
- ONDAVX747(poorly) and MROBE500 added to PLA
- IAUDIO67 PLA keymaps corrected (2 command were mapped to the same keys)
- exit lamp mapped to PLA_EXIT and PLA_CANCEL

Now that rockbox utility handle mkimxboot, fuze+ should be added to the list of target being handled. This patch update builds.pm on this purpose.
I think the status of the port allow us to send it directly into the unstable target.

Extract of snake plugin (yes the first simple one):
\opt{RECORDER_PAD,IAUDIO_X5_PAD,ONDIO_PAD,IRIVER_H100_PAD,IRIVER_H300_PAD%

    ,SANSA_E200_PAD,SANSA_C200_PAD,GIGABEAT_PAD,GIGABEAT_S_PAD,MROBE100_PAD%
    ,SANSA_FUZE_PAD,PBELL_VIBE500_PAD}
    {\ButtonUp/\ButtonDown}

….

     \opt{HAVEREMOTEKEYMAP}{& }
   & Change levels (1 is slowest, 9 is fastest)\\

I don't see anything like that in the plugins code… shouldn't we remove this?

1) Way to reproduce:
- download and install lebellium Samsung-like Theme.
- select lebellium Samsung-like Theme frome theme from within the setting menu
- once loaded plug the device with usb

2) Bug description
on usb connexion this theme crash rockbox:
- corruption appears on the screen usually it is in the lower part of the screen where ./rockbox/wps/lebellium Samsung-like/hide-background.bmp is to be displayed.
- only hard reboot to get out of that state

- Sometime the following panic screen is displayed instead of corruption
Prefecht abort
at FFFFFB44
FSR 0x1
(domain 0, fault 1)

- Sometime the usb storage doesn't start on usb (only hid). In such case the player won't crash, and work as expected once disconnected

3) Workaround: deleting the file ./rockbox/wps/lebellium Samsung-like/hide-background.bmp
solve the issue (and then the thème is ugly)

4) Already tested:
- change bmp format to whatever the gimp allow no luck

5) Target tested:
- as been seen on Fuze+ (240x320), it would be nice to have it tested on gigabeat-s.
- do not seems to occurs on some other screen size device

from bubbles.c:
#define BUBBLES_QUIT1 PLA_EXIT
#define BUBBLES_QUIT2 PLA_CANCEL

(both command are identical, I checked)

from bubbles.tex:
\PluginCancel

     \opt{HAVEREMOTEKEYMAP}{& \PluginRCCancel}
      & Exit to menu\\
  \end{btnmap}

so \pluginExit is missing in the table

\note{You can control whether or not Rockbox includes the contents of

subdirectories when adding an entire directory to a playlist. Set the
\setting{Settings $\rightarrow$ General Settings $\rightarrow$ Playlist
$\rightarrow$ Recursively Insert Directories} setting to \setting{Yes} if
you would like Rockbox to include tracks in subdirectories as well as tracks
in the currently-selected directory.\\}

…

\subsection{Helpful Hints}

\subsubsection{Including subdirectories in playlists}
You can control whether or not Rockbox includes the contents of
subdirectories when adding an entire directory to a playlists.
Set the \setting{Main Menu $\rightarrow$ Settings $\rightarrow$ General Settings
$\rightarrow$ Playlists $\rightarrow$ Recursively Insert Directories}
setting to \setting{On} if you would like to include tracks in subdirectories
as well as tracks in the currently selected directory.

"\note{When the cursor is on the input line, \ActionKbdSelect{} deletes the preceding character}"

you mean:

"\note{When the cursor is on the input line, \ActionKbdBackSpace{} deletes the preceding character}"

Don't you?

PLEASE DON’T HATE ME :)

Someone ask me about this. I’m aware such a hack as about 1.2% chance to end up in the tree.
Anyway if they’re are some ‘do it right’ that could help to have it in tree: please feel free to elaborate.

I’m starting to write fuze+’s manual
for the moment only the image files (png and pdf) should be uploaded to the server, as they cannot be diffed and are ready however
the patch is given as a sources to comment/helps untill it is fully ready.

1. Way to reproduce:
The bug appears randomly but always stay a while once appeared. It cannot be reproduced systemically. But always appears at the end. It has been reported by three different fuze+'s user so far.

2. Description
The files won't be played but skipped until the playlist reach its end.

3. Workaround
- Desactiving directory cache (settings > system > Disk) always get rid of it. Reactiving bring the bug back.
- Reinitialize the database (wether there is no DB or an already present up-to-date one). But the player will then be back on non-playing behaviour after reboot.

1. Way to reproduce:
While playing any file except mp3 select a MP3 file

2. Bug description
WPS stay idle a couple of second on the new file without playing it (detection of the format correctly being showed) then:

Undefined instruction at 0000AC44
backtrace start
pc: 0x0000AC44
sp: 0×00005350 backtrace end

find_addr.pl returns:
jean-louis@debian:~/Bureau/rockbox-devtree/rockbox/buidl$ ../utils/analysis/find_addr.pl 0x0000AC44 1
/home/jean-louis/Bureau/rockbox-devtree/rockbox/buidl/firmware/libfirmware.a(thread.o) → threads

jean-louis@debian:~/Bureau/rockbox-devtree/rockbox/buidl$ ../utils/analysis/find_addr.pl 0×00005350 1
/home/jean-louis/Bureau/rockbox-devtree/rockbox/buidl/apps/codec_thread.o →

Whatever the format of the “coming from” file is, the address in backtrace stay the same.

3. No bug if:
- If the files are in the same playlist, the bug doesn’t occurs - only on moving to a new dynamic playlist.

4. test performed:
tested format:
WMA > MP3 bug
MPC > MP3 bug
OGG > MP3 bug
FLAC > MP3 bug

MP3 > OGG no bug
WMA > OGG no bug
FLAC > OGG no bug

each format transition tested 2 times with 4 different files

This is probably related to the sansa fuze+ port rather than to the codec… I'm reported this one separatly from  FS#12429  for it is very easy to reproduce on the device.
It occurs everytime the player has to goes from reading mp3 file to reading flac file. This does not involve generating dynamic playlist for even skipping from file A to B inside a predefined playlist will cause it. The reverse isn't true: from flac to mp3 doesn't crash the player.

Undefined instruction at 63E5C2A0
backtrace start

  pc: 0x63E5C2A0
  sp: 0x00005390

backtrace end

jean-louis@debian:~/Bureau/rockbox-devtree/rockbox/buidl$ ../utils/analysis/find_addr.pl 0x63E5C2A0 1
This address is in codec space, please select the codec which was used with this address:
[1]: ay.elf
[2]: a52_rm.elf
… [35]: flac.elf
….

Selection: 35
/home/jean-louis/Bureau/rockbox-devtree/rockbox/buidl/apps/codecs/flac.elf → decoded0

Several problem occurs with those format on Fuze+’s port. The problem has been identified as player specific as it doesn’t occurs on clip+ and has been seen on 2 differents Fuze+ unit.

The problem are quite random which lead to difficulties to track them down precisely. Nevertheless, 3 differents phases can be observe regarding the behaviour of the fuze+ and mpc files:

- Normal behaviour (files can be selected, play, playlist also play without problem)
- Non-playing behauviour (files are skipped one after the other till the end of the dynamic play list) – Nothing consistent was found on how to go from normal into non-playing behaviour or reverse.
- Buggy behaviour (you can actually play and skip between files but after playing one file, the player will just hang stucked or go into panic at the moment to load the next one:
Two different value set were observed for now (backtrace remains the same):
Data abort at 63E57B28
FSR 0×8 (domain 0, fault 8)
address 0×64000000 backtrace start
A: 0x63E56AE8
A: 0x60040D28
A: 0x6003D87C
A: 0x6003DB50
backtrace end

or:

Data abort at 63E57B24
FSR 0×8 (domain 0, fault 8)
address 0×64000001 backtrace start
A: 0x63E56AE8
A: 0x60040D28
A: 0x6003D87C
A: 0x6003DB50
backtrace end

Several tests were made so far to establish that:

1) The problem is not files specific as normal behaviour and non-playing and buggy behaviour occurs on the same sets of files. Differents tag coding and even wiping all the tag away didn’t help either.

2) The problem is not related to database as not building it and/or erasing all DB files doesn’t wipe out the buggy behaviour.

3) The problem ist not be related to specific settings or if so, it is related to defaut settings. Recompiling, reinstalling rockbox from scratch doesn’t solve the buggy behaviour

4) Nothing consistent was found about how the player goes from normal to non-playing or reverse. However some consistent (systematical) way to go from non-playing to buggy phase was found:
- Reinitialize the database (wether if there are no DB or an already present up-to-date one). But the player will then be back on non-playing phases after reboot.
- Playing a big directory with a lot of files after skipping 20 to 50 of then the player will eventually start playing one of then (a random one nothing consistent here to)
- desactivating the directory’s cache option (settings > system > disk) this way is the only way to remains even after reboot.

5) the backtrace of panic occuring in buggy behaviour was given into the ./utils/analisys/find_address.pl tool with the following result:
https://gist.github.com/1434466

6) Flac format as been seen with the same non-playing behviour. But buggy phases gave no backtrace:
Data abort at 63E71120
FSR 0×1 (domain 0, fault 1)
address 0x00004D6B

Could someone checks that I did no blasphemy and commit it?

So I will try to implement that… but I’m really beginning with C++

The file is huge, I used it only for testing purpose on the new fuze+ port.
But indeed it doesn’t work. See attached little cut of the file.
The screen seems to show that the file get correctly recognized (at least for the bpps) then immediately closed

diff file from rockbox translation for french