Rockbox

Over the past month? the radio menu has been disappearing. When I reinstall the menu comes back and the radio works and the debug screen shows the radio.

When it re-initializes the DB, the radio disappears and the debug screen said that there's is no hardware.

If I manually deleted the DB files, the radio comes back…

A few other people on anythingbutipod forum have mentioned the same issue.

Still an issue August 1, 2007: r14133-070801

Holding the Pause button (to move/paint down) will shut down rockbox.

This shutdown combination should be disabled for Rockpaint!

While I’m at it (and you can put this in a different Flyspray if you want), I suggest that we make use of the iPod scrollwheel somehow in Rockpaint, maybe to change the size or shape of the brush or something and/or in the menus.

I would also like to be able to set the colour of the background to start with.

Only filetree.c should be allowed to call opendir(), anything that needs to recursively scan directories should be calling ft_load() which can smartly open, scan and close a directory.

The problem with this is that the filename buffer could get corrupted easily if its misused.

as of r18234 the following is using opendir() in the core
filetree.c:133: dir = opendir(c→currdir); ← not recursive
filetree.c:257: dir = opendir(tempdir); ← in ft_load() so ok
filetree.c:259: dir = opendir(c→currdir); ← “” “” “” misc.c:164: dir = opendir(pathlen ? buffer : “/”);
misc.c:1059: dir = opendir(BOOTDIR);
misc.c:1142: DIR* d = opendir(path);
onplay.c:466: dir = opendir(dirname);
onplay.c:817: srcdir = opendir(src);
tagcache.c:4075: dir = opendir(dirname);

the tagcache and the onplay.c ones are dangerous… the 3 in misc.c are not recursive so safe.

the following are uses in plugins, havnt checked them so I only know for sure that stats, disktidy and properties are unsafe
plugins/disktidy.c:203: dir = rb→opendir(name);
plugins/disktidy.c:270: dir = rb→opendir(name);
plugins/md5sum.c:78: dir = rb→opendir( path );
plugins/md5sum.c:113: DIR *dir = rb→opendir( newpath );
plugins/md5sum.c:209: dir = rb→opendir( arg );
plugins/properties.c:79: dir = rb→opendir(tstr);
plugins/properties.c:151: dir = rb→opendir(dps→dirname);
plugins/properties.c:276: dir = rb→opendir(str_dirname);
plugins/random_folder_advance_config.c:70: dir = rb→opendir(fullpath);
plugins/random_folder_advance_config.c:165: dir_check = rb→opendir(formatted_line);
plugins/rockpaint.c:740: d = rb→opendir( bbuf );
plugins/rockpaint.c:754: d = rb→opendir( “/” );
plugins/rockpaint.c:915: d = rb→opendir( FONT_DIR “/” );
plugins/sokoban.c:925: if(!(dir = rb→opendir(dirname)))
plugins/stats.c:139: dir = rb→opendir(fullpath);
plugins/test_codec.c:763: dir = rb→opendir(dirpath);
plugins/test_disk.c:356: dir = rb→opendir(testbasedir);
plugins/test_disk.c:359: rb→splash(HZ, “opendir() failed.”);
plugins/test_disk.c:421: if 1) == NULL)
plugins/wavrecord.c:3774: if 2) == NULL)

so,
The bad calls in the core should be changed to use ft_load, and the plugins should either get a new function in the lib to grab some ram and manage the whole thing, or maybe its safe to just call ft_load there also?

or alternatively, we can go on ignoring the issue.

I have just now installed the latest stable version of rockbox (that would be 3.0) on an iriver h340. Unfortunately, it’s unusable at the moment due to some serious screen corruption. It sort of looks like this picture: http://img54.imageshack.us/img54/2263/iriver3qs.jpg, but is so much worse that it’s impossible to navigate the menus. If I wait for the backlight to go off, and then press a button, the screen looks fine until I start navigating, at which point the corruption resurfaces.

I’m really excited about rockbox, but this bug is a showstopper for me at the moment.

Thanks for looking into it!

Regards.

When the dc jack is plugged in to charge while the player is not running (switched off), the display says ‘ATA Error -11’. It can’t be reset except by removing the batteries and dc jack. I ran an older build from last year and it works fine.

