Today I've experience something which IMO should not happen.

I recorded vian the built in micro on my Sansa e200 v1, paused the recording (not stopped!). In this state, I plugged USB cable. After that, there was the following text in the system font on the display, and the player did not respond to any keys. It had to be restarted via very long pressing at On/Off.

The text is:

*PANIC*

usb_storage_init_connection
(): 00M
pc:0006B878 sp:000D3538

  A: 00069978
  A: 00069F80
  A: 0005326C

bt end

I've reproduced this three time in a row.

I have the official version 3.14 installed.

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.

Dear Rockbox, long story short after doing update to the latest daily build c6d5cd7(2017-09-11), after playing music for around 30-40 minutes the screen start to freeze cannot scroll or select anything on the screen even turn it off is not possible but after few seconds it turn off by itself and can be turn on normally after that.

Daily build c6d5cd7-170907

An idle power off can occur in recording mode. When it does, data loss occurs. This has already bitten me a few times.

Steps to reproduce (on battery, not charging):
1. Execute Settings > Manage Settings > Reset Settings
2. Set Settings > General Settings > Startup/Shutdown > Idle Poweroff to 1 minute
3. Reboot
4. Go to Recording mode
5. Note current Volume and Gain settings and then change them to something else and note the new settings. Don't start a recording; just leave it in “stop” mode (*not* record or record-pause).
6. Wait for automatic power off
7. Power back on and check recorder settings

Expected: Settings are what they were after being changed.
Actual: Settings reverted to what they were on boot.

This can cause the loss of entire recordings, too:

8. Go back to Recording mode.
9. Wait until just before Rockbox would power off, then start a recording (if the display goes to sleep, it comes back on a bit before powering off; start the recording as soon as it comes back on).

