This problem bugs me for a long time. Sometimes, when I start the playback of a file too soon after startup, the playback starts to pause regularly for a few seconds. At the same time the ui is very unresponsiv. Stopping the playback and waiting for some time, resolves the problem.
I am listening podcasts at 250% playback speed exclusively and start the playback normally by selecting the latest bookmark.

Entering and exiting Pictureflow multiple times will eventually generate a segfault. This can be reproduced on the simulator quite easily. Despite the apparent ‘random’ nature of the segfault, GDB and Valgrind show it is always caused by the same line of code.

Oddly enough, it only occurs for portrait display orientations (LCD_HEIGHT > LCD_WIDTH). Weird . Square and landscape displays are fine, which would explain why nobody seems to be complaining… AFAICT, portrait displays are much less common especially among the stable ports.

I tested using the Sansa Fuze+ (portrait), Sansa Clip Zip+ (square), and iPod 6g (landscape) simulators.

The bug is on master, was introduced by 45915101d according to ‘git bisect’, and I confirmed it does not appear on the preceding commit (9adfab9b2).

The problem lies in the function render_slide(), on the indicated line:

...
        int p = (bmp->height-1-DISPLAY_OFFS) * PFREAL_ONE;
        int plim = MAX(0, p - (LCD_HEIGHT/2-1) * dy);
        pix_t *pixel = LCDADDR(x, (LCD_HEIGHT/2)-1 );

        if (alpha == 256) {
            while (p >= plim) {
                *pixel = ptr[((unsigned)p) >> PFREAL_SHIFT]; /** <<< HERE **/
                p -= dy;
                pixel -= PIXELSTEP_Y;
            }
...

I think ‘p’ must have a bad value, but it kept getting optimized out (even after recompiling with -O0) so I was unable to confirm this in GDB. I can see ‘pixel’ and ‘ptr’ and they appear sane.

Running the simulator under Valgrind is the most reliable way to reproduce the bug. Valgrind does run cleanly on 45915101d and master for square and landscape displays, so it is definitely the portrait orientation that triggers this.

Here’s the Valgrind error I got from testing on a Fuze+ simulator build of 45915101d:

==69170== Invalid read of size 2
==69170==    at 0x4BB2F67: render_slide (pictureflow.c:2708)
==69170==    by 0x4BB30FE: render_all_slides (pictureflow.c:2848)
==69170==    by 0x4BB4BF8: pictureflow_main (pictureflow.c:3684)
==69170==    by 0x4BB4BF8: plugin_start (pictureflow.c:3870)
==69170==    by 0x4BB6998: plugin__start (plugin_crt0.c:102)
==69170==    by 0x143586: plugin_load (plugin.c:961)
==69170==    by 0x157309: ft_enter (filetree.c:652)
==69170==    by 0x150672: dirbrowse (tree.c:707)
==69170==    by 0x150E47: rockbox_browse (tree.c:1021)
==69170==    by 0x12C8E5: plugins_menu (plugin_menu.c:57)
==69170==    by 0x12B9BF: do_menu (menu.c:636)
==69170==    by 0x143EDA: miscscrn (root_menu.c:347)
==69170==    by 0x1444E6: load_screen (root_menu.c:687)
==69170==  Address 0x4392fa8 is not stack'd, malloc'd or (recently) free'd

Radio Remote support is incredibly unstable on the newest daily builds (presumably since 77f8c9c).

While the stable build did not actually support the FM Radio functionality (and I haven’t gotten it to work on the newest dev builds either, despite the menu option now appearing), its remote functionality worked far better. On the current builds remote buttons only work one out of several attempts to connect the device. Getting it working requires a trial and error of several reboots and unplugging/plugging the remote in repeatedly. I have also seen the buttons on the remote cause rockbox to crash. None of this behavior exists in the 3.15 stable build.

Another thing is that the buttons on the remote seem to now control rockbox’s volume when they did not used to. They should not be doing so, since the radio remote uses the iPod’s line out signal and controls its own volume independently of the player. Not to mention that these controls currently bypass any maximum volume limits set in rockbox.

testing FW: 714f7a21da-2103*

after disconnecting a general purpose power supply (SONY 5V 1500mA) system crashes with:

*PANIC*
mount: 0

a restart is immediately possible by pressing (NEXT) “lowest right button”

As of the daily build from March 12th (and continuing to the 14th’s) attempting to transfer files over USB Mass Storage mode while using a common flash adapter for an iPod Video results in a halted transfer after a few seconds. It also results in Rockbox being stuck in USB mode until it’s rebooted, even after it is unplugged. I am not sure if this behavior existed in daily builds prior to the 12th, but it definitely exists in the 3.15 Release build. I have been told that this issue also affects builds on the iPod Classic. As far as I can tell, I believe Power Management would need to be disabled entirely when these flash adapters are detected (or by a manual toggle in settings) in order to allow proper USB file transfers.

UPDATE: After testing a build from the 11th (before the newest ATA changes), the same problem seems to persist. It may be important to note that I am using an unbranded “green board” and Digigear branded CF adapter, rather than the corresponding iFlash brand adapter. However this shouldn’t change Rockbox’s perception of them as they both show Power Management and Advanced Power Management as “unsupported” in Disk Info. The DMA mode is however listed as UDMA 2, whereas I was under the impression that these flash adapters functioned better under UDMA 1 and that an earlier commit had addressed this.

Most of the Japanese music artwork I purchased on iTunes has png format files registered.
Currently only bmp and jpg files are supported.
Normally, it can be handled by converting the artwork of the music file, but continuing to support only the old age format means that the music library will be adapted to the old age accordingly.
I think that if you want to manage the data rationally, you should support the default of the music store.

Left channel comes out of right ear and right channel comes out of left ear. When selecting mono left, it plays the left channel so that works fine. It also plays fine through my ipod when not on rockbox so Im pretty sure its just a software issue.

.webm files do not play in Rockbox. Container is not supported. Audio only .webm with supported audio codecs do not play.

I press Delete while Track 1 is playing and get this prompt:

 Delete?
 /Track 1.mp3
 SELECT = Yes
 Any Other = No

If Track 2 starts playing before I press SELECT, Track 2 is deleted instead of Track 1.

I’ve set USB Mode to Charge Only but this setting is applied only after I open WPS screen. If after setting change I simply exit settings menu to main rockbox menu (no music is played) - it asks on USB insert.
The same behavior after reboot. So if I switch it on and it’s loaded to main menu and then I insert USB - it always asks. Setting is properly applied only after I open WPS screen.

Hi there,

I’m using Rockbox on my Xduoo X3II with the build 4e54996 but the problem is the same since the build 0c99a3f. I never tried with builds previous to the 0c99a3f one.

Some Mp3 or Flac files can’t be read by Rockbox while there aren’t reading problems with the Xduoo firmware.

First, I was thinking it was relatd to the music files but I have looked precisely and I see they share a common problem : when the size of the cover art (named cover.jpg)in the folder album is bigger than 2.3 Mb, the covers can’t be shown on the screen player and the files can’t be played.

I have checked this problem on several album folders. Once I got a file working despite a cover art of 3,7 Mb.

Tell me how I can help you : providing files or cover art (or both), I will do.

My best and thanks

Hi All,

Some updated Hungarian translations.
Kind regards
g

Using Rockbox version 2d85c72151-201030
On an ipod 4th Generation (Greyscale)
Hardware revision 0×00050014 PP version: PP5020E

I’m unable to shutdown rockbox by long pressing the play button on the clickwheel as instructed in the manual.

Holding (as opposed to pressing it repeatedly) the “next” or “prev” button to scroll through a large list of files in the file browser or in the database while playing music, stops the music playback which then cannot be resumed until restart.

I’m testing this on xDuoo X3ii with the latest dev. build 7c498b9043.

Recreate:
* start playback (it seems the file format is not important)
* while music is playing go to the file browser or the database which has a few screens long list of entries
* start scrolling through the list by holding the “next” or “prev” button (don’t release)
* in a few seconds (while scrolling) the playback may start to skip and the scrolling starts to lag. In about 10 seconds the playback stops.
* release the button

Observe:
Menus work, playback screen shows the current track (playback indicated with the play icon but no sound being played and progress bar not moving), you can switch to a new track and it will be shown as the current - but no actual playback. Play, pause is registered, but makes no difference.

Waiting for a minute not pressing anything doesn’t resolve the issue.

The only solution to the “lockup” I found is to restart the player.

PS:
- doing the same while NOT playing music causes menu lag, but playback is possible afterwards
- pressing “next”/”prev” button to scroll through the list doesn’t lockup the player

Thanks for your continued support!
Best, iMpig

When a .m4a file is played, particularly one bought from the iTunes store, it seems to overwhelm the AAC codec in rockbox.

I think it may be something to do with the ‘anti-skip buffer’ but I cannot confirm this for sure, but it seems related, as in the stable release (3.15) playback works fine and the HDD Access indicator in the corner is only displayed briefly during the beginning of playback. In the latest development build (Rev. 3fbca49) and a few previous, however, the HDD access indicator stays on screen at all times during stuttery playback, the whole system becomes slow and almost impossible to use and sometimes locks up completely.

I have confirmed this on my iPod 4G color, it seems to be only on older iPods, as my 6th Gen classic plays them fine!

IMPORTANT NOTE: I am using an iFlash solo + 128GB SD in the iPod. Haas surround 5ms is enabled along with +3db tone control on both bass and treble

When Using FM Reciever within Apple Radio Remote with any of my iPods that support the function (in Rockbox), it either does not appear (Not detected at all in FM debug menu) in the latest stable version (3.15), or in the case of the latest daily builds, it appears to detect the FM hardware, and will attempt a search.

The ‘FM Radio’ menu in the debug menu of rockbox version 2cf75bf008-201023 states the following:

HW Detected: yes
PI:0000 PS:’ '
RT:
CT1970-01-01 00:00

An odd clicking sound may be heard, like interference from within the iPod.
The Radio remote works fine as it should in OF, indoors and outdoors

Rockbox functionality tested indoors and outdoors.

The remote control and audio functions work flawlessly (play/pause/volup/voldown/prev/next) when playing music from the iPods internal library.

Similar behavior seen between 1st gen nano, iPod 4G Colour and the 4G mono
with two different Radio Remotes.

Hello,

The SBS info viewport does not refresh automatically when used as a conditional and the value has changed.
One needs to enter any menu (Files, settings etc…) and get back to the home screen to force the viewport refresh.

Tested on Onda VX747 UI Sim for Windows (old 2018 build from rasher) and on target (YP-R1 fresh build edbdefa09a-201018)

Simple examples with playback mode (%mp) and repeat mode (%mm) conditionals:

%wd
%V(0,0,-,-,-)
%?mp<%VI(Z)|%VI(X)|%VI(Y)>
%Vi(X,4,19,232,200,1)
%Vi(Y,4,19,232,250,1)
%Vi(Z,4,19,232,344,1)
%V(0,363,100,37,-)
Status: %?mp<Stop|Play|Pause|Ffwd|Rew|Rec|Rec pause|FM|FM pause>
%V(100,363,-,37,-)
%T(0,0,-,37,play)
%T(0,0,-,37,stop,long_press)
Button: play/pause

%wd
%V(0,0,-,-,-)
%?mm<%VI(Z)|%VI(X)|%VI(Y)>
%Vi(X,4,19,232,200,1)
%Vi(Y,4,19,232,250,1)
%Vi(Z,4,19,232,344,1)
%V(0,363,100,37,-)
Status: %?mm<Off|All|One|Shuffle|A-B>
%V(100,363,-,37,-)
%T(0,0,-,37,repmode)
Button: repeat mode

When playing a single album file along with a .cue-sheet file (for track listing & metadata) the numbers reported on screen eg. “1 of 5” are wrong.

Actually the second number reported is in reality for the number of cuesheets within the directory, which is not what the user expects.

What a user wants (I believe) is to show the numbers relevant within the current cuesheet (album) - number of the currently playing track out of all album tracks.

It’s interesting that the tracks are otherwise correctly marked on the progress bar and all playable (skipable to), it’s just the numbers that are wrongly reported.

I tested two “default” themes to make sure it’s not a theme problem.
Also “File view > Show files” (showing cuesheets or not) setting does not change this behavior.

Tested on xduoo x3ii, dev build ef34126913

With default scrolling settings (in particular Settings → General Settings → Scrolling → Screen Scrolls Out of View set to No) on my Xduoo X3 I’m unable to see end of text using tree scrolling feature (Play + Next)
For instance with folder name:
2012 - Greatest Hits 1993 - 2010 [Malaysia Edition]
Scrolling with Play + Next scrolls only to “Edit” part and “ion]” is missing.