This may represent other players as well.

I installed a new battery on my iriver, a 2100 mAh that is working perfectly. The problem however, is that when fully charged, the voltage holds up to 4.12 volts, and until it drains to somewhere under 3.9 volts, Rockbox thinks that it is powered via USB, so naturally Rockbox gets stuck in USB mode until the battery is drained enough for Rockbox to realize that it IS a battery. With this problem at hand, I have to charge my iriver to only less than seventy percent of its battery life, or else wait for an hour or so to drain it to that point. I HAVE tested it in its original firmware, like I said, works perfectly. The problem lies with Rockbox thinking that the battery is a USB charger. I am asking for a fix around this. Is there a way that I can modify Rockbox so that it may understand that it is running off of a battery that will get up to 4.12 volts and not mistake that for USB power? I just now thought to turn off the “Charge During USB Connection,” maybe that will solve the problem; I will get back when I find out whether or not that works. However, I would still like to request a work around for this problem. Any help is much appreciated. Thanks.

Using the latest revision (r20001 - but its been broken since I started using Rockbox) the iAudio M3 does not recharge the battery using either the USB or the Power adapter.

The only way I can get the iAudio M3 to charge is to use Cowon’s firmware.

Currently running r19940 but there doesn’t seem to have been any chage in the power code for the gigabeat S recently.

The issue is that there is a regular clicking noise heard if DC power is connected while the battery is fully charged. This noise is not heard while the battery is charging. The same power adapter doesn’t cause the same noise on an F.

When the battery is low, Rockbox is unable to charge iPod. When booting into Rockbox, the charging icon is displayed, but after a while the device shuts down.

Booting the OF and charging under it for few minutes is required.

charging isn’t monitored on ipod 3G. it just goes up to 100% very quickly and stays there.

When the battery is nearly empty and the iriver H10 is about to shutdown, the volume sometimes suddenly increases progressively, as if the volume UP button was pressed and held down, all the way up to the maximum.

This has happened to me about 3-4 times so far. Pressing the volume DOWN button somewhat counters this bug, but only for as long as the DOWN button is used - the volume keeps increasing.

This occurs with Rockbox Release 3.5 (not 3.4 as the Report Version field of the ticket says).

sometimes when i click on next(or previous) button a couple of times , rockbox gets stuck and then anfter 3 or 4 secs ,it restarts .then when loaded the battery is empty.
i am not sure if this is a rockbox related issue or hardware realated cause i use my ipod for file transfer mainly .and this issue existed from version 3.3 till now( i cont know or remember about before that).

is there a way that i can somehow debug (trace) this issue?

URGENT/HIGH PRIORITY: Rockbox Firmware 3.7 installed with iRiver H300 1.29J.

Charging when in Rockbox mode (player switched on):

When Rockbox is running and the charger is plugged in, Rockbox can be seen charging the battery in the top left hand corner. When it is fully charged, it shows a full battery.

Charging when iRiver is powered off (player switched off):

When the charger is plugged in, the iRiver begins charging in Original Firmware mode. This is okay as the player charges correctly until Complete.

Booting into OF mode, shows a full battery charge so I can be sure it is fully charged.

However, boot back into Rockbox mode and Rockbox seems to be misreporting the battery charge as depleted - I say misreporting because at this point I know it is actually full/complete. (Booting back into OF mode would also confirm again at this point that there is indeed a full battery charge).

But run Rockbox 3.7 and after a few minutes, a false message - "Low Battery - Shutting Down" appears, after which Rockbox powers off.

I know this is inccorect, because if the battery was so low in OF, the iRiver OF would not even allow you to attempt to power back on (instead it would display a "Low Battery" picture on the display), but I can boot back into OF mode easily with no problems even after this message from Rockbox, again the OF shows a full battery and I can run it for hours with no problem so I know somewhere here there must be a miscommunication/misreading from the battery charge to the Rockbox 3.7 firmware.

Have tested this a number of times to ensure it is a fault and yes it presents itself everytime.

When plugging in an AC USB charger, the ipod shows rockbox's disk mode instead of just changing the "external power" icon. Is it possible to make it detect if a charger is connected, or an usb host (for example, a computer)?