Expected: Recording is done as usual
Actual: Rockbox powers off anyway, without warning, less than a minute into the recording. The recording is lost (or if the file is there, it's unplayable; maybe this depends on the recording format used).

I use a 64 GB MicroSD card in my Clip Zip and the stock firmware recognizes it. Rockbox recognizes it in the debug disk info screen and when connected to a computer via USB, I can read and write it through rockbox. However, when I try to access it or when I just check the regular rockbox info, rockbox does not show the SD card, nor can I play music from it.

The bug is also present in the current development version and is overall very similar to this one: https://www.rockbox.org/tracker/11798

I tried reinstalling rockbox and reformatting the SD card, but nothing worked.

Rockbox starts with remote, but doesn't respond to button presses except turning backlight on with build 6039eb05b-180313.
It works with deaeb73-161114 though.

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

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

+ storage_thread_init();

   return 0;

Rockboxutility barfs while creating talk files if it encounters unpronouncable charicters (japanese kanji) and does not continue afterwords resulting in talk files not being copied to the player.

[talkgenerator.cpp:156 INFO] voicing: "シマシマ" to "/tmp/talkfiles/952b0e2854336082e41fb0ef8ef8dc97.wav"
[ttsfestival.cpp:188 INFO] Voicing "シマシマ" → "/tmp/talkfiles/952b0e2854336082e41fb0ef8ef8dc97.wav"
[rbsettings.cpp:162 INFO] GET U: "festival-client/path" "/usr/bin/festival_client"
[ttsfestival.cpp:194 INFO] Client cmd: "/usr/bin/festival_client –server localhost –otype riff –ttw –withlisp –output \"/tmp/talkfiles/952b0e2854336082e41fb0ef8ef8dc97.wav\" –prolog \"/tmp/RockboxUtility.zowYwG\" - "
[:0 WARNING] QProcess: Destroyed while process ("/usr/bin/festival_client") is still running.

/
The result of this is an invalid wav file wich the the encoder bails out on and the process aborts.

[talkgenerator.cpp:235 INFO] encoding "/tmp/talkfiles/952b0e2854336082e41fb0ef8ef8dc97.wav" to "/tmp/talkfiles/952b0e2854336082e41fb0ef8ef8dc97.talk"
[encoderrbspeex.cpp:82 INFO] Encoding "/tmp/talkfiles/952b0e2854336082e41fb0ef8ef8dc97.wav" to "/tmp/talkfiles/952b0e2854336082e41fb0ef8ef8dc97.talk"
[encoderrbspeex.cpp:103 ERROR] Error: invalid WAV file
[ttsfestival.cpp:29 INFO] Destroying instance

I suggest ignoring failed encoded files and continuing encoding and copying the files that suceeded.

Click on the music file and die

I primarily use my unit for audio books while driving, but the latest build (as I write this) won't play one of the files properly. It tries to start, stuck at 0:00. Trying to seek hangs the player altogether, requiring a hard restart.

I've recreated this problem on a flaky Clip+ and an AGPTek Rocker.

The 'file' tool identifies it as: ISO Media, MP4 v2 [ISO 14496-14]

Here's what mplayer has to say (while playing it back properly):

[lavf] stream 0: audio (aac), -aid 0, -alang eng

I have an iPod 4G Grayscale (model A1059) running Rockbox 3.14 with an Apple FM remote (model A1187). The remote part works ok (Play/Select and Fwd/Rev buttons work - volume control is separate due to it being connected to the line out, but works).

However, the radio menu does not show up in the main menu when connected. Not when I boot with the remote connected, not when I connect it after booting, and not if I go to a different menu and then back.

In the debugging menu, it simply says that the FM tuner hardware is not found.

I am sure that this used to work at some point. Are there known regressions?

I am trying to build Rockbox for Sony NWZ-380 from Git repo, commit ce0b31d87db3c4c1c1bfb535c50770d33e9c4aaf.
arm-elf-eabi-gcc version 5.4.0, ARM binutils 2.30.
Everything goes smooth until just the latest step where this happens:

… LD duke3d.ovl
LD bmp.ovl
LD jpeg.ovl
LD png.ovl
LD ppm.ovl
LD gif.ovl
LD rockbox.elf
/usr/libexec/gcc/arm-elf-eabi/ld: section .ARM.exidx VMA [00000000600a9548,00000000600a954f] overlaps section .bss VMA [00000000600a7f20,00000000600ff773]

I'm using Rockbox on my NWZ-384 for a couple of years now and there were no problems building it in the past. I also was very glad that NWZ-380 port reached stable status in 3.14,
but now something seems to be broken (not terrible it seems, just requires some adjustments to the linker scripts but still).

Please refer to forum post for full exchange: http://forums.rockbox.org/index.php/topic,52518.0.html

In summary playing ALAC will crash the unit, other codecs not as much. My reasoning is (as contained in the forum post):

Converting some of my ALAC collection to FLAC to test has given excellent results = no crashes. I am suspicious of the ALAC decoder; watching the VIEW BUFFERING THREAD there seems to be consistency:

OGG/MP3/FLAC/WAV: CPU Frequency goes up to 124 until pcm: becomes full, then drops to 45mhz and pcm: hovers (it is always active) near the top of 100%. Upon track change the cycle starts again (124mhz until pcm: becomes full). I don't seem to get crashes.

ALAC: CPU Frequency goes up to 124 until pcm: becomes full, then drops to 45mhz and pcm: quickly goes down (takes about 2 seconds) to 75%, then cpu switches to 124mhz to get pcm: back up to 100%. This goes on constantly (cpu high - low cycle) while a single track/file is playing. I am now believing this cpu going up and down constantly gives me the crashes. Note on crashes: I don't know when they will happen, sometimes after a minute or two, sometime after 10 minutes , there is no pattern I can tell.

The volume settings are bypassed and is at max volume when the plugin is started. Even when putting it at -60DB it still has sound. After exiting and relaunching the app,the volume is maxed again,regardless of volume settings.

Whenever screendump is enabled,It gets a panic error.
Error Message:
*PANIC*
Stkov usb
pc:080739ac sp:080f5458

Reported Version: 3.15 not 3.14

Hello,

I am using a "SanDisk Sansa Clip+" and it seems that currently it is not possible to remove quickscreen entries when they are set, you can only overwrite them.

In the manual chapter "3.15 Quick Screen" has to be adapted, once this function has been implemented.

It would be very nice to have this possibility!

-Ramon

Hello there,

When I reboot my Rockboxed iPod nano second generation, it changes the time +5 hours.

Does anyone know why this can be? Thanks

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.

In the "Scroll bar width" screen, the value used to show the width selected is the previous one, not the current one. The first value change has no effect.
Anyway it seems that the right value is stored: if you select a value and exit by the screen, when you re-enter in it, the width is correct.

Priority low.

Referred to r22406.