Also with Screen Scrolls Out of View Set set to Yes I think it’s better stop scrolling when end of text is reached (so basically ignore this setting when doing manual scrolling). Or at least stop right after text is hidden.

P.S. Thanks for implementing tree scrolling for Xduoo X3 so quickly (https://www.rockbox.org/tracker/task/13240)

As there are multiple targets that support such formats in OF (all Xduoo players, Agptek Rocker…) would be cool to have it in rockbox too. Not sure if it’s really useful but there is open source library for decoding such formats written in C:
https://tari.in/www/software/libodiosacd/ https://bazaar.launchpad.net/~robert-tari/libodiosacd/trunk/files/head:/src

Steps to reproduce

@Boot
time stretch = false
Haas surround = disabled

Play Song

enable timestretch
enable Haas Surround

Tracked crash down to here:
https://github.com/Rockbox/rockbox/blob/master/lib/rbcodec/dsp/surround.c#L81

static void dsp_surround_flush(void)
{

  memset(core_get_data(handle), 0, SURROUND_BUFSIZE);

}

removing the memset stops the crash at the expense of dirty data blasting in your ears

testing the handle doesn’t help the handle is valid as far as buflib is concerned

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.

Playing 320K MP3s pauses often in Version 3.15 and daily build 7d00533 also UI becomes unresponsive
Version 3.14 or older does not reproduce the issue in either 44 or 48khz sampling rate and same sound options
Is not reproducible under OF or Version 3.15 running on IPOD 6G
seems to be a cpu usage issue as compiling a version of rockbox with much higher than stock CPU clocks seems to alleviate the issue to an extent but there is still occasional pauses that is not present after reverting to 3.14 and stock 80 mhz clock speed.

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

Neither of the tools, ipodpatcher or Rockbox Utility 1.4.0, work on macOS Catalina.

Catalina removed 32bit support.

Using ipodpatcher generates the following error:

bash-3.2$ ./ipodpatcher
bash: ./ipodpatcher: Bad CPU type in executable

And Rockbox Utility has a white circle with a line through it indicating that it does not work with this version of the OS.

(see attached file)

I store the album art by putting a folder.jpg file in the album's directory.
Any WPS on other players shows the cover pictures properly if album art is enabled in the theme.

I am aware of caveats like progressive jpgs, that are not supported by RB.

In the attached zip file, there are four directories with a folder.jpg file and a free opus file for demonstration purposes.

All pictures show up fine on my Sansa E200 (v1) using CabbieV2 or lebellium_Samsung-like.
However, on my XduOO x3ii the pictures are not displayed for the examples 1 - 3, but show for example 4.

None of the jpgs are progressive and I cannot figure out a difference between 1-3 and 4.

I don't know how to debug this further myself, but would be happy doing any furter experiments.

This is true for the current dev builds, e.g. b450707955.

I would like to run my iPod with its keypad locked all the time, thus I wrote a little patch to an option to disable the settings reset during startup regardless of the hold button's position.

You will find the patch attached to this message. I'm not entirely convinced by the name of the new option (or my wording in general) so if you have a better idea, feel free to rename things.

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

Version 9e186e34ab-190820

i have an ipod 7th gen
rockbox installed
140.000 titles

database contains in unpredictable many cases of the folders 2 times the same title
not in all folders, but it happens very often that i open one and i see all titles 2x although they are only 1x on the sd card

the files exist only ONCE
but the database keeps listing them all 2 times

i rebuilt it several times, but the database keeps on doing that

any hint what i can do?

start as apple / itunes and delete rockbox folder / install new did not help

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

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.

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.

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

Click on the music file and die

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.

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

Bug exists in the DEV builds for, at least, Sansa Clip+, Sansa Fuze+, and iPod Video for at least a year, although I cannot confirm this as I've only just now tracked down the problem. The issue was discovered because imagemagick occasionally selects 1x2,1x2,1x2 as the chroma sampling factor when converting an image.

To recreate this bug, convert any image using imagemagick to a JPEG with that chroma sampling factor and attempt to view it in Rockbox. What you will see is a nonsensical image to the size of the original JPEG. Any desktop image viewer, like eyeofgnome, renders the picture correctly.

I've also included a sample Rockbox logo generated in the faulty fashion along with this bug. To create it, run this command in a Unix-like with imagemagick and curl installed: 'curl -J -L "https://www.rockbox.org/rockbox400.png" | convert - -sampling-factor 1x2,1x2,1x2 -quality 100 folder.jpg'

Ordinarily, when Rockbox is shut off and turned back on, it will remember the position in the last-played song, and begin playing from where you left off. However, in the latest build, Rockbox doesn't remember the last track that was playing if the file used a relative path. This happens on every version of 3.14 including the current daily build (2017-11-13).

Here is how the error can be reproduced:

Have a folder with two songs. Then, in the parent folder, create two m3u playlists named "absolute.m3u" and "relative.m3u".
.\
—absolute.m3u
—relative.m3u
—MUSIC\
——song1.ogg
——song2.ogg

In the absolute.m3u playlist, add the following lines:
MUSIC\song1.ogg
MUSIC\song2.ogg

In the relative.m3u playlist, add the following lines:
.\MUSIC\song1.ogg
.\MUSIC\song2.ogg

To see expected behavior:

1.) Open the files list, and run absolute.m3u and song1.ogg begins playing.
2.) Push right to start song2.ogg. Let it play a few seconds in.
3.) Turn off your device by pressing power.
4.) Turn on your device with the power button.
5.) song2.ogg continues to play the same song at the same location as when it was shut off.