Doing the same test (with the same charger) on an ipod color/4g shows the expected result (not going to usb mode, just a charger icon appears)

The rockbox behaviour when plugging in a firewire cable is to automatically reboot into disk-mode, preventing charging whilst running rockbox.

When booting rombox or rockbox from flash on h1x0 with dircache enabled, chances are good that the thing will freeze. This started with r30393 / 7e14b935dfdcd808cfb0703d19a43efd11eeef16.

This still happens with d2f97da668836f5d825c9aaef0d58dea64fc4dd5

There is a bug with the clip zip that when you plug a device in for the first time it doesn't install succesfull the driver and when i unplug it the device crashes and needs a hard reset

The remaining time estimate shown under System>Rockbox Info reports just “0h -1m”.

The battery indicator on the status line works OK… maybe it’s just a display bug?

When my Fuze+ is charged and it's still connected to the charger, it seems it keeps toggling between charging and discharging.

I think the problem is that it reacts to some voltage to stop charging. When it's charging it measures up to 4.35 V. But when it stops charging it changes to 4.25V, and says something like 96-99% charged, and which point it changes to charging again, and so on.

So it's basicly toggling between charging and discharging very often, and I don't think that's very good for the battery. Once it's charged it should stop charging as long as the charger is connected. (This might apply to other devices too.)

This was with version 2ef7a54-130111

Kurt

Hi there,

  this is another WIP plugin that I wrote last year.  It plays videogame streamed music
  using the UADE library.  Original homepage here: sourceforge.net/projects/vgmstream/

  I'm a bit new to git so please forgive me for not uploading a proper patch.

  To test the plugin, simply copy the rockstream folder to the plugins folder in
  rockbox sources.  And you have to extract the data.zip file in the .rockbox folder.

  The formats.db found in data.zip is basically a list with all vgmstream supported
  extensions (at least "all" by the time I wrote the plugin).  You can add  or remove 
  new or unwanted extensions there.  The plugin will only handle the extensions found
  in the formats.db.

  Currently the plugin works as a viewer plugin, and there is only one extension associated
  with the plugin in viewers.config for testing purposes, but you can always use the 
  'open with' option from rockbox.  Once you open a file the plugin will parse all supported
  files found in the same folder.

  The vgmstream project is updated quite often, if someone wants to
  update the core library, I believe that would be very easy, since I only changed a couple
  of things to it.

  I'm not going to work on this anymore, so I decided to upload it here, and hope someone
  can make a proper patch and maybe some dev would be interested in testing it, make 
  the necessary changes and upload an stable release.

  As a last comment, I have only tested the plugin in the simulator, samsungypr0, fuze+
  and ipod nano. It only worked in the simulator and samsungypr0, so hope someone can 
  fix that.

  Please read the README file for some additional info about the plugin.

  Working on:  simulator and samsungypr0
  Commid ID: e1ea08417bca57c607df6686472fa0a86f38b6d1

Version: 3.13

Variable ‘tmp’ on line 565 is possibly not initialised (found by cppcheck).

The filename cover.jpg works ok. But {album}-{artist}.jpg doesnt wokr. Also the albumart appears on the WPS, but not in the Pictureflow

When I connect my Sansa Clip Zip with most recent Rockbox version to my pc (Windows 8) while it’s paused or not playing a song at all, pc gives message ‘Device not recognized’.
When a song is playing, and I connect the player to the pc, the song will pause (expected behaviour of course), and I can access the internal and sd storage on the device.

After setting the “Charge During USB Connection” Rockbox setting to “no”, the battery in my iPod Classic still gets charged whenever connecting the iPod to my PC via USB. From the iPod Video manual:

“This option lets you control whether the player should charge during the USB connection and hence draw the full 500 mA. Turning it Off is recommended if the player is connected through an unpowered USB hub or a laptop port.”

I would expect the battery NOT to get charged. Running Rockbox dev build 9576134.

when i pressed the fm radio it’s. but when i press off it sounds like it’s still on and beeping. i’ve got all the settings of for beeping and it’s still on the fm radion i mean. this weird bug i know. please do fix this bug thanks

