- Move multiple-id3 functionality into lib
- Extract retrieve_id3 function
In preparation for using these functions
from the Properties plugin.
Change-Id: I7252581340680e32df763f1f4b41646a055fe19e
This was added in commit d553bb1 and
doesn’t seem to be used anymore.
Return PLUGIN_OK since an error message
is already produced.
Change-Id: I5eaf7e7eb7c850a6fa9c3d2717c440e335f5efd1
It seems connecting an iPod Video to a Mac triggers the null
request check, resulting in a panic. Ignoring the error with
a bare return "fixes" it and allows the iPod to connect. This
isn't ideal though, because it could silently introduce bugs
on other targets.
The likely cause of this is the host sending control requests
too fast, or a driver problem (the Video uses the ARC driver,
which is still on the legacy interface), with multiple requests
getting queued at once. Since the USB core expects to deal with
only one request at a time, the second response trips the check.
Try to handle this situation a bit more gracefully by detecting
overlapped requests and returning a STALL to the host when it
occurs. At this point the USB stack is able to safely handle a
new request.
Link: https://forums.rockbox.org/index.php/topic,54414.0.html
Change-Id: I9a2b7e35620ff540ebdb39f81671377062a4917d
It turns out removing DSP_INIT broke the codec ABI and caused
old codecs to crash; the loop and mdelay() was a red herring.
This reverts commit 541960a110.
Change-Id: I020d826e7b4beb006d093d9c3d4f45fa5eaac717
Apparently queue_send() silently falls back to queue_post()
if sending isn't enabled. Doesn't seem like a good idea, as
post and send are definitely *not* interchangeable!
The playlist code relies on queue_send()'s blocking behavior
to prevent the dircache thread from using potentially stale
pointers.
Change-Id: Ibf4b0def3bf9c96cb2fe80cd75043b7ce1dcf250
Commit 6bcd830490 ported an optimization to decode_subframe_fixed()
from FFmpeg (upstream commit 08965b22e2). This contains an out of
bounds read, which doesn't affect the decoder output, but makes ASAN
complain.
FFmpeg fixed the out of bounds read (upstream commit 0ec7b71de8) but
that appears to increase code size a lot.
Inlining the initialization of a, b, c, d into the switch produces
similar code as the non-bounds-checked version with only a handful
of instructions of overhead (checked on MIPS & ARM).
Change-Id: I053fac4efc4676b133eb7545c80e23f37fb00d86
Not really sure how best to deal with the warnings (redefinition of
ARRAYLEN, etc.) short of splitting things out of system.h but this
is good enough for now.
Change-Id: Ibea9f693d128c7995f564f0f5c81d572462a5553
These are more efficient than separate pin/unpin calls because
pin count increment and decrement can be done cheaply when the
data pointer is known.
Secondly, pinned access can be made safe against preemption by
hardware interrupts or other CPU cores; buflib_get_data() can't.
This makes it more useful under different threading models and
for SMP targets; both of which are not particularly relevant to
Rockbox now, but might be in the future.
Change-Id: I09284251b83bbbc59ef88a494c8fda26a7f7ef26
This is intended for improving the effectiveness of tools like
ASAN when debugging memory errors in the sim. It's not meant to
be a serious allocator for hosted targets.
Enable it by changing the buflib backend in config.h.
Change-Id: I0cf23cefa47ee35dede7b49e0e5b72dac60e8d3e
To minimize code duplication between buflib backends move the
public part of the API to buflib.h. Also rewrote documentation
for the whole API.
Change-Id: I4d7ed6d02084d7130cb41511e63c25ec45b51703
You could only add single files to playlists
from the database browser before. This
enables adding any database selection to
a new or existing playlist.
Change-Id: I811c7167641c589944bb2afc18dcc1d299a7b979
move seconds and sizes to arrays indiexed by enums
use a loop for the display and talk of each
stop exiting on SYS_EVENTs
Change-Id: I49d5b9827df4e711b38326e5fef3c54292000370
bad tracks now get skipped with a message at the end of scanning
rather than an error killing the count
Change-Id: I6d8c14ce00e78416b772bc5e9093a889351bc3de
Sansa Clip and Clip+ have a split monochrome screen
some versions have a dead line of pixels
having text split at this line makes it hard to read
move text picker below this split on these devices
Change-Id: I1ebcb4c4c7b1ea950f38e35fed06ed85437a657f
This reverts commit ebebef5566.
Reason for revert: I don't want to get too deep into this till I come back to the keyboard rewrite (hopefully)
Change-Id: Ia273f1a19a042be2dd0f1ee46690c03f2865cd95
Gate buflib_get_data() checking, debug printing, and buflib
integrity checks behind individual defines in buflib.h, and
turn them all off by default. If needed, they can be turned
on manually when compiling.
The buflib debug menu is only available if debug printing is
enabled, so after this commit it will no longer be included
in normal builds -- it isn't very useful to end users.
Change-Id: Iab25b7852bc7c5592ce04c9c45762046a87d5bc3
Removing the variable-length name in the middle of buflib metadata
makes it a lot easier to deal with.
Change-Id: I6eaf236c2285cae40fb6ff0fa5acf827972cdd8b
The CRC is a fairly useless safety check because we already
have specific checks to validate the metadata, and CRCs are
only verified before calling the move callback. Removing the
check should not significantly reduce buflib's robustness.
Change-Id: Ica99bd92fc514819b4fd9f359b4272e581020f75
Remove the name handling code, but leave the allocation structure
otherwise untouched; it's as if all callers provided a NULL name.
The public API still accepts names but names are no longer stored
or returned.
Change-Id: I6c4defcdfd255774f02030949a0fd731477e6a54
Naming your allocations is more of a debugging feature; it's a
bad idea to abuse this feature for storing some random string.
The font code does exactly that to remember the path used to
load a font, and it's the only code that uses buflib names in
this way.
Store the path inside the font allocation instead as a regular
char array. For simplicity it's MAX_PATH sized, so this'll use
a bit more memory than the buflib name method, maybe 1-2 KiB if
a few fonts are loaded.
Change-Id: Ie286a1a273d6477af9e5d3f76e0534b62f72e8f7
dc_thread_playlist was asking for invalid indices
since previously the name buffer would have been valid
it just got whatever junk data was left over
add dc_discard_playlist_pointers for HAVE_DIRCACHE targets
this allows the dc_playlist_thread to stop its current lookup loop
Change-Id: I6f25b97b8c4e314d27c5e1e6ff0925b5a3e93f26
dc_playlist_thread may continue loading pointers even while
underlying indices are changing instead stop the loop by marking
pointers as clean and rebuild later
Change-Id: If154f673b4af8d6e9c364499d58f1321834a76a4
It's usually only called from init() in main.c, so this is safe.
There is one more call in system-dm320.c from system_init(), but
that's also "safe". I don't know if it's okay to call i2c_init()
twice, but presumably it works...
Change-Id: I9c1cd918d162d9955f7cf03209e836cbd5e30c57
On single-core targets, system_init() is only called from init()
in main.c, which is also INIT_ATTR, so this is safe.
Multi-core targets additionally call system_init() from cop_main(),
which isn't marked INIT_ATTR. I'm fairly certain that it would be
safe to add INIT_ATTR to cop_main() with a bit of refactoring, but
I don't have a way of testing it. So for now, leave INIT_ATTR off
for multi-core targets.
Change-Id: I8fe4358f975880ca317d46bda01d7d9db529d3e3
It seems removing this causes a crash on the Clip+ when playing
any file. Appears to be a timing-related issue as replacing the
loop with an mdelay() also fixes it. Needs further investigation
to identify the real cause of the problem, see FS#13386.
Change-Id: Ia93a2887a79b376de50563d6bb3bbc79cee11a1c
This reverts commit 89c021fbfa.
Reason for revert: crash when playing on disk playlist then playing a directory as an in-ram playlist
Change-Id: Ia5cf5da9f46f8c10c5c0f3707e7978c05664b8a4
