Rockbox

Device: xDuoo X3
Version: 102dc49ed9-230703

Hi! I recently dug my xDuoo X3 out of storage and updated it to a new daily build, which has moved the last.fm scrobbler to a plugin. Since then, I’ve noticed it occasionally misses tracks.

Anecdotally, it seems the first track I listen to is often correctly scrobbled but subsequent tracks are lost. A wild guess is that the cache is not being written before the idle poweroff kicks in, losing any scrobbles in memory.

Hello,
I’d like to suggest that the timer for when to turn off the LCD backlight should start when the last pressed button is released rather than the current behavior - when a button is pressed.

Example:
I have my backlight timer set to 10s because that is usually more than enough time and I want conserve the battery life.
However, when I’m scrolling through files/database/playlist in order to find a particular song, I PRESS and HOLD a (fwd / back) button. While I’m still holding the button (in order to scroll) the backlight times out. I think it would make more sense to start the backlight timer when all buttons are released.

What do you think?
Is there already a way around this that I missed?

Thank you,
best iMpig

Tested on: xDuoo X3ii, b6d04d1ac0-230310

This one happens every time for me under the following conditions:

1. Start playing a track from Database (note, it must be from Database, same procedure with file browser works as expected)
2. Shut off player
3. Boot up player and resume playback
4. Use back button to navigate to a different album and play a track (this loads a new playlist, I think is important?)
5. Resulting panic message: “audio_reset_buffer(): OOM!”

This is present on the latest and greatest build 78718aa7eb-230129, and I’ll attach my config file in case it’s a weird settings combination.

My Sansa Clip Zip with latest daily build 20230128 starts to throw exceptions on playback start from time to time.

