| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
When replacing a dynamic playlist with Play Shuffled, the current
track could incorrectly be left at the end of the new playlist.
Fix this - the current track should always be at the beginning,
so it can be skipped past regardless of the repeat/shuffle mode.
Change-Id: Ia86539bc23ad8ebd714b8dc50b5720671b4ad0a9
|
|
Add a setting that makes Play and Play Shuffled in the playlist
context menu leave the current song (if any) playing when they
replace the playlist. Default to on, since this was the behavior
of the old "Clear List & Play Next" option.
Change-Id: I1340aed5c28bb3244e36d0953b3308ae59681c97
|
|
Rename the "Clear List & Play" options to simply Play and Play
Shuffled, and change their behavior slightly. Previously they
would leave the current song playing, but now they will start
playing the first song of the new playlist immediately.
Shuffle options are now consistently hidden whenever a single
file is selected.
Fixes FS#13336 -- Play Shuffled is now always displayed where
applicable, regardless of playback state.
Change-Id: Idd454b4f9ab2c98cda3ce0389add747a3273fb42
|
|
When opening an audio file from the file
browser or database using the Properties
plugin, it will now use existing code from
the Show Track Info screen for displaying
metadata. The menu option has been
renamed accordingly.
Change-Id: I5a824865b9f980151b91aff3c3c18ec45830a12c
|
|
Change-Id: I7c3c86ffdab62859ce88faeeb84160ea52a4626a
|
|
I intended to check for enough space in buffer but this isn't
really doing it and it is making aa_bufsz slightly too big so
it's a possible buffer overflow.
Restore the old ALIGN_DOWN(..., 4) rounding in case it's important,
if not, then no harm done.
Change-Id: I904f255ac79a77d5328b44667502ceae8308e659
|
|
get rid of the magic buffer size and the whole name buffer
naming the buffers individually doesn't serve any real purpose
instead add a static string for all td buffers
Change-Id: I962a966456453e1b84bab6fec6f4df7cb075ef4e
|
|
the iriver devices overwrite the pointer
Change-Id: I20ae6db2aec0f957824b61db349c7c45a95e58d9
|
|
I don't think this will amke any difference except maybe for hosted ports
Change-Id: I84f898aea92a6963901a6d889dd18b63f24c9a41
|
|
It was possible for the tag tree's buflib move callback to turn a
null pointer non-null. The tagcache_search_clause->str can be null
for OR clauses. Also ensure that clauses are zeroed on allocation
to ensure garbage pointers don't creep in.
Change-Id: Ic823a8eecc501eeaa75798066521e427a9a89190
|
|
Bug reported by UBSan.
Change-Id: I3223a496dfa5df4e3df97fb88a14ea0174d4b428
|
|
Bug reported by UBSan.
Change-Id: I02276521510acac8696499895fec15993c55aaf6
|
|
A couple of places use sizeof(int) for allocations and copying but
the indices are longs, which causes bugs in the simulator on 64-bit.
Change-Id: Ie101ac57d44217c4b1657cf0152c97e276bd7043
|
|
UBSan reports an avalanche of unaligned pointer bugs stemming from
hardcoded 4-byte alignments used in certain places. Use sizeof(long)
instead to align to the machine word size.
Change-Id: I28e505212462c5268afa24e95df3a103ac3e2213
|
|
GCC complains about this when compiling with UBSan.
Change-Id: I4bd8ff2b47882ab95620dc7750a9a80f823cc2ea
|
|
Change-Id: I376aba4258dd3c54c45d97317aa1e7bc8f2a3a17
|
|
Change-Id: I59e7f7face07f3f97fc6e016ee333cd3139ad5fd
|
|
These operations can only be used in limited circumstances and have
exactly one user. bufgettail especially seems of dubious value; how
often do you need to read N bytes from the end of a file without
changing the file position?
strip_tags() was the only function using them, to strip off ID3v1
and APE tags off the end of buffered tracks. This would save only
32-192 bytes per track -- if the container format uses APE/ID3v1.
It hardly seems worth the effort.
Change-Id: I8fc3c1408517eda6126e75e76d76daea904b50eb
|
|
forgot to add the update function to the list_wraparound callback
Change-Id: I7ee7940f126726c727344d7d09371f1bf3295c81
|
|
According to the on screen instructions, any other button
should mean No.
More importantly, in my experience at least, the Select
"button", since it is touch-activated, can sometimes be
pressed by accident, especially when a warning screen
is displayed as a result of pressing that same button.
Change-Id: Ieeadfa8018b5df99605297bc47948a181c22dab4
|
|
np_file is a buffer of size MAX_PATH. After
removing only the file name component and
leaving the rest of the path, the
available space may not be sufficient
for appending another file name (possibly of
size MAX_PATH itself) to it.
This can occur after a file of acceptable
length is opened in ImageViewer, and you
then advance to another file whose path
(including the file name) is longer than
MAX_PATH.
Change-Id: Ideadd9451359bd5735bce92fca5d983e61f300e9
|
|
These options don't seem to
apply to the database...
Change-Id: I777073eeaed4099acf44996b95fa05b4c2b3abc4
|
|
When the 'Album Art' setting was set to
'Prefer Image File' and neither image file
nor embedded artwork were found,
playback would check for files twice.
Change-Id: Ibe392928d58ec04103e2572124841724509bd859
|
|
Change-Id: I02dbc3e91856eaef081446ca77919e6182a85e1d
|
|
Change-Id: Ieec0e49d0b5e1ca14fa828a510edf30d548969b2
|
|
flags were getting un-initialized memory
it really didn't matter with the flags getting initialized
anyway
But once I added a new flag that didn't explicitly
set or clear the flag at init well here we are
set flags to VP_DEFAULT_FLAGS in viewport_set_defaults()
add the flags variable to the default vp's set to 0
(it was already initialized to 0 by bss, make it explicit)
Change-Id: I3a9a062455b4cf66d2b8c70fdf05402a5c0c091c
|
|
Frequency, file size, and the codec are not stored
in the database and thus can’t be displayed in the
Playlist Viewer's Track Info screen when metadata
is only retrieved from the database.
Change-Id: I9e1d11c13ad8bf7b90b654ed78e4e7f763c30f8a
|
|
Change-Id: I619a637bdf1fb932c3618f1f40aaa1c9e7f98300
|
|
Change-Id: Idbee52505b3c109a0aad23e2edf7dd78519eb173
|
|
Change-Id: If31a99e6488dabab47d482637b2609ff829df1ca
|
|
...and go to last album, even if it hadn't
been selected for playback
Change-Id: I44013e930a1feb873f128c2885ecb8ddaf4ae3ff
|
|
Eliminates flashing of slide right after launch or
when changing sorting on the M3K using the
volume buttons
Change-Id: Icd317e0b0d5b939269dc8dafd30d0c0f9daa5fd9
|
|
This plugin provides a menu for easily editing the root redirect file
on targets that support multiboot. You can select a new root from a
list of Rockbox installations detected on the filesystem or remove all
redirects to boot from the default location.
To avoid searching the whole filesystem, only subdirectories of the
volume roots are checked for valid installations. Only installations
that are compatible with the current player will be displayed.
Change-Id: I7dcbadfd97873b87817870e61d2ae37956d2da00
|
|
Allow a clean shutdown to end in either power off or reboot. Add a
new event SYS_REBOOT to signal it and sys_reboot() to trigger the
event. SYS_REBOOT signals a reboot request and should be listened
for alongside SYS_POWEROFF events.
Change-Id: I99ba7fb5feed2bb5a0a40a274e8466ad74fe3a43
|
|
--typo
Change-Id: Iaa632e215d7d1e3758f62fedd72565fa633d925e
|
|
its really painful needing to override global settings in order to change
some aspects of lists
this patch moves:
[scrollbar position, cursor type,
talk_menus, keyclick,
wrap around, scroll paginated]
to variables within the synclist, it also makes updating
after settings changes a necessity
I think I have the static synclists in core covered
(I think the one in gui/list-skinned can be left as is)
this patch allows easy modification these flags on the fly
Change-Id: Id0dcb8b05eb9ecd78929c0aff7678bf2ab4c70a7
|
|
The progress callback doesn't rate limit LCD updates, which causes
excessive slowdowns (up to 150x!) on some targets. Limiting updates
to 20fps solves the problem and should boost load speed across the
board, particularly for large images and animated GIFs that may run
the progress callback thousands of times.
Change-Id: Ia48924d4dcb24c1111509329581809be494d0165
|
|
In some circumstances it was possible for a bitmap to overflow its
buffer and overwrite the next handle. The easiest way to trigger it
is with a highly compressed JPEG that is decoded to a large bitmap.
Because the JPEG file size is used to determine how much to allocate
this would cause an obvious buffer overflow when the JPEG is smaller
than the decoded bitmap. Fix this by using the decoded bitmap size as
the allocation size. Some overhead must be added to deal with JPEGs,
but it will be freed once the image is loaded.
A less obvious possibility is the fact that add_handle() will allow
a handle to be added even if there's not enough space for the entire
allocation. This is generally beneficial because it allows the first
part of a file to be loaded while waiting for space to free up, but
for bitmaps it is not valid because the whole image is loaded at once.
Hence if there is not actually enough space in the buffer, the bitmap
load can again overflow the actual free space and overwrite the next
handle.
The buffering code supports an H_ALLOCALL flag for allocations that
need the free space available immediately, so use it for bitmaps to
avoid that bug.
load_image() had a sketchy-looking check for free space which stopped
me from triggering the bug with simple tests, but since guessing the
free space is obviously a bad idea when the caller *knows* how much
free space there really is, remove that guess and let the caller tell
load_image() the real deal.
Change-Id: If62a58759705d83c16ee5b50f26bcbccc3f6c01f
|
|
JPEG decoding requires additional space in the bitmap buffer beyond
what is needed for the decoded pixel data. Provide a way to estimate
how much overhead is needed.
The actual overhead is sizeof(struct jpeg) + decode_buf_size, where
the latter depends on the image size and JPEG encoding used. From my
testing decode_buf_size is normally pretty small (under 5 KiB) but
looking at the code it could be large in some cases, primarily with
large images, so 32 KiB seems to be a decent compromise. Someone who
knows better about JPEG should pick a better value if that's too big.
Using a constant is obviously not the most accurate but it seems to
be the simplest option for retrofitting to existing code.
Change-Id: I573b0abb8ca2d79e43f185010487f07226edb793
|
|
Not sure what the comment is talking about - signed overflow
is undefined behavior and we don't use -fwrapv or other flags
to make it defined. I can't see how a compiler could abuse it
here, but the overflow is nonetheless easily avoided.
Change-Id: Ibed6d7c0d841db2aa86b9d8ba4c6a0d08c413354
|
|
don't stop playback to alloc viewports for the keyboard
For the moment it doesn't make much difference
each vp takes about 40 bytes (double that in the sim?)
so not the end of the world 120 extra bytes
Change-Id: I482d7e3061cf9fb8065dc28bf62a6f830770f3c7
|
|
While the track number is limited to 99, I know of no documented
constraint on the value of offset minutes to 99.
As we are storing the millisecond offset as unsigned long, assuming
32 bit, we can allow 70,000 minutes (2^32 / 60000).
However, I've been unable to generate a test audio file 48 days long
under 2GB, so I've set the limit to 30,000 minutes.
In addition, this change reduces the maximum number of seconds to 59,
and frames to 74.
I've generated some silent test files with the filenames being
cue_[minutes].mp3
http://peskett.co.uk/rockbox/test_cues/
Change-Id: I3ca4468ebc88ba134c4e785e9395f90bf76941ac
|
|
allows items to be moved around with less code changes
remove scrolling I was not overly impressed with it
add test_kbd plugin
Change-Id: Ic183c7221bda9405891632704f3a7bbfd79bfe83
|
|
if you skip a track after the halfway point the scrobbler may double post
with slightly different timestamps but the same track info
take a crc of the non-unique part and check against the previously
written track
Change-Id: I676342c4cd76f632131d9cb6d9f7d2f59df357e6
|
|
we need to make sure we don't deref NULL pointers
Change-Id: I9c564b681cd20222c3a134680e60a310b2eb846c
|
|
The comment regarding Windows paths was fairly confusing as to
its intent. What the code is trying to do is replace the drive
letter with the volume containing the playlist, which appears
reasonable. The middle of the comment was devoted to explaining
why the code below was potentially incorrect which only served
to add to the confusion.
AFAICT the last volume specifier in a path will cause search to
start from the root of that volume, so any incorrect result can
be avoided by using the new function path_strip_last_volume().
Finally, add a comment at the top of the function that explains
what it does.
Change-Id: If4e4938801f2f81eb52f5d32b5461872995e5e83
|
|
Change-Id: I385354688b1d8f8df4d44e7e177e23bdb6ed3df4
|
|
Change-Id: I66dda13ec2cbb592ebe0d269f0c7eff749bc737a
|
|
Change-Id: I41f794a457435f0d02da180673e272438e3879b2
|
|
Change-Id: I442d79842ca1d58d122058171175a6fee844a353
|
