Fiio M3k

[GSV3MiaC]

I'm running the native version from a few weeks back, but when I went to start the player today I got a 'committing database 1/9' message, and then the player turned off. Tried again and once it got as far as 2/9, but no further. Plugging into Win10 I get a device not recocnized / failed message. Suggestions for debugging welcome. I suppose the battery could be well down, but I can't boot far enough to see.

[amachronic]

Sounds like the database is in a bad state and you need to delete it -- delete all the database*.tcd files in the .rockbox folder. If you need to connect over USB you can either boot the OF (hold Play while booting) or use the Rockbox bootloader's USB mode (hold Volume Up and select USB mode from the menu).

I've run into database corruption and panics a few times, mostly due to playing music while the database is updating. I imagine these problems would occur on other ports but I haven't looked into it. My own workaround is simple: just never update the database. (and make sure auto-update is off; it should be by default.)

[Julian67]

I notice that when I change volume between -32 and -32.5 dB I hear a click.  Not at other levels.  It's fairly quiet and I suspect it might often pass unnoticed with louder music but it is readily apparent in quieter or simpler passages.  Is it the DAC moving to/from low power to full power?  In Rockbox settings I have the DAC power mode set to "High performance" and the roll off set to the default "sharp", in the general settings the Frequency is set to "Automatic".  I'm not using any EQ, dithering or other sound altering settings.

I have noticed this with all firmware versions I tried.  I'm on the latest one today.  I suspect it's a hardware thing and I'm not complaining!  But I am curious.  If it's a software thing then I guess it deserves a fix but basically I'm wondering what it is?

[amachronic]