First, thanks for existing …

I just bought a 8GB Sansa Clip+ and had issues when trying to listen 24 bit Flacs, which was instantly solved using RockBox. Well, the issue I’d like to report is that it freezes when I plug it into my Mac while having the SD card on it; to avoid this I have to remove the SD card, but this is kind of unconfortable.

Any advise?

Thanks in advance

Pure i20 does not charge the iPod classic with OS rockbox.
I feel like Rockbox can not recognize interface pure i20 (drivers?)
Through Pure i20 will not play music even if it is in the installed Rockbox in the iPod.(only apple Flash = possible charging/playing via Pure i20)

I own Ipod classic 6G 160GB (flashed rockbox)

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;

When using the H300 non-lcd remote to turn on the player (iriver H340) I get the following error message “hold switch on, power off…” (the hold switch is not on).

The Idle Poweroff only reboots my 1G iPod. I assume it should power it off or put it into a power saving mode. This forces it to use up the battery faster then normal unless I set the Hold button to boot into the iPod firmware to do a proper suspend when Rockbox reboots.

I used the official toshiba updater to get an “original” fresh install on my beast and then attempted to run through the install procedure for a single boot rockbox install. After a (seemingly) sucessful install I’d end up in recover mode after any reboot.

Fatal error when attempting to install nk.bin (rockbox only bootloader) using sendfirm in Windows to an updated (v1.2) Gigabeat S player.

After install of both bootloader and rockbox the Gigabeat S, once rebooted, goes into recovery mode (toshiba) and requires an update/restore. This is the Number 3 Triangle.

Notes:
Gigabeat was first updated using the official toshiba MESV12US updater. “gbs_update_1_2_us.exe”

Using SVN revision 19741 to compile nk.bin under WinXP and Cygwin.
Using MTP.zip of 7/4/2008 found on the wiki to send over the bootloader.

I suspect most devs updated their bootloaders using the sendfirm utility *before/without* updating the entire player with the updater utility from toshiba. Thus they started from a v1.1 OF and never updated any part of that.

Maybe the updater changes something in the bootcode. I don’t know.

Build 21245

I have ''Start Screen' set to 'Resume Playback'.

When connecting the Ipod (from OFF) to the PC the Ipod boots and USB mode starts but also playback (the play > sign is display on the title bar).

The Ipod is not shows and not mounted on the PC.

On disconnecting USB I get 'data abort' and have to hard reset.

This isn't a big problem because the MR-100 won't turn on if the hold switch is already engaged.

But if the user turns on the MR-100 and then engages the hold switch while the M:Robe logo is on the screen, a "Hold switch is on Shutting down…" message is displayed, but it does not shut down.

A reset is required at this point - disengaging the hold switch and holding down the power button in this state does not shut down the MR-100.

   I've update my ipod nano 2G to r23629. I found the clickweel would remember the last point my finger leave. And next when I touch the clickwheel, it will make a farward/backward move according to the last point I left, even click the button. Now it is not convenient to type a word with the keyboard inside or setting.
   And my Mac doesn't launch my ipod when I connect my ipod with USB until I change to disk mode. Seems that the USB driver doesn't work.

H120 not starting original IRiver Firmware with LCD Remote holding Rec + Play Button both on LCD-Remote.

I am trying to use the last method mentioned on the ipodpatcher wiki page to write Rockbox directly into the OSOS image on my iPod Nano2G. Sometimes it works properly, but other times it fails saying that it couldn't read the header from the .ipodx file. I am following the instructions exactly, so that can't be an issue. I have tried hexediting the .ipodx file, and in some cases I can get ipodpatcher to read the header by editing the first four values, but this always causes a Checksum Error. Here is the exact output:

C:\Users\Michael Marley\Downloads>ipodpatcher.exe -wf rockbox.ipodx
ipodpatcher 5.0 with v4.0 bootloaders (v1.0 for 2nd Gen Nano)
(C) Dave Chapman 2006-2009
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