Data abort at 30
FSR 0×8 (domain 0, fault address 0x55de00
pc: 3006b48c
sp: 300dec30
bt end

pc and sp can have different values

Then pressing power button leads to “Prefetch abort …” and blinking screen

I don’t find the way to reproduce it. It just one time works and another time might throw when you start playing files

Can’t say when this was introduced exactly but I’ve been using 20221120 build before update without any such issues.

I know for sure this one’s a regression. I spoke way too soon! This appears to have been a preexisting bug uncovered for some reason by an unrelated patch.

I can no longer add “Haas Surround” to the quickscreen. Just now, I did get it to work, but then I tried it again and it crashed again, so I will try to make the reproduction procedure as foolproof as possible. It seems to depend on whether audio is playing when the setting is added?

Tested on version 7a00ad72. Bisecting to follow.

There’s two parts to this: I can add it and it shows up on the quickscreen, but if I try to change it I get a TLB refill crash. Alternatively, if I add it and shut down the player, the setting is no longer there when I boot it up again.

To reproduce:

1. Start with no QS Bottom setting.
2. Have Haas Surround set to Off
3. Have music playing
4. Go to the WPS
5. Open Context menu, go into Sound Settings, add Haas Surround –> Haas Surround as QS Bottom
6. Back out of context menu with back button
7. Open QS, attempt to change Haas Surround setting
8. TLB Refill crash

The setting being saved is similar:

1. Start with no QS Bottom setting.
2. Have Haas Surround set to Off
3. Have music playing in the WPS
4. Open Context menu, go into Sound Settings, add Haas Surround –> Haas Surround as QS Bottom
5. Back out of context menu with back button
6. Turn off player
7. Turn off player, start playback, open QS. Setting isn’t there.

There is at least one way of launching a plugin from an already running plugin,
e.g. by using the Shortcuts menu to navigate to a folder and then choosing
“Open With” in the context menu, which can crash the player.

There are variants of the 5G Video iPod with 32 MB and 64 MB RAM. Rockbox makes one build, with memory size set to 64 MB. This is a problem for SDL game overlays, because their location in memory depends on memory size. They’re built for 64 MB memory, and Rockbox will refuse to load them into non-existent memory on an iPod with 32 MB memory. The workaround is to set the memory size to 32 MB and rebuild them. In the build directory, after a build is complete, you can do:

sed -i s/MEMORYSIZE=64/MEMORYSIZE=32/ Makefile
rm apps/plugins/overlay_ref.link
make

Verify the result via:
grep PLUGIN_RAM apps/plugins/sdl/*.refmap

You should see:
PLUGIN_RAM 0×0000000000000000 0x0000000001e80000
and not:
PLUGIN_RAM 0×0000000000000000 0x0000000003e80000

After this, Wolf3D, Duke3D and Quake all worked for me, though I had a data abort when exiting Quake.

This is on Rockbox 3.15. I’ve also downloaded rockbox-ipodvideo-20221120.zip and confirmed the problem exists there, but II don’t have the new toolchain, so I didn’t experiment with that build.

I noticed that some tracks converted to Vorbis, OPUS and AAC will become distorted at higher volume levels, especially when used with compressor and makeup gain (default compressor settings with Threshold -24 dB).

I was trying my best to make reproduction as easy as possible, so created some audio samples that are constantly problematic on my Sandisk Sansa Clip+ using Rockbox 3.15. The samples contain a 200 Hz sine wave every half a second and silence at every other half, each at -1 dB level. Listen to attached files starting with “200hz”.

1. Copy all samples to the player
2. Go to Sound Settings → Compressor → Threshold and set it to a very low value (-24 dB is perfect).
3. Start playing back the samples.
4. You’ll notice the distorton, the same kind at Vorbis and OPUS but a slightly different at AAC.

I also attached the output from my Sansa (playback.mp3) recorded from its headphone jack. I played the samples in the following order: m4a (!), ogg (!), opus (!), wav (ok)

Other formats (tested: WAV (pcm_s16le), FLAC, MP3, AC3, MP2) are OK and have no distortion at all with the same volume and compressor setting.

It seems something goes wrong (a bit overamplified?) between the decoder and the compressor (maybe a floating point precision issue with base output volume from the decoders?). Also, this isn’t necessarily specific to the compressor. I’ve also heard these distortions without the compressor during playback of various Vorbis tracks, however at those it’s harder to hear and distinguish the distortion.

Emoji and other Unicode characters cause Rockbox to crash or to fail to play the file.

This could also cause corruption of data in the worse case scenario.

To recreate this bug:

Add emoji or other non-standard Unicode to track: title, album or artist tagging.
Then attempt to play the file like normal.

This will cause Rockbox to fail to play the audio file or crash (had this happen ones)

The ipod3g config file does not contain “HAVE_HARDWARE_CLICK”.

If it’s added, main.c and misc.c fail to compile.
Including piezo.c in main.c allows it to compile, and the option appears on the iPod, but the clicker does not work.

On an M3k target (or simulator), holding down the fast-forward button to move to the very end of an ALAC file can cause a crash under certain conditions, especially if the sample rate of the following file differs from the playing one.

Codecs other than ALAC may behave differently. A similar FLAC file doesn’t seem to cause a crash, but instead reverts the playback position to where the Fast-Forward button was first pressed.

“Frequency” may have to be set to “Auto” in Playback Settings to (make it easier to) reproduce.

To reproduce:
- Clean install daily build 7616822fbb-231002
- Unzip attached mp4/ALAC files to new folder in root directory
- Select one of the files for playback (the playlist should now contain all 3 files)
- Fast-foward to very end of file

Expected result:
- Next file is played, or playlist finishes (in case of the last track)

Actual result:
*EXCEPTION*
TLB refill at 83d0123c [0×0]
00 pc:83d0123c sp:800d8930
01 pc:83d002c4 sp:800d89b8
02 pc:80047aa8 sp:800d8ab8
03 pc:80048194 sp:800d8ad8
04 pc:8008fcac sp:800d8b18

Simulator gdb output:

  Thread 1 "rockboxui" received signal SIGSEGV, Segmentation fault.
  alac_decode_frame (alac=alac@entry=0xaaaaaadc3c18 <codec_stack+31776>, 
  inbuffer=0x0, 
  outputbuffer=outputbuffer@entry=0xfffff4b20024 <outputbuffer>, 
  yield=0xaaaaaab123ec <yield>)
  at /home/christian/Developer/rockbox/lib/rbcodec/codecs/libalac/alac.c:1120
  1120	    channels = readbits(alac, 3);

It should be prevented by `action_wait_for_release()` but this logic is broken.

https://github.com/Rockbox/rockbox/blob/master/apps/gui/wps.c#L383-L384

Broken by the following code:
https://github.com/Rockbox/rockbox/blob/51c1e3ce7fa2874f2b1afd0788ff7d2beba6a96e/apps/action.c#L278-L293

Removing whole block fixes it but seems somehow breaks yes_no screen. Broken logic was firstly introduced in
https://github.com/Rockbox/rockbox/commit/54e6bafada0f0b55246e208c3ffb85394756135f

Changing the “Shuffle” setting from the Shortcuts menu won’t shuffle or unshuffle the playlist as would happen if you changed it from the Settings menu or QuickScreen.

I’m using Rockbox (build from 2022-05-03) with xDuoo X3ii.

The device supports controlling playback with a button press on the headphones.

This is behavior currently enabled with a define (USE_REMOTE) during the build process, and for now, it’s only supported by the xDuoo target.

I would really prefer if this was a setting, as I find it sometimes doesn’t behave as expected, and if I wish to turn it off I have to rebuild rockbox.

Here are the issues I’m having, which may be related to faulty headphones, but might also be related to some error-correction that the native firmware does, and Rockbox doesn’t.

I found that these behaviors can cause Rockbox to think there was a remote button press:
1) Pulling the jack in and out of the player (the rockbox setting to pause/resume playback when the jack is removed/connected is DISABLED).
2) Sometimes moving the headphones wire triggers a button click.

I’m using Rockbox (build from 2022-05-03) with xDuoo X3ii.

Sometimes the bootloader fails to load Rockbox with the error “Cannot boot Rockbox”. After a single restart of the device it loads fine.

The current bootloader makes this restart process very cumbersome:

1) When starting the device without user interference, the bootloader tries to load rockbox and gives the error
2) Then the bootloader is back in the main menu, and after several seconds of no user involvement, will attempt to load rockbox instead.

I haven’t tried, but I think this loop will continue indefinitely.

If I wish to restart the device, I need to follow these steps:

3) Choose the configuration option in the bootloader, and choose the restart action.
4) Wait for the device to restart. Then the bootloader will start with the “Settings” option selected by default (since it was the last selection).
Before it auto-selects it, I need to quickly switch back to the Rockbox menu option.

During this entire process, the device requires my full attention, which means I can’t just turn the device on in my pocket and wait for it to autoplay.

To ease this error-recovery, I suggest the following:

1) When Rockbox fails to load, a countdown timer will start, and when it’s over, the device will automatically restart. The user can interrupt this process with any button press.
2) When choosing the settings option in the bootloader, I don’t think the bootloader should remember it for later. It should only remember the Rockbox option, or the “native firmware” option.

—

Identifier | hbs
Language Name(s) | Serbo-Croatian
Status | Active
Code Sets | 639-3
Equivalent(s) | 639-1: sh (deprecated)
Scope | Macrolanguage (Serbian, Croatian, Bosnian, Montenegrin)
Language Type | Living
Denotations | Ethnologue, Glottolog, Multitree, Wikipedia

—

Request to add this language in RockBox, and/or to fuse Serbian with it.
It’s pretty much 4 languages in one. No need for any additions.

xduoo X3
I am using Car adapter Mode.

No problem during battery charging.
However, once the battery is charged to 100% and the charge is complete, playback will stop

rockbox:d4917888e3-220805
problem is repeatable

@Translated at DeepL

utils/sansapatcher/sansaio.h uses loff_t but doesn’t include the header for it, so it fails to build against the musl libc. I believe this header is <sys/types.h>. I’m not sure, but I think this header is also present on Windows, so including this may avoid the need for the existing messy loff_t logic.

See the original Gentoo Linux bug report.

The lib/skin_parser and utils/themeeditor directories are missing, causing the build to fail. The source tarball is therefore effectively useless.

Revision 58bf7c7e6f.

The iPod freezes at the boot logo.

Additionally, I upgraded my iPod video to this same build, and it boots on the target.

Note: I have put the OS as “Eros Q / K” but actually I’m using a Surfans F20, which runs the same version of Rockbox however.
Build: 1d39261338-220528 (rockbox-aigoerosq-20220530.zip)

To reproduce:
- Install Rockbox (the hosted port) on this player
- Observe that scrolling through a long list of files (whether by using the wheel or holding fast-forward) works smoothly
- Go to settings > General Settings > Display > LCD Settings > Backlight Fade In, and set it to “No” - Observe that scrolling now works sluggishly, and almost grinds to a halt after holding fast-forward for a few seconds

Bug report copied from demon_slayer’s post: https://forums.rockbox.org/index.php/topic,53858.msg250472.html#msg250472

*PANIC*
TLB refill handler at 0x800272fc! [0x4]

My rockbox version is 2f71571c0a-220515. It doesn't happen all the time 
but seems to happen when I eject and remove the USB from the M3K. I am 
able to turn off the device then reboot back into Rockbox.

This crash comes from https://github.com/Rockbox/rockbox/blob/master/apps/tree.c#L659.

Update
It happened again but with a slightly different message

*PANIC*
TLB refill handler at 0x8007c970! [0x720065]

This is in lcd_alpha_bitmap_part_mix in lcd-16bit.c so it’s probably the same tree browser bug, or at least closely related.

Although reported on the M3K I suspect this will be reproducible on all players.

Steps to reproduce:

1. Enter the file browser
2. Plug in USB and then unplug it
3. Select something in the file browser

By getting rid of duplicate untagged entries, PF also over-eagerly eliminates
all but one album with a valid artist_idx of 0 when building its album index.

If you have more than one album with the same title but by different album artists,
only one of them is going to be displayed in PictureFlow

Regardless what setting is selected when it comes to displaying file extensions, file name voicing always spells out the full file name (including the extension as well). Visually it all behaves as it should, but it would be nice if file name voicing/spelling followed the user experience of sighted users as long as possible.
This is on an XDuoo X3II, but this does not feel like a player-specific issue to me.