Rockbox

If the user modifies the currently active playlist and then saves it, rockbox should load the newly saved playlist and resume it to the same position/state it was in.

This would make it easier to deal with the fact that Bookmarks don’t work with modified/dynamic playlists. Currently, in order to bookmark in a modified playlist, the user needs to save the playlist, stop playback, go manually find the playlist, load it, manually find where they were when they wanted to bookmark, and only then can a bookmark be created.

I have tried my best to see if I could do this, but I just don’t think my skills are up to the task.

Build of git commit 42dba70, tested on Eros Q

Bookmarks work normally if a file is played from the file browser by pressing select on a file.

If any playlist altering action is taken, the “Create Bookmark” item is no longer in the context menu, and the prompt to create a bookmark is no longer present upon stop if that feature is enabled.

To reproduce (this is probably not an exhaustive list):
1. in file browser, context-menu on a file and go to Current Playlist → Clear List & Play Next. Erase current dynamic playlist.
2. In WPS Context menu, the Bookmarks item is not present at all.

1. Play a file from a directory with multiple files. Erase current dynamic playlist.
2. In WPS Context menu, note Bookmarks item is present, and Create Bookmark is present within.
3. Go to current playlist from Context Menu. Remove or Move a track, it does not appear to matter whether it is before or after the current playing track.
4. In WPS Context menu, Bookmarks item is present, but Create Bookmark is not present within it.

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.

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