To reproduce the bug:

1.) Open the files list, and run relative.m3u and song 1 begins playing.
2.) Push right to start song2.ogg. Let it play a few seconds in.
3.) Turn off your device by pressing power.
4.) Turn on your device with the power button.
5.) song1.ogg plays from the very beginning.

The file format of the songs doesn't seem to matter (I've tested ogg and mp3).

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).

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.

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.

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.

I downloaded this: https://www.youtube.com/watch?v=Lrb0dHKJBR4 using the youtube-dl python program. The file plays and seeks correctly in foobar2000 and MPC-HC. But, on my clip+, whether I seek 10 seconds or 10 minutes into the file, it ends up playing a position of the file previous to the one displayed. For example, if I seek 50 seconds forward from the beginning, it will play the file from the start, while the screen still displays as if it's playing from 50 seconds onwards. Seeking to the end of the file will have it play a section from about 2 minutes earlier than it should be, while the time display and music will continue until 1:14:20, with the file actually being 1:12:46.

I did not hear the files being played slower than they should be, so it seems it's only an issue when seeking.

I've confirmed this happens on every AAC file downloaded by youtube-dl, and that re-encoding the same file to AAC using NERO encoder makes the problem dissapear.

For a couple of months my Sansa Fuze v2 has been crashing randomly when playing music. Most of the time I just get a white screen with an error message. The last message I got was :