[INFO] Scanning disk devices… [INFO] Read XML info (4 bytes)
[INFO] Ipod found - 2nd Generation Nano ("winpod") - disk device 1
[INFO] Reading partition table from \\.\PhysicalDrive1
[INFO] Sector size is 2048 bytes
[INFO] Part Start Sector End Sector Size (MB) Type
[INFO] 0 63 48194 94.0 Empty (0x00)
[INFO] 1 48195 1982462 3777.9 W95 FAT32 (0x0b)
[INFO] Read XML info (4 bytes)
[INFO] Ipod model: 2nd Generation Nano ("winpod")
[ERR] Failed to read header from rockbox.ipodx
[ERR] –write-firmware failed.

I got no SD-Card support for my E-250 after boot into USB mode.
I plug in my powered off player into usb and only have access to internal storage.

If i plug in my player booted up there is no problem.

I am using daily build r29174-110131.

Since r30937, the e200v2 bootloader is too large and mkamsboot errors with:

[ERR] Packed data (120926 bytes) doesn't fit in the firmware (120860 bytes)

Steps to reproduce:
1. build e200v2 bootloader
2. cd to rbutil/mkamsboot
3. run make to create the mkamsboot utility
4. run mkamsboot <path-to-e200pa.bin> <path-to-bootloader-e200v2.sansa> <path-to-output.bin>

Rockbox Info: Version: 3.12

Device: iRiver H140, 80GB Toshiba MK8009GAH 8mm 1.8" IDE HDD 8mm

BUG: Repeatable, Consistent.

Additional Information:
1. To verify that I had a good installation of the 3.12 version of the Rockbox firmware working, I have reformatted, and re-flashed rockbox 3.12 two seperate times after initially encountering this, duplicating this behavior. So it doesn't seem to be a bad firmware flash.

Expected Behavior:

1. Player should Power On and boot properly every single time the bootup sequence is initiated correctly (Play Button pressed when Player is in a Powered Off state).

Buggy Behavior:

1. Player Powers Up, then locks up (i.e. "crashes") during bootloader sequence, requiring a hard reset, and upon second boot, finally Powers On and boots properly, bringing up a functional session of the Main User Interface. This is repeatable, and consistent.

Bug Symptoms & How To Repeat:

1. Consistently the Player will lock up during first "boot" sequence. The bootloader will usually reach the text stage, and sometimes crash here. Sometimes the bootloader will get through the text stage and reach the Rockbox Logo and then crash here. The Main User Interface is never reached upon first "boot" sequence.

2. The result of the first "boot" lockup (i.e. "crash") requires that I reset the Player by inserting a paperclip into the Reset hole (on the bottom plate of the Player) and triggering the button hidden in there. This Powers Down the Player, and Resets the Firmware, leaving the Player ready to be Powered On again.

3. Upon the second "boot", the Player will "boot" and the bootloader will make it past the text stage, the Rockbox Logo stage, and then spin up the HDD properly; the bootloader will not lock up the firmware, and behaves 'normally', finally resulting in a completed boot up sequence with the Main User Interface coming up (as a user would expect). The Player is now ready to use.

Alarm wakeup doesn’t work reliably. It is unclear whether the setup is wrong or the wake up is. It might be that the player wakes up before time because of a small press on the power button and thus somehow forgets about alarm.

Hi,

There is a compilation problem when the environment variable BLOCK_SIZE is set. It gave me errors about a comma.

This can be set or cleared systematically or on a command by command basis.

Suggestion one; unset BLOCK_SIZE and its relatives high in the build chain, but be prepared for POSIX to bite with 512 byte blocks.

Suggestion two; set LS_BLOCK_SIZE=1 high in the build chain. (And DF_BLOCK_SIZE=1024 and DU_BLOCK_SIZE=1024 ?)

Suggestion three; edit apps/lang/Makefile so that

$(SILENT)echo “#define MAX_LANGUAGE_SIZE `ls -ln $(OBJDIR)/* | awk ‘{print $$5}’ | sort -n | tail -1`” > $(HEADER)

becomes

$(SILENT)echo “#define MAX_LANGUAGE_SIZE `ls -ln –block-size=1 $(OBJDIR)/* | awk ‘{print $$5}’ | sort -n | tail -1`” > $(HEADER)

or

