Recent Posts
1
Hardware / Re: Does battery estimation take in account power settings
« Last post by speachy on Today at 07:06:28 PM »QUESTION 1
Does anyone know how accurate the
%bv The battery level in volts
and or the
%bl
are?
I would imagine it would just keep going lower show less of a value, but on occassion I have noticed the value also going up as if the battery is magically being charged
%bv is what the hardware reports. %bl is computed by first looking up the voltage in a table, and linearly interpolating.
(Note there are exceptions here; some hardware with a "smart" PMIC only reports the battery percentage instead of a voltage)
The reason you see it go back up sometimes is that the measured battery voltage is affected by the load on said battery. Spinning up the hard drive is particularly heavy; this is why rockbox has a "critical battery level" threshold under which it won't try to spin up the storage (eg to save playback state) as that could corrupt data or crash the device outright.
QUESTION 2
So as far as I know, the estimation is based on what "Battery Capacity" setting is choosen, for example 550mAh.
Runtime estimation is the battery state of charge times battery capacity in mah divided by the run current for the device.
Runtime estimation is just that, an estimation. It takes the configured battery capacity and percentage level to compute a "X mAh remaining" value. It then divides that by the estimated power consumption *at that exact time* (ie does not try to do any sort of usage pattern analysis). What goes into this consumption estimate depends on the individual device, but typically takes into account: (a) the baseline idle power consumption, (b) if the display is on, and (c) if the storage device is active. The power consumption numbers for each of those situations can vary widely in accuracy; they may be taken from datasheets, measured carefully in a controlled setting, simply guessed at, or in some cases, supplied by the hardware in realtime.
This can be made as fine-grained as one would like, it's just a matter of carefully measuring the current in isolation.
Further details can be found in firmware/powermgmt.c, in the battery_current() function.
2
Hardware / Re: Does battery estimation take in account power settings
« Last post by questions2000 on Today at 06:28:49 PM »(Might not be worth reading)
I mentioned above that I had already typed out a post before realizing that there was another reply with these instructions.
Because already typed, I figured I might as well post, still some info that would be good to know.
@saratoga / anyone else interested
Thank you for reply.
Sorry I did not realize there were two different indicators available, all the themes I have tested I believe just have shown the "battery state of charge" based on your description. So this is the battery indication that I was referencing in my question, so now my question probably does not make as much sense because I guess it was more based on "runtime estimation" rather than "battery state of charge"
Also apologize the following reply is going to be a bunch of random information I have come across.
IPOD FIRMWARE
I imagine this is similar what the orginal iPod firmware uses for battery indication, which was just a picture of battery outline with a fill inside giving a general indication of how much power currently available, but this was not very accurate (in my opinion) just a visual.
3RD PARTY THEME BATTERY METER
However the theme I was testing not only includes battery graphic meter, but it also includes an actual number percentage value, for example "85%". To me this is more of a helpful indication (if it is accurate).
Here are some items I narrowed down from that theme regarding the battery
I thought it was the following variable mentioned in the manual
%bv The battery level in volts
but I think it is using this variable instead
%bl
also here is the estimation variable you had mentioned, I do not see this one in the themes code
%bt Estimated battery time left
I would be curious to see how this variable displays / how accurate this would be.
Wonder if this one would be more informative then the volt percentage.
QUESTION 1
Does anyone know how accurate the
%bv The battery level in volts
and or the
%bl
are?
(I might be looking at this incorrectly also? not that familiar with how voltage works, anyways)
Reason I ask this is because the battery power value ##% shown in theme seems to adjust in both directions often.
I would imagine it would just keep going lower show less of a value, but on occassion I have noticed the value also going up as if the battery is magically being charged
------------------------------------------------------------------------------------
QUESTION 2
Might as well ask this again then just for curiosity.
Lets say user/theme uses this variable which is "runtime estimation"
%bt Estimated battery time left
So as far as I know, the estimation is based on what "Battery Capacity" setting is choosen, for example 550mAh.
Does anyone know if any of the following settings are taken into account by the "runtime estimation"?
-Backlight = Off
-Display = Sleep when Backlight is Off
-Brightness = Lower values
-Accessory Power Supply = Off
etc.
Meaning for example does turning "off" backlight completely alter the battery estimation shown in the battery meter?
Or is the estimation a static setting based only on the size battery choosen in the "Battery Capacity" setting section?
Or is it just exactly what developer saratoga has mentioned
Runtime estimation is the battery state of charge times battery capacity in mah divided by the run current for the device.
Thank You to anyone who reads all of this.
I mentioned above that I had already typed out a post before realizing that there was another reply with these instructions.
Because already typed, I figured I might as well post, still some info that would be good to know.
@saratoga / anyone else interested
Thank you for reply.
Sorry I did not realize there were two different indicators available, all the themes I have tested I believe just have shown the "battery state of charge" based on your description. So this is the battery indication that I was referencing in my question, so now my question probably does not make as much sense because I guess it was more based on "runtime estimation" rather than "battery state of charge"
Also apologize the following reply is going to be a bunch of random information I have come across.
IPOD FIRMWARE
I imagine this is similar what the orginal iPod firmware uses for battery indication, which was just a picture of battery outline with a fill inside giving a general indication of how much power currently available, but this was not very accurate (in my opinion) just a visual.
3RD PARTY THEME BATTERY METER
However the theme I was testing not only includes battery graphic meter, but it also includes an actual number percentage value, for example "85%". To me this is more of a helpful indication (if it is accurate).
Here are some items I narrowed down from that theme regarding the battery
Code: [Select]
# Numeric Power %
%V(164,168,38,10,0)%Vf(cccccc)%Vb(000000)
%ac%bl%%Code: [Select]
%xl(B,batt.bmp,0,0,9)
%V(164,186,44,47,-)
%t(1)%?bp<%?bc<%xd(Bh)|%xd(Bi)>|%?bl<||%xd(Ba)|%xd(Bb)|%xd(Bc)|%xd(Bd)|%xd(Be)|%xd(Bf)|%xd(Bg)|%xd(Bg)>>;%t(1)%?bp<%?bc<%xd(Bg)|%xd(Bi)>|%?bl<||%xd(Ba)|%xd(Bb)|%xd(Bc)|%xd(Bd)|%xd(Be)|%xd(Bf)|%xd(Bg)|%xd(Bg)>>I thought it was the following variable mentioned in the manual
%bv The battery level in volts
but I think it is using this variable instead
%bl
also here is the estimation variable you had mentioned, I do not see this one in the themes code
%bt Estimated battery time left
I would be curious to see how this variable displays / how accurate this would be.
Wonder if this one would be more informative then the volt percentage.
QUESTION 1
Does anyone know how accurate the
%bv The battery level in volts
and or the
%bl
are?
(I might be looking at this incorrectly also? not that familiar with how voltage works, anyways)
Reason I ask this is because the battery power value ##% shown in theme seems to adjust in both directions often.
I would imagine it would just keep going lower show less of a value, but on occassion I have noticed the value also going up as if the battery is magically being charged
------------------------------------------------------------------------------------
QUESTION 2
Might as well ask this again then just for curiosity.
Lets say user/theme uses this variable which is "runtime estimation"
%bt Estimated battery time left
So as far as I know, the estimation is based on what "Battery Capacity" setting is choosen, for example 550mAh.
Does anyone know if any of the following settings are taken into account by the "runtime estimation"?
-Backlight = Off
-Display = Sleep when Backlight is Off
-Brightness = Lower values
-Accessory Power Supply = Off
etc.
Meaning for example does turning "off" backlight completely alter the battery estimation shown in the battery meter?
Or is the estimation a static setting based only on the size battery choosen in the "Battery Capacity" setting section?
Or is it just exactly what developer saratoga has mentioned
Runtime estimation is the battery state of charge times battery capacity in mah divided by the run current for the device.
Thank You to anyone who reads all of this.
3
Hardware / Re: Does battery estimation take in account power settings
« Last post by questions2000 on Today at 06:25:41 PM »@Bilgus
Again another great post with great information, I was not aware that there was a solution for iPod batteries.
Thank you for this
I have not tried this out yet.
I was not expecting this question to lead to something that would need to be tested.
I have to pick the right time to perform this test.
Right now have been have been trying to figure out some things about themes.
Then I have to make sure to apply any settings desired and start with fresh setup.
This way can get as accurate of a result as possible.
Again another great post with great information, I was not aware that there was a solution for iPod batteries.
Thank you for this
I have not tried this out yet.
I was not expecting this question to lead to something that would need to be tested.
I have to pick the right time to perform this test.
Right now have been have been trying to figure out some things about themes.
Then I have to make sure to apply any settings desired and start with fresh setup.
This way can get as accurate of a result as possible.
4
Feature Ideas / Re: GUI Sounds - Offering sounds for specific actions
« Last post by questions2000 on Today at 06:24:16 PM »Thank you
True, but if not using the voice prompts option, some kind of sound effect could be helpful to some users.
Again Startup may not be as important because device is "on" and any navigation right after will let user know the device is "on", Shutdown would mainly benefit from this, but again just mentioned Startup as well because they are kind of a pair.
True, but if not using the voice prompts option, some kind of sound effect could be helpful to some users.
Again Startup may not be as important because device is "on" and any navigation right after will let user know the device is "on", Shutdown would mainly benefit from this, but again just mentioned Startup as well because they are kind of a pair.
5
Feature Ideas / Re: Menu Tweaks - Capitalizing some Settings menu items
« Last post by questions2000 on Today at 06:21:08 PM »@speachy
Thank you for really looking into this, I know you did because the ones you choose to update were the main ones I would have updated as well.
I know the other ones I mentioned were against "the rules" of title case, the only reason I mentioned them is because in context of small device screens / them being used in a list view (item after item), having each beginning letter capitialzed would make each list item more defined amongst the list.
But again, I agree, you updated the main ones that I think required the updating.
Also, thank you for making these updates in general.
Thank you for really looking into this, I know you did because the ones you choose to update were the main ones I would have updated as well.
I know the other ones I mentioned were against "the rules" of title case, the only reason I mentioned them is because in context of small device screens / them being used in a list view (item after item), having each beginning letter capitialzed would make each list item more defined amongst the list.
But again, I agree, you updated the main ones that I think required the updating.
Also, thank you for making these updates in general.
6
Feature Ideas / Re: Sorting in Files section - Make filenames sort same way as folders do
« Last post by questions2000 on Today at 06:10:52 PM »@bahus
Is that what it is? I had actually run into something like this in the past with Linux sorting, where the dot of the extension did something similar.
I did not even think about this being the issue in RB.
I mean I still prefer filenames to sort the same as how folders currently do, but at least there is a reason for why this occurs.
@bahus
Wow, thank you for doing this.
In the past I had to download the source code for something but I think it was from a different site.
I was not aware of Rockbox using the site you mentioned (Gerrit Code Review)
You mentioned/I saw your post also includes dot folders at top.
When I am viewing on a Linux machine, I think dot folders do show up at top, but that is default behavior of Linux so not sure if it is my file manager/Linux doing this or if Rockbox on device does this as well or not?
But makes sense to me I agree with dot folders (hidden folders) being above all other non dot prefixed folders if they do not do this currently.
Not sure if this will get added, but I really appreciate you putting it in a place where maybe more developers will see this.
I'll keep an eye out in the future to see if this gets added.
Thank you again for doing this.
Is that what it is? I had actually run into something like this in the past with Linux sorting, where the dot of the extension did something similar.
I did not even think about this being the issue in RB.
I mean I still prefer filenames to sort the same as how folders currently do, but at least there is a reason for why this occurs.
@bahus
Wow, thank you for doing this.
In the past I had to download the source code for something but I think it was from a different site.
I was not aware of Rockbox using the site you mentioned (Gerrit Code Review)
You mentioned/I saw your post also includes dot folders at top.
When I am viewing on a Linux machine, I think dot folders do show up at top, but that is default behavior of Linux so not sure if it is my file manager/Linux doing this or if Rockbox on device does this as well or not?
But makes sense to me I agree with dot folders (hidden folders) being above all other non dot prefixed folders if they do not do this currently.
Not sure if this will get added, but I really appreciate you putting it in a place where maybe more developers will see this.
I'll keep an eye out in the future to see if this gets added.
Thank you again for doing this.
7
Repairing and Upgrading Rockbox Capable Players / Re: XDUOO xiii repair
« Last post by silverbear on Today at 08:08:16 AM »I don't have the necessary skills & was hoping for a contact for someone who did. Sounds like I need a new player.
Thanks for the reply. Appreciated.
8
Audio Playback, Database and Playlists / Re: Rockbox 4.0 - Album Artist changed behaviour
« Last post by HandUndFuss on May 17, 2025, 03:41:45 PM »Thank you guys. Thanks also for the patch.
I realize my and OPs message is the typical "It used to work for me!" use case regression where you could argue our approach is wrong. Unfortunately with music tagging what's 'perfect practice' is a bit up in the air. Some people say the AA field is not necessary if Artist is consistent across the album, but not all players work like this. Having the AA field always present is certainly the idiot proof approach. I'm considering masstagging my music archive to be done with it, but getting this right is a bit of a risk in case something doesn't work.
Here's how it can be done with the foobar2000 Masstagger plugin. There may be breakage if individual tracks of an album have an AA tag that deviates from the newly written tag, for some reason. What this does exactly is check if the Album Artist tag is empty, and if the Album tag exists. Both being the case, it will copy the Artist tag to Album Artist.
Select "Format value from other fields"
Destination field: ALBUM ARTIST
Formatting pattern: $if2(%album artist%,$if(%album%,$if(%artist%,%artist%,),))
For now, and this can also be done, I'll mount the rockbox iPod's entire archive and masstag that one, see how it looks. Edit: It works.
I realize my and OPs message is the typical "It used to work for me!" use case regression where you could argue our approach is wrong. Unfortunately with music tagging what's 'perfect practice' is a bit up in the air. Some people say the AA field is not necessary if Artist is consistent across the album, but not all players work like this. Having the AA field always present is certainly the idiot proof approach. I'm considering masstagging my music archive to be done with it, but getting this right is a bit of a risk in case something doesn't work.
Here's how it can be done with the foobar2000 Masstagger plugin. There may be breakage if individual tracks of an album have an AA tag that deviates from the newly written tag, for some reason. What this does exactly is check if the Album Artist tag is empty, and if the Album tag exists. Both being the case, it will copy the Artist tag to Album Artist.
Select "Format value from other fields"
Destination field: ALBUM ARTIST
Formatting pattern: $if2(%album artist%,$if(%album%,$if(%artist%,%artist%,),))
For now, and this can also be done, I'll mount the rockbox iPod's entire archive and masstag that one, see how it looks. Edit: It works.
9
Hardware / Re: New cheap portable player in the market
« Last post by pmp4 on May 17, 2025, 12:41:18 PM »it seems smartlink based players use LVGL library to render the user interface.
https://lvgl.io/
https://github.com/lvgl/lvgl
You can see same filenames in lvgl source code
https://github.com/lvgl/lvgl/blob/master/src/core/lv_obj.c
and so on.
Code: [Select]
strings dump-round18usbc-yp3_2.0.43.bin | grep 133
F:\pen133_yp3_mp\spark2\src\gui8\lvgl\src\core\lv_disp.c
F:\pen133_yp3_mp\spark2\src\gui8\lvgl\src\core\lv_event.c
F:\pen133_yp3_mp\spark2\src\gui8\lvgl\src\core\lv_group.c
F:\pen133_yp3_mp\spark2\src\gui8\lvgl\src\core\lv_indev.c
F:\pen133_yp3_mp\spark2\src\gui8\lvgl\src\core\lv_obj.c
F:\pen133_yp3_mp\spark2\src\gui8\lvgl\src\core\lv_obj_class.c
F:\pen133_yp3_mp\spark2\src\gui8\lvgl\src\core\lv_obj_pos.c
F:\pen133_yp3_mp\spark2\src\gui8\lvgl\src\core\lv_obj_style.c
F:\pen133_yp3_mp\spark2\src\gui8\lvgl\src\core\lv_obj_tree.c
F:\pen133_yp3_mp\spark2\src\gui8\lvgl\src\core\lv_refr.c
F:\pen133_yp3_mp\spark2\src\gui8\lvgl\src\draw\lv_draw_img.c
F:\pen133_yp3_mp\spark2\src\gui8\lvgl\src\draw\lv_draw_label.c
F:\pen133_yp3_mp\spark2\src\gui8\lvgl\src\draw\lv_draw_mask.c
F:\pen133_yp3_mp\spark2\src\gui8\lvgl\src\draw\lv_draw_rect.c
F:\pen133_yp3_mp\spark2\src\gui8\lvgl\src\draw\lv_img_cache.c
F:\pen133_yp3_mp\spark2\src\gui8\lvgl\src\draw\lv_img_decoder.c
F:\pen133_yp3_mp\spark2\src\gui8\lvgl\src\extra\layouts\flex\lv_flex.c
F:\pen133_yp3_mp\spark2\src\gui8\lvgl\src\extra\widgets\chart\lv_chart.c
F:\pen133_yp3_mp\spark2\src\gui8\lvgl\src\hal\lv_hal_disp.c
F:\pen133_yp3_mp\spark2\src\gui8\lvgl\src\hal\lv_hal_indev.c
F:\pen133_yp3_mp\spark2\src\gui8\lvgl\src\misc\lv_anim.c
F:\pen133_yp3_mp\spark2\src\gui8\lvgl\src\misc\lv_color.c
F:\pen133_yp3_mp\spark2\src\gui8\lvgl\src\misc\lv_fs.c
F:\pen133_yp3_mp\spark2\src\gui8\lvgl\src\misc\lv_mem.c
F:\pen133_yp3_mp\spark2\src\gui8\lvgl\src\misc\lv_style.c
F:\pen133_yp3_mp\spark2\src\gui8\lvgl\src\misc\lv_timer.c
F:\pen133_yp3_mp\spark2\src\gui8\lvgl\src\misc\lv_tlsf.c
F:\pen133_yp3_mp\spark2\src\gui8\lvgl\src\misc\lv_txt.c
F:\pen133_yp3_mp\spark2\src\gui8\lvgl\src\widgets\lv_btnmatrix.c
F:\pen133_yp3_mp\spark2\src\gui8\lvgl\src\widgets\lv_dropdown.c
F:\pen133_yp3_mp\spark2\src\gui8\lvgl\src\widgets\lv_img.c
F:\pen133_yp3_mp\spark2\src\gui8\lvgl\src\widgets\lv_label.c
F:\pen133_yp3_mp\spark2\src\gui8\lvgl\src\widgets\lv_roller.c
F:\pen133_yp3_mp\spark2\src\gui8\lvgl\src\widgets\lv_textarea.c
F:\pen133_yp3_mp\spark2\src\gui8\lvgl\src\draw\lv_draw_blend.c
F:\pen133_yp3_mp\spark2\src\middleware\audio_crab\core\crab_pin.c
https://lvgl.io/
https://github.com/lvgl/lvgl
You can see same filenames in lvgl source code
https://github.com/lvgl/lvgl/blob/master/src/core/lv_obj.c
and so on.
10
Audio Playback, Database and Playlists / Re: Rockbox 4.0 - Album Artist changed behaviour
« Last post by amachronic on May 17, 2025, 05:58:26 AM »There was quite a bit of argument about what the "correct" behavior should be when the change to album artist behavior was proposed. Ultimately I accepted the patch for three reasons: (1) I agreed that the old way of inferring album artist from artist was problematic for specific tagging schemes; (2) it did not seem useful for dealing with arbitrary input from users who don't maintain their tags; (3) it only changes behavior when the album artist tag is blank/missing.
Personally I think leaving tags blank as a way to convey meaning is asking for trouble because you're forcing software to infer the content of missing tags from other tags, and there isn't a single rule that works for everyone because there is no widespread agreement on how to interpret this kind of tagging scheme. Rockbox can certainly support different options, but at the moment this means adding settings you configure before building the database like Bilgus's patch. (I'm not at all opposed to that, but it's less than ideal from a UX point of view.)
What I recommend is to always explicitly populate all tags with the data you want. That way, Rockbox and pretty much every other piece of software will use and display that data correctly without any special configuration.
Personally I think leaving tags blank as a way to convey meaning is asking for trouble because you're forcing software to infer the content of missing tags from other tags, and there isn't a single rule that works for everyone because there is no widespread agreement on how to interpret this kind of tagging scheme. Rockbox can certainly support different options, but at the moment this means adding settings you configure before building the database like Bilgus's patch. (I'm not at all opposed to that, but it's less than ideal from a UX point of view.)
What I recommend is to always explicitly populate all tags with the data you want. That way, Rockbox and pretty much every other piece of software will use and display that data correctly without any special configuration.