All Projects

The latest build shows "Divide by zero at 30065EF0" immediately after boot.

—— the problematic build:
Target: sansaclipplus
Target id: 66
Target define: -DSANSA_CLIPPLUS
Memory: 8
CPU: arm
Manufacturer: as3525
Version: r29664-110331
Binary: rockbox.sansa
Binary size: 506040
Actual size: 506032
RAM usage: 753652
Features: alarm:crossfade:dircache:flash_storage:lcd_bitmap:lcd_invert:pitchscreen:multivolume:quickscreen:radio:recording:recording_swcodec:recording_mic:rtc:swcodec:tagcache:tc_ramcache:charging:large_plugin_buffer:ab_repeat_buttons:lcd_flip:lcd_contrast:usb_power
gcc: arm-elf-eabi-gcc (GCC) 4.4.4
ld: GNU ar (GNU Binutils) 2.20.1.20100303
Host gcc: gcc (Debian 4.3.2-1.1) 4.3.2
Host system: Linux

The latest daily build works.
—— the working daily build:
Target: sansaclipplus
Target id: 66
Target define: -DSANSA_CLIPPLUS
Memory: 8
CPU: arm
Manufacturer: as3525
Version: r29662-110330
Binary: rockbox.sansa
Binary size: 506032
Actual size: 506024
RAM usage: 753652
Features: alarm:crossfade:dircache:flash_storage:lcd_bitmap:lcd_invert:pitchscreen:multivolume:quickscreen:radio:recording:recording_swcodec:recording_mic:rtc:swcodec:tagcache:tc_ramcache:charging:large_plugin_buffer:ab_repeat_buttons:lcd_flip:lcd_contrast:usb_power
gcc: arm-elf-eabi-gcc (GCC) 4.4.4
ld: GNU ar (GNU Binutils) 2.20.1.20100303
Host gcc: gcc (GCC) 4.4.4 20100630 (Red Hat 4.4.4-10)
Host system: Linux

So there are only 2 commits to check: r29664 and r29663. I guess r29664 is more suspicious.

The build r29613-110318 on Sansa Clip+ causes freeze in these situations:
- playback approaches end of a track (maybe buffering of the next track problem)
- playback is stopped

When frozen the player does not react to button presses. Only pressing the power button for several seconds turns off the player.

With a 24 hour older build I did not observe this problem.

First observed on r28078-100914
Last checked just now on r28092-100916

Right after start Rockbox shows WPS backdrop in menu (even if WPS was not shown yet).
Loading a different theme or clearing backdrop solves the problem.
After restart the problem appears again.

Observed on H120. Tested with cleared settings.
The latest daily build where the problem does not appear is r28070-100913 so the problem was probably introduced by one of the Jonathan Gordon’s commits r28073 - r28075 modifying the skin engine.

A fraction of second after displaying WPS (by resuming playback or running a new one) or radio WPS Rockbox freezes and is completely unresponsive.
It looks like the whole WPS is drawn correctly and with radio WPS also FM radio starts playing. Only on WPS the freeze occurs before album art is displayed.

The problem was tested and observed on H120 with settings cleared on the daily build r27622-100729 and the latest build r27627-100730. I tested multiple audio file types with multiple bitrates in the WPS.

The oldest daily build where the problem could be observed is: r27622-100729
The newest daily build where the problem does not occur is: r27607-100728

After looking at the changed files I think that the problem could be introduced by one of these commits:
r27613
r27614
r27616

With the latest builds I observe panic immediately after starting Rockbox kernel from the bootloader. The bootloader writes approximately:

… checksum … result 0

then the screen clears and Rockbox immediately writes (two different results for two builds tested):
— build r24571-000208
I04:IllInstr
at 31057FE8
— — build r24568-100208
I04:IllInstr
at 31057FE4
— Then it normally reacts to pressing PLAY by rebooting.

The latest known working build is the daily build r24556-100207. The problem happens on iriver H120.

PS: Notice the wrong year in the build number: build r24571-000208

The patch in  FS#10951  - Complete Czech language update was encoded in Windows-1250 character set, not in ISO-8859-1 as Michael Chicoine interpreted and commited it.
The commit http://svn.rockbox.org/viewvc.cgi?view=rev;revision=24450 is wrong.

Here is the same patch and complete file recoded to UTF-8 and LF line endings. Unfortunately I do not have a diff at my hand to quickly create a new patch aplicable to the latest revision.

While being in WPS I encountered the following panic message on the build r23008-091008 on my iriver H120:

I1E+Level6
at 3104B17E

Unfortunately it was very difficult to be read and even I could not be sure about some characters as the text was written over the WPS background! If the area of the message would be black in the WPS background I would not see anything of the message.

I think that Rockbox should not write the panic text with “transparent background” but it should instead print a contrast background around the text.

Yesterday I installed the build r23008-091008 on my iriver H120 and I encountered a panic state with it.

