mirror of
https://github.com/Rockbox/rockbox.git
synced 2026-07-10 13:29:52 -04:00
a824085057
%pP reports playlist progress by position index, which treats every track as equally long. For playlists with tracks of unequal length -- audiobooks with chapters anywhere from two minutes to an hour are the motivating case -- position is a poor proxy for listening progress. %pX reports the played percentage of the whole playlist by time: the summed length of all preceding tracks plus the elapsed time in the current one, relative to the playlist's total duration. It can be used as a value, in a conditional, with %if(), or as a bar tag like %pb. If a playlist contains more than 500 tracks or the scan is taking too long and the user aborts the tag will fallback to the behavior of %pP except the progress through the current track will be included in the returned percentage -------------------------------------- Computing this needs every track's length, and reading metadata for every track is too slow and disk-heavy for a tag that refreshes on the WPS. Instead each track's length is estimated from its file size: the skin engine scans the playlist in the background, a batch of files each skin refresh, opening each file only to read its size (directory metadata, no header parse). Size is turned into time by calibrating one file of each type -- the first file of each extension is parsed once with get_metadata to learn its bytes-per-second, and every later file of that type reuses it. A single-format playlist, the usual audiobook case, parses exactly one file and stat's the rest. The result is an estimate -- bitrate varies within a type, especially for VBR -- but it is cheap and accurate enough for a progress indicator, and the playing track always contributes its exact elapsed time. Per-track lengths are stored as two bytes of minutes each in a movable buffer sized to the track count and allocated only while the tag is in use; the cache is keyed on the track count and a crc of the first, middle and last filenames, so a playlist swap or reshuffle is caught. If the buffer cannot be allocated (a very large playlist on a low-memory target) the tag falls back to position-based progress. The buffer is allocated when playback starts (and when the now-playing screen is opened with playback already active) rather than lazily on the first WPS refresh, so the one-time allocation happens at a playback boundary instead of during steady-state playback; it falls back to allocating on first use if that point is missed. Until the scan finishes the tag does not blank: it returns an instant equal-weight estimate -- (completed tracks + fraction through the current one) / track count -- which sharpens into the size-based value as the scan fills in. So a theme can just use %pX and it is correct from the first frame, and %?pX is true whenever a playlist is loaded. Tested on a Sansa Clip Zip and in the simulator. On a 216-track, ~745 MB single-format audiobook playlist the length scan dropped from ~4150 ms (get_metadata on every track) to ~174 ms (one parse plus 215 file-size stats), roughly 24x lighter. Change-Id: I6e572e78a10444bd513ddc77e30da04aa5153ef2 |
||
|---|---|---|
| android | ||
| apps | ||
| backdrops | ||
| bootloader | ||
| docs | ||
| firmware | ||
| fonts | ||
| icons | ||
| lib | ||
| manual | ||
| packaging | ||
| tools | ||
| uisimulator | ||
| utils | ||
| wps | ||
| .gitattributes | ||
| .gitignore | ||
| .gitreview | ||
__________ __ ___.
Open \______ \ ____ ____ | | _\_ |__ _______ ___
Source | _// _ \_/ ___\| |/ /| __ \ / _ \ \/ /
Jukebox | | ( <_> ) \___| < | \_\ ( <_> > < <
Firmware |____|_ /\____/ \___ >__|_ \|___ /\____/__/\_ \
\/ \/ \/ \/ \/
Build Your Own Rockbox
1. Clone 'rockbox' from git (or extract a downloaded archive).
$ git clone git://git.rockbox.org/rockbox
or
$ tar xJf rockbox.tar.xz
2. Create a build directory, preferably in the same directory as the firmware/
and apps/ directories. This is where all generated files will be written.
$ cd rockbox
$ mkdir build
$ cd build
3. Make sure you have mips/m68k/arm-elf-gcc and siblings in the PATH. Make sure
that you have 'perl' in your PATH too. Your gcc cross compiler needs to be
a particular version depending on what player you are compiling for. These
can be generated using the rockboxdev.sh script in the /tools/ folder of the
source.
$ which arm-elf-eabi-gcc
$ which perl
4. In your build directory, run the 'tools/configure' script and enter what
target you want to build for and if you want a debug version or not (and a
few more questions). It'll prompt you. The debug version is for making a
gdb version out of it. It is only useful if you run gdb towards your target
Archos.
$ ../tools/configure
5. *ploink*. Now you have got a Makefile generated for you.
6. Run 'make' and soon the necessary pieces from the firmware and the apps
directories have been compiled, linked and scrambled for you.
$ make
$ make zip
7. unzip the rockbox.zip on your music player, reboot it and
*smile*.
If you want to build for more than one target, just create several build
directories and create a setup for each target:
$ mkdir build-fuzeplus
$ cd build-fuzeplus
$ ../tools/configure
$ mkdir build-xduoox3
$ cd build-xduoox3
$ ../tools/configure
Questions anyone? Ask on the mailing list or on IRC. We'll be happy to help you!