Thanks for bringing it to my attention. The click might be due to hardware, but it's only getting triggered due to software -- the M3K has a very limited hardware volume range so I tried to make the most of it. At -32 dB the DAC's digital & analog volume controls are at their minimums so normally we'd need to use software volume to go lower. But the DAC's digital mixer has a divide by 2 mode which halves each sample, which is approximately a -6 dB volume adjustment. So at -32.5 dB, the divide by 2 mode is enabled and the digital volume is boosted up by +5.5 dB to compensate (the digital volume is still negative at -6.5 dB so there's no clipping involved).

The click is probably caused by one of two things:

• changing the mixer settings causes the click because the DAC doesn't protect against this
• the mixer setting and volume can't be set at exactly the same time, so there's a tiny interval where the volume is reduced by -6 dB before being boosted back up by 5.5 dB

Either way the fix is simply not abusing the digital mixer for volume control, and start using software volume at -32 dB instead of -38 dB. I don't think losing the extra -6 dB hardware range from the mixer is a big deal if it fixes the clicking.

[Julian67]

Thanks for the info, much appreciated.

[Julian67]

You fixed the click already! I tried today's firmware. No click! 

I'm trying to imagine FiiO responding to enquiries and bug reports like this.  Brain overheating.  Smoke from ears.

[amachronic]

Umm.. no. I haven't even gotten around to reproducing it myself yet!

[Julian67]

I saw your reply & checked again. It is still there. Yesterday I was using earphones with higher impedance and much less sensitivity & I couldn't hear it. This morning I went back to my usual earphones with extremely low impedance and high sensitivity...... *click* 

Anyway, I discovered a workaround 

[GSV3MiaC]

Sounds like the database is in a bad state and you need to delete it -- delete all the database*.tcd files in the .rockbox folder. If you need to connect over USB you can either boot the OF (hold Play while booting) or use the Rockbox bootloader's USB mode (hold Volume Up and select USB mode from the menu).

I've run into database corruption and panics a few times, mostly due to playing music while the database is updating. I imagine these problems would occur on other ports but I haven't looked into it. My own workaround is simple: just never update the database. (and make sure auto-update is off; it should be by default.)

Ah, the problem was actually the device was totally discharged after not being used for a couple of weeks. I guess RB doesn't completely shut it down. The database update completed OK once I got it charged - for some reason even plugging it in to a 2A charger didn't supply enough power fast enough to allow RB to complete the DB updates. Is the 'drains battery while supposedly off' a known problem?

[braewoods]

Rockbox generally shuts down fully if that is possible but it can only do so much. The hardware may have a higher standby current draw that Rockbox can do nothing about. Some ports have far better offline battery life due to these differences.

[SteveDave]

Ah, the problem was actually the device was totally discharged after not being used for a couple of weeks. I guess RB doesn't completely shut it down. The database update completed OK once I got it charged - for some reason even plugging it in to a 2A charger didn't supply enough power fast enough to allow RB to complete the DB updates. Is the 'drains battery while supposedly off' a known problem?

Amachronic posted previously about only charging at .1 amp.
"As a workaround you can set General Settings > System > Battery > Charge During USB connection to Force, it should force the full 500 mA charge rate."

Just to rule it out have you tried turning off the LCD timeout temporarily to make sure the device is actually powering off?

[cereal_killer]

I have some suggestions for the button layout. The Sansa Fuze+ has a similar touchpad and physical button combo, so I used this player as an inspiration. I had a look into writing patches, but this is way above my head, so I post my ideas here:

• The play/pause function is doubled by the physical button and the center of the touchpad. The physical button could be the only play/pause and "got to WPS" from anywhere in the menus.
• The center of the touchpad could be "go to file browser" and a long button press could be the context menu.
• The upper left touch button, that is the context menu right now could be set as "go to main menu" and a long press could be the quickscreen.
• Alternatively the upper right touch button could could alter between main menu and WPS.

Any thoughts?

[amachronic]

Ah, the problem was actually the device was totally discharged after not being used for a couple of weeks. I guess RB doesn't completely shut it down. The database update completed OK once I got it charged - for some reason even plugging it in to a 2A charger didn't supply enough power fast enough to allow RB to complete the DB updates. Is the 'drains battery while supposedly off' a known problem?

AFAIK the only standby current is 27 uA from the power management IC (axp192), plus whatever the RTC draws. Shutdown will force all other power supplies off. As long as RB sends the shutdown request to the axp192 the hardware should really be off.

Somebody already beat me to it and mentioned that 100 mA charging bug. The M3K can draw around 200 mA if maxed out, but I reviewed the code and axp192 datasheet, and I'm setting the limit on the charging current only, ie. how much the power IC will give to the battery. It should still draw additional power needed by the platform, on top of that 100 mA limit. So it shouldn't be a case of not supplying enough power to keep running.

(*facepalm* because that stupid bug still exists and now I see I didn't even limit the current properly.)

The only simple explanation I can think of is that RB noticed the battery was low but did not recognize that it was charging (for some reason), and decided to shut down forcibly. The power thread tries to ask nicely for a shutdown, but if the main thread does not respond quickly enough, it will force a shutdown and you won't get to see the usual battery low warning (I think). This is pure speculation, but I'd guess the database commit blocks the main thread so it can't respond in time.

[amachronic]

Hi all. It's been a while since I've made any major user visible improvements, but I've got one to announce today. Tomorrow's daily build will bring improved USB performance and reliability to the M3K (and Q1 / ErosQ native ports). The performance isn't yet on par with the OF, but I'm hoping to close that gap with an improved USB storage driver (based on the UASP protocol).

Also, there was a bug in the low-level timer setup code which I fixed. This shouldn't be a noticeable change, except for slightly shorter boot times, but it's possible some units might experience issues (possibly intermittently or at random). If anybody does start seeing buggy behavior after today's build I'd appreciate if they can report it, since it will likely be caused by this timer bugfix and only need a quick patch to fix.

[7o9]

amachronic, after upgrading the M3k to the build with your USB changes (rockbox-fiiom3k-20211017.zip), it shows the message 'Battery empty! RECHARGE!' immediately after start and shuts down.

The device charge, it runs the OF fine and shows a full battery icon.

Going back to the previous daily build (rockbox-fiiom3k-20211016.zip) makes it work fine.

This problem does not happen on the Shanling Q1 (rockbox-shanlingq1-20211017.zip) which boots fine.