$(SILENT)echo “#define MAX_LANGUAGE_SIZE `LS_BLOCK_SIZE=1 ls -ln $(OBJDIR)/* | awk ‘{print $$5}’ | sort -n | tail -1`” > $(HEADER)

Suggestion four; just tell people that they are not allowed to have commas in their core utilities output (and be prepared to be bitten badly if the default block size ever changes).

BTW I *like* having thousands separators on my command line, so I have

export BLOCK_SIZE=\'1
export DF_BLOCK_SIZE=\'M

in my /etc/bashrc file.

The H10 5G MTP needs a different bootloader than the UMS version (see http://www.rockbox.org/twiki/bin/view/Main/IriverH10PortDevInfo#Build_a_Rockbox_Bootloader).
I’m not sure about the correct way to do this in configure, so I’ll leave it to someone who is.

The uisimulator cannot be build by using the source of the latest version on MinGW.

I send this bug’s patch.

It is necessary to apply the patch of FS#10021 to build the firmware on MinGW.

Tested at r29689, gcc 3.4.4. When trying to create a voice file in Cygwin, the following comes out (taken from STDERR):
librbspeex.a(rbspeex.o):rbspeex.c:(.text+0x453): undefined reference to `_speex_nb_mode'
librbspeex.a(rbspeex.o):rbspeex.c:(.text+0x45a): undefined reference to `_speex_wb_mode'
librbspeex.a(rbspeex.o):rbspeex.c:(.text+0x462): undefined reference to `_speex_encoder_init'
librbspeex.a(rbspeex.o):rbspeex.c:(.text+0x490): undefined reference to `_speex_bits_init'
librbspeex.a(rbspeex.o):rbspeex.c:(.text+0x4b9): undefined reference to `_speex_encoder_ctl'
librbspeex.a(rbspeex.o):rbspeex.c:(.text+0x4d9): undefined reference to `_speex_encoder_ctl'
librbspeex.a(rbspeex.o):rbspeex.c:(.text+0x4f6): undefined reference to `_speex_encoder_ctl'
librbspeex.a(rbspeex.o):rbspeex.c:(.text+0x513): undefined reference to `_speex_encoder_ctl'
librbspeex.a(rbspeex.o):rbspeex.c:(.text+0x527): undefined reference to `_speex_encoder_ctl'
librbspeex.a(rbspeex.o):rbspeex.c:(.text+0x5fd): undefined reference to `_speex_resampler_init'
librbspeex.a(rbspeex.o):rbspeex.c:(.text+0x609): undefined reference to `_speex_resampler_skip_zeros'
librbspeex.a(rbspeex.o):rbspeex.c:(.text+0x6ac): undefined reference to `_speex_resampler_process_int'
librbspeex.a(rbspeex.o):rbspeex.c:(.text+0x6fc): undefined reference to `_speex_encode_int'
librbspeex.a(rbspeex.o):rbspeex.c:(.text+0x724): undefined reference to `_speex_bits_write_whole_bytes'
librbspeex.a(rbspeex.o):rbspeex.c:(.text+0x7c0): undefined reference to `_speex_bits_write'
librbspeex.a(rbspeex.o):rbspeex.c:(.text+0x81d): undefined reference to `_speex_encoder_destroy'
librbspeex.a(rbspeex.o):rbspeex.c:(.text+0x829): undefined reference to `_speex_bits_destroy'
librbspeex.a(rbspeex.o):rbspeex.c:(.text+0x83d): undefined reference to `_speex_resampler_destroy'
collect2: ld returned 1 exit status
make[2]: * [../rbspeexenc] Error 1
make[1]: * [rbspeexenc] Error 2
make: *** [voicetools] Virhe 2

When I try to build rockbox, I get the following error:

=⇒ make: execvp: /bin/sh: Argument list too long
⇐=

My build path is a fairly long path. Building it at a location with shorter path it works. Details:

Steps to reproduce:

* Create a location where you want to have the sources; use a fairly long path name, e.g.

  mkdir -p /home/myuser/download/mediaplayer_hardware/SanDisk/Sansa_Fuze_v2/rockbox/firmware/source/

* Change to that directory:

  cd /home/myuser/download/mediaplayer_hardware/SanDisk/Sansa_Fuze_v2/rockbox/firmware/source/

* Download git sources (Tried with version from 2014-09-22, 10:55:11 GMT+1, Commit by "Marcin Bukat marcin.bukat@gmail.com", Change-Id: "Ie3aa9b208e3f4f17d4d02f11f69839e9b381217d") to a long path:

  git clone git://git.rockbox.org/rockbox 

* Make a build directory and change into it:

  mkdir -p /home/myuser/download/mediaplayer_hardware/SanDisk/Sansa_Fuze_v2/rockbox/firmware/source/build_FuzeV2
  cd /home/myuser/download/mediaplayer_hardware/SanDisk/Sansa_Fuze_v2/rockbox/firmware/source/build_FuzeV2

* Configure the build:

  ../rockbox/tools/configure --target=63 --type=N

prodces the output

==>

Using temporary directory /tmp
Platform set to sansafuzev2
Normal build selected
Using source code root directory: /home/myuser/download/mediaplayer_hardware/SanDisk/Sansa_Fuze_v2/rockbox/firmware/source/rockbox
Using arm-elf-eabi-gcc 4.4.4 (404)
Using arm-elf-eabi-ld 2.20.1.20100303
Found and uses ccache (/sbin/ccache)
Automatically selected arch: arm (ver 5)
Created Makefile

<==

* Running "make":

  make

produces the output

==>

Generating dependencies
make: execvp: /bin/sh: Argument list too long
make: *** No rule to make target '/home/myuser/download/mediaplayer_hardware/SanDisk/Sansa_Fuze_v2/rockbox/firmware/source/build_FuzeV2/make.dep', needed by 'all'. Stop.

<==

and returns with exit code 2.

Workaround:

Building it in a directory with shorter path, e.g. doing everything in "/tmp", works.

But that is only a workaround; it should not fail when building in arbitrary locations, and especially not with a message not making it clear _what_ the underlying problem ist. (I had to do a long internet search to get to the idea that the build place can be the problem).

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

Trying to cross-compile GCC for the ipod with GCC 9.2 I keep running into errors:

In file included from ../../gcc-4.4.4/gcc/diagnostic.h:25,

               from ../../gcc-4.4.4/gcc/tree-mudflap.c:43:

../../gcc-4.4.4/gcc/pretty-print.h: At top level:
../../gcc-4.4.4/gcc/pretty-print.h:310:6: error: ‘cgraph_node’ is not defined as a type

310 |      ATTRIBUTE_GCC_PPDIAG(2,3);
    |      ^~~~~~~~~~~~~~~~~~~~

This would seem to be the same issue as the one described on https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90677

The attached patch against GCC seems to fix the problem for me.

RB does not play AC3 tracks which were extracted from DVD with splitting one-track/one-song (splitting by chapters).

In other words - if you extract single AC3 song RB will not be able to play it back, despite the fact foobar2000 and Winamp with AC3Filter plugin will play it fine.

It is not a problem related to extracting software as the problem occurs for AC3 files saved by DVD Audio Extractor and SmartRipper. (Files saved by them are bit-bit the same as file comparison showed).

Simulator does not display any debugging info when you try to play AC3 file which RB is unable to play.

AC3 playback is not completely broken because RB plays AC3 files if you extracted full AC3 track without splitting it.

When you play back a broken flac file (in this case a file that was truncated) it can happen that he decoder outputs constant loud noise instead of just skipping to the next track.

I’m not sure if this is really a bug since you are not supposed to play back broken files.

Attached is a file where this happens.

H300 r18009 (happens in the uisim too).

I have only tested this on my H120 with an 18007 build. I have been using the APE codec for some time now and never had a problem in the past.

After reformatting my hard drive and installing the current build I found that rockbox has 2 problems with my APE files

1. The parser for APE files no longer recognizes my APE files encoded with version 8,9 of Jriver Media Center. Result is that files don't play when selected in the file browser and these files do net get added to the database.

2. When switching APE tracks one of two possible behavior occur. a) the Iriver freezes completely. b) On switching tracks there is a loud hiss and then playback of the next track resumes.

Cheers

  Thomas