this needs tested by the heavy playlist users
with the addition of initialize_catalog_buf there shouldn't be any stack overflow concerns
since we are no longer creating another max_path sized buffer when one is already available
this also simplifies the code a bit
rather than carrying around the playlist directory just generate it on the fly
copies the directory to the supplied buffer
add catbroswe_status to keep track of what browse context(s) are currently in use
Change-Id: I145ec501f601c84bb52f2241ed28c6aefab6897b
get_filename() changes the seek pos with out restoring it
seek back to the beginning or after the BOM if utf8
--
the other option is to open our own file descriptor this will
remove the need for the mutex but it would no longer block get_filename
from getting potential stale / bad data
Change-Id: I0d2b8a1a297c7aaf453b3bc558b2b5b53dbe591b
All the F_PADTITLE settings use a lang string so it's safe to
assume the title (which is usually from the setting's lang_id)
is ok. Not like it's very useful or safe to show the cfg_vals,
anyway...
Change-Id: I0bf710e1b2a5a7bcdfe9e4370f48a2f25e8dddf0
The hotkey settings come from a fixed enum, arbitrary values are
not supported. It's not possible to use choice settings for them
because some enum values are only used in the WPS, and some are
only used in the tree.
Change-Id: I4647a8c02d960234323a7f2bbf31fee9f8c5b91a
This atoi() was added long ago in commit d490f441, and it looks
like it's intended to allow arbitrary values in table settings.
These table settings have some symbolic values (eg. off, on) but
are otherwise int-valued.
As far as I can see the only settings that can take this branch
are all table settings with F_ALLOW_ARBITRARY_VALS. It doesn't
make a lot of sense to accept random integers without that flag,
so make the atoi() conversion dependent on it.
Change-Id: I7bb1bc4997601b73ad8dcbf2f3ddf434d16adf23
Use find_setting_by_cfgname() instead of doing it manually.
Reduce the excessive level of indentation.
Change-Id: I410fd7e0c26d065bc479dad3b6facfb5368cd091
The old inline implementation was buggy -- it didn't check the
suffix was actually at the end of the string before stripping
it, and didn't check for truncation. This version also avoids
using an extra buffer.
Change-Id: I33abfefc508675d3079cc64a9ad2b11d646baa0d
This flash chip is found on some Surfans F20 units. For our purposes
it's the same as the GD5F1GA4xExx so just #define an alias instead of
adding a whole new chip struct.
Change-Id: I2f4c4fbf1faf3a0c7a1503534430afacbddc426e
I'm pretty sure this is a very old bug I traced it down to the
current_playlist getting changed out from under add_indices_to_playlist
causing myriad of issues from buffer full to invalid control file to shifting indices
this only appears to happen with the dircache on
I still get an incorrect resume state with the wrong song very rarely -- turns out get_filename seeks the file FIXED
Some debugging left in for now till we can verify there are no other instances
Change-Id: I289a775462eddfe93da4a326dc9e38605af06816
fix a bug where when 'most recent bookmarks'
was enabled the next bookmark file written
would get the info from the last 'most recent'
bookmark instead of the current bookmark
also removed the global resume_info struct in favor of local variables
added verification of the resumed track
Change-Id: I10176a2e4a18da6d5c4bb5fc0ed5d7e81d803ed5
strlcpy returns the size of the string it tried to create so we still need strlen
since we know what the sizes are of the strings just check for overflow first and use strmemccpy
fix bufsz on playlist_get_name()
Change-Id: Iaa52f869994ca94487c19b0cf2958330db4fc786
The playlist catalogue now remembers when you left
a playlist open and will return to it automatically.
Change-Id: I5b725a776b0a524139588c86e38150e5e25cb7d7
Saves and restores the selected item in your
most-recently accessed playlist, similar to Database
and File Browser.
Change-Id: I00afca41e33470cb458c4b87baccd6fd4016887a
Amachronic raised concern about open() blocking causing a static buf
to get overwritten in multiple calls its prudent to just have the caller
supply the buffer to minimize stack issues later
Change-Id: Iae27c7d063adb1a65688f920f6aa5c395fa5694a
unfortunately most of the overhead in searching for <Untagged> occurs in
reading of entries so changing searching the resulting string faster doesn't
do much good but any we don't need this strlen call since its already been
computed
Change-Id: Ia2815a6e7d75237366977632f9b0bc7999254096
current_playmode() returns a value from 'enum playmode' and we
can take advantage of the enum values to simplify the code.
Change-Id: I368ec38ba5061f6cc6d3382e536db2312b27d643
The viewport field in albumart is unnecessary, but for a different
reason than eg. the progressbar was. The skin engine draws images
by going over a global list of images shared between all viewports.
Prior to drawing a viewport, every image is marked "not displayed."
When an image display tag is encountered during rendering this mark
is set to the index of the subimage to be displayed.
The albumart is handled similarily, by setting a handle to -1 and
then updating it when the %Cd tag is encountered. The albumart is
not drawn unless the handle is set to >= 0 by the %Cd tag. So we
don't need to track or check viewports at all, because only the
viewport that contains the %Cd tag will ever draw the albumart.
Change-Id: Ibc0233d168012759325d3c16dc317de9ad3dcf6c
Yet again, no need to store the viewport because we already know
it -- and this time the render code is obviously relying on that
assumption.
Change-Id: Id5eb7cd9999fbe1efccd54bd8f0fd3c8a3011c8e
Again, we don't need to store the viewport in the progressbar
struct because it's known at render time.
Change-Id: I12514ceaace7c897194b18929364340871ef4635
Seems a bit clearer to me than redefining the meaning
of ONPLAY_OK in this context, which was easy to miss.
Fixes the return value for the bookmark_create_menu
hotkey, too. It was previously mapped to ONPLAY_OK
in case the function failed, and to ONPLAY_RELOAD_DIR
if it succeeded. This had no ill effect - or any effect –
since either of the values were disregarded by the WPS
when executing a hotkey.
Return values of playlist_insert_shuffled also had no
effect (by design, apparently, see commit 482b45b).
Use ONPLAY_FUNC_RETURN in hotkey_assignment.
Behavior hasn't changed, it's only been made more
explicit.
Change-Id: Iefc60c9f42c1063af78d368dc382916848064d38
there are a lot of duplicated voiceclips in the inbuilt_filetypes struct
its already looked up so deduplicate
Change-Id: I7846277d2da308f605d5564e9081d6077e697239
there are a lot of duplicated icons in the inbuilt_filetypes struct
its only used at load so deduplicate and look-up by attr
Change-Id: I5eb34e5243d88688984f689e0add08f92d953a6f
