Fiio M3k

[amachronic]

tjhoward180,
See if you can read the SD card by another means -- using a USB adapter, card reader slot, phone, etc. If you can browse the fileystem from Rockbox, that shows the M3K has no issues reading the SD card. If the problem only shows up with USB connection, try using another USB cable and see if it's just a bad cable issue.

By the way, I'm not sure what you mean by a "version to match 1.3.0." Unless you are talking about the XVortex builds? Those are pretty outdated, in case you didn't know we have an officially supported native port now.

[tjhoward180]

Ah! So, to get things back in a stable place again, I did use an external reader to put an older firmware on - once that was installed, Windows was able to read the SD card.

Also, I didn't know there was an official port @amachronic! Thanks for informing this dummy. I've been in this forum a bunch, and hadn't realized it. I'll try the native port out now.

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