'undefined instruction at 0006DC8C'

(I think that last number varies at each crash)

This didn't happen with v3.13, but it's been happening with every daily build I've tested IIRC.

It doesn't happen very often so it's hard to reproduce. I listen to music in public transports about twice a day and this happens not more than once a week. It seems to happen more often when the battery is low (less than 10%). It generally happens early in a playback session, when the first or second track is played.

Sometimes I don't get a white screen, but the program freezes and some parts of the interface are surrounded with white frames. I don't know if it's the same bug or if it's unrelated.

Note that I'm always listening to music on a microSD card, and I haven't tried on the main memory.

PS: I chose "Sansa Fuze+" in the OS list because I couldn't find Sansa Fuse v2.

After upgrading from "Version: 33856d9-161111" to "Version: 6436c6e-170211" Resume Playback from the main menu does not work. Here are the steps taken to verify the problem:

Running Version: 6436c6e-170211… Reset config
Using default settings, enabled Shuffle via Shortcuts
Started playlist; track identified as 1 of 5330
Skipped ahead to the 5th track
Paused @ 1:01
Forced shutdown
Enabled Hold switch
Waited ~1 min., then booted via disengaging Hold switch
Clicked Resume Playback… resumed on the same first track (1 of 5330)
This behavior occurred every time I attempted to Resume Playback.