Everything was going well. I played some MP3s and FLACs.
Then during playing FLAC files I was changing the Dynamic Compressor parameters. Later still during playback I pressed and hold the STOP button to shut the player down but the player ended in a panic state writing the following to the screen:

I1E+Level6
at 3104B17E

I am not sure about the exact “reading” of the characters because they were written directly over the WPS background! Especially I am not sure about the “I” and “+”.

The panic seemed to be handled correctly as the player successfully rebooted after pressing the PLAY button.

It seems that the problem depends on multiple conditions. I was not able to reproduce it yet. I will attach my config file if needed.

I have found four files which play fine in fooobar2000 and Windows Media Player but do not play in the current Rockbox (Version: r13990-070726, hardware: H120). When trying to play any of the files Rockbox shows the correct tags in the WPS (but the track number is often nonsensical like -1). It shows play time 0:00 and then it freezes the whole Rockbox.

Information about the files was extracted using foobar2000. I lost the original location of the last two files but I can upload them somewhere.

http://www.sound-emotion.com/sound-emotioncom/wmamusic/beyonthepain907z.wma

Duration: 1:11.284 (3143624 samples)
Sample Rate: 44100 Hz
Channels: 2
Bitrate: 33 kbps
Codec: WMA
Codec Profile: WMA V2
Encoding: lossy

http://www.sound-emotion.com/sound-emotioncom/wmamusic/baroqueloop90z.wma

Duration: 0:26.516 (1169356 samples)
Sample Rate: 44100 Hz
Channels: 1
Bitrate: 33 kbps
Codec: WMA
Codec Profile: WMA V2
Encoding: lossy

iamthecamerarange.wma

Duration: 2:48.412 (5389184 samples)
Sample Rate: 32000 Hz
Channels: 2
Bitrate: 33 kbps
Codec: WMA
Codec Profile: WMA V2
Encoding: lossy

pickmeuprange.wma

Duration: 0:54.800 (1753600 samples)
Sample Rate: 32000 Hz
Channels: 2
Bitrate: 33 kbps
Codec: WMA
Codec Profile: WMA V2
Encoding: lossy

I booted iriver H120 into the bootloader USB mode, upgraded the firmware to r13142-070413. Then I unplugged USB and let the new firmware boot. After one minute I plugged the USB again (Rockbox was running), copied several files and unplugged. Rockbox ended in panic state:
*PANIC*
Blocking violation
B→*T

I could not reproduce the bug later.

The fire in Invadrox is mapped to the SELECT button on iriver H100 series however hardware of these players does not allow detection of simultaneous presses like SELECT + LEFT or SELECT + RIGHT. Could you please change the mapping so that the fire would be mapped to PLAY? (It is the only button detectable independently on iriver H100 series.)

Brandon Low repaired the bug http://www.rockbox.org/tracker/task/5906 by this commit:
17 Oct 12:56 Brandon Low apps/playback.c 1.365 Remove fill_bytesleft, simplify some buffering code, fix  bug 5906  Thank you, Brandon.

Unfortunately this repair revealed a new bug which could be observed under the same conditions. To be able to hear the gap while reproducing the bug use tracks which should play without a gap between them.

1. Play an MP3 file (not the last one in a directory).
2. Seek near to the end of the file (i.e. 30 seconds before the end).
3. Stop the playback. (A resume point is stored.)
4. Resume the playback by pressing PLAY.
5. Seek before the time point of resume. (Rockbock will rebuffer probably just the remainder of the track.)
6. Wait till the beginning of the next track.
7. Rockbox will start to buffer the next track too late - about 1 second before the end of the playing track although the default 5 seconds Anti-skip buffer is configured. As a result a gap will appear between the tracks.

Last reproduced on iriver H120, Rockbox CVS 061018-1412.

I encountered crashes on iriver H120 when leaving the “Recording Settings” menu entered from the FM Radio screen.
In older build (probably 060907) it showed:

I41:PDIR2FULL
at FFFFFFFF

Now (060909-1036) it just spins up the HDD (even when no option was changed), changes the sound of the radio (it loses high frequencies) and freezes without any message or the possibility to reboot by pressing PLAY. I seems that after entering and leaving the “Recording Screen” it does not crash anymore. I tested it with cleared settings.

Probably the CVS update from 31 Jul 08:12 solved one serious bug in playback but one similar minor bug still remains.

How to reproduce it:
1. Play an MP3 file (not the last one in a directory).
2. Seek near to the end of the file (i.e. 30 seconds before the end).
3. Stop the playback. (A resume point is stored.)
4. Resume the playback by pressing PLAY.
5. Seek before the time point of resume. (Rockbock will rebuffer.)
6. Wait till the beginning of the next track.
7. Sometimes (always?) the following happens:
- Rockbox will rebuffer again.
- A short part (fraction of a second) of the beggining of the file will be played twice.
- During the first playback the displayed time will show 0:00 or a nonsensical time.

Last time the bug was tested on the firmware CVS 060830-1432 with the default settings on iriver H120.
The bug could not be reproduced with OGG (whole file is buffered) and WV files.