Restored previous version (Version: 33856d9-161111)
Rebooted
Reset Settings
Using default settings, enabled Shuffle via Shortcuts
Started playlist; track identified as 1 of 5330
Skipped ahead to the 5th track
Paused @ 1:01
Forced shutdown
Enabled Hold switch
Waited ~1 min., then booted via disengaging Hold switch
Clicked Resume Playback… resumed on the fifth track @ 1:01

FWIW: No Bookmarking used (never have). Database not initialized (never use it).

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

Steps:

(Asing attached config.cfg)

1 Set Settings, Playback Settings > Shuffle to Yes
2 In Files, enter a folder of tracks and press Select to play
3 Go up to the folder itself, press long select > Current playlist > Insert Last
4 Press long select > Current playlist > Insert
5 Press long select > Current playlist > Insert
6 Go to Now Playing > Current playlist > View current playlist

Expected: Four copies of the list, all shuffled

Observed: One copy of the list, shuffled, followed by three not shuffled: http://i.imgur.com/Emldcdt.png

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

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

Creative ZEN device build 8fec364f6-170125

Steps:

1 Clear Running Time
2 Shutdown, to ensure Running Time clear takes effect
3 Launch Rockbox
4 Record wall clock time
5 Leave running for a few hours
6 View Running Time and compare with elapsed time on wall clock

Expected: Running Time equal to elapsed time
Observed: Running Time less than elapsed time by 2%

Note: battery_bench.txt times accord with elapsed time.