The function to check whether a playlist has been modified
will now only try to resume a playlist, if the global resume index
is not -1.
This also means that replacing a finished (modified) playlist will not
produce a warning anymore if Rockbox has been restarted in
between. In that respect, the behavior is identical to
what it was *before* 46085c8978.
Change-Id: Ib95f89043274f1c72c75023d1506fc093aaf4cf9
Music currently doesn't begin playing after the user has selected a new song from a playlist or using the database/file browser, unless another item was already playing or the previous player state was "stopped" but not "paused". This results in an inconsistent user experience. The user's likely intention is to immediately listen to a song they select regardless of the previous player state.
Change-Id: I574c3fe5c12fee544da0569182fc9573d307ac2f
Rockbox would previously not present a warning when you were about
to replace a modified playlist after restarting the player,
unless you first resumed playback.
Change-Id: I9752228f84b105747e41ce6e1c8f95f0f9f14c10
Discovered on ClipZip but applicable to other LOW MEM targets
Back off voice buffer on playlist_resume
Change-Id: Ia316c4b7fc1bcb089d3069a13dd7c193edf2ba1e
After using “Insert Next” to insert multiple songs at once (e.g. an album from the database browser or folder from the file browser), subsequent Insert operations will incorrectly insert items after the first song of all items that were previously inserted, instead of after the last song of the previously inserted items.
A bug fix was originally written by Costas Calamvokis for the file browser only. I adopted the original fix and added code analogous to it so that it works from the database browser as well.
See FS#7898, FS#7363 or this forum post for more info:
https://forums.rockbox.org/index.php/topic,53741.0.html
Change-Id: Ie2718e136df0b340000f7a171e9e806cf23a27b4
Music currently doesn't begin playing after the user has selected a new song in a playlist, unless another item was already playing or the previous player state was "stopped" (but not "paused"). This results in an inconsistent user experience. The user's likely intention is to immediately listen to the song they select for playback regardless of the previous player state.
Change-Id: I68a8da01b06a81d8c3b61e351710431152bfdfaa
Note: I left behind lcd_bitmap in features.txt, because removing it
would require considerable work in the manual and the translations.
Change-Id: Ia8ca7761f610d9332a0d22a7d189775fb15ec88a
'swcodec' is now always set (and recording_swcodec for recording-capable
units) in feature.txt so the manual and language strings don't need to
all be fixed up.
Change-Id: Ib2c9d5d157af8d33653e2d4b4a12881b9aa6ddb0
While playing a track the playlist viewer may not
have a big enough temporary buffer to load and display
'max_files_in_playlist' entries
This patch attempts to load as many entries as possible
If tracks were already playing (dynamic playlist or otherwise)
The original code only gave half the plugin buffer to a playlist
loaded from file
On some targets half the plugin buffer is not enough to load all entries…
Now we attempt to get as many entries possible while at least leaving a
small buffer (MAX_PATH) for the name buffer
Change-Id: Ic06eaabc4e2550f076d625957d6d073790852743
I observed a crash on buflib>move_block
after dumping ram I noticed that the buffer for filetypes was being corrupted
tree_get_entry_at returns a entry from the buflib 'tree entry' buffer
filetree.c->ft_load writes data to this buffer before checking if it has
reached the last entry resulting in buffer overflow that overwrites the
next entry in the buffer ['filetypes']
Patch checks that the index passed to tree_get_entry_at() is in range
otherwise it returns NULL
Added checks + panic in other functions using tree_get_entry_at()
Fixed tree_lock_cache() calls in playlist and filetree
Change-Id: Ibf9e65652b4e00445e8e509629aebbcddffcfd4d
Playlist was CRC-ing the path from the id3, which may have been
modified to remove "bogus dirs". This would cause a CRC mismatch
in the resume information.
Now, just use the current playlist's current index and call
playlist_get_filename_crc32() to get the original path when
updating resume info.
While technically correct, if this causes any issue(s) it's just
a one-line change and painless to revert.
Change-Id: Ie595ef6c40349c342bd7acac8c542829f9cd5d76
Playlist dircache references should be back in working order.
Reenabling dircache references in the database ramcache is not
yet done as it requires quite a bit of rework. Otherwise, the
database in RAM is functional again.
Some buffer compatibility changes have been made for database
commit because the dircache buffer can no longer be stolen, only
freed by an API call.
Change-Id: Ib57c3e98cb23e798d4439e9da7ebd73826e733a4
Some changes in behavior were made with filesystem code commit
for the sake of compatibility that changed expected behavior.
* Restore substitution of drive spec in fully-qualified DOS paths
with the playlists's volume spec (or root on univolume targets).
Drive-relative paths of the form "c:foo" (no separator after
':') will be treated as purely relative.
* Restore old behavior of preserving leading whitespace in the
source path and trimming only trailing tabs and spaces.
* Multivolume: Volume substition on fully-qualified UNIX/RB paths
has NOT been reintroduced (and perhaps wasn't intended in the
first place). They will not be modified because there is no
ambiguity to resolve. Doing so would prevent a playlist on
external storage from referencing a file on main storage without
qualifying it with "/<0>...".
* Plain relative paths are and always have been interpreted as
relative to the location of the playlist.
Change-Id: Ic0800cea79c59563b7bac20f8b08abb5051906c7
This should only be a problem if the last line
is not terminated by \r or \n though.
cppcheck reported:
[rockbox/apps/playlist.c:234]: (style) Array index 'i' is used before limits check.
Change-Id: I8182b66272ba9c024984c81588bd2a6dbb8255b8
This patch redoes the filesystem code from the FAT driver up to the
clipboard code in onplay.c.
Not every aspect of this is finished therefore it is still "WIP". I
don't wish to do too much at once (haha!). What is left to do is get
dircache back in the sim and find an implementation for the dircache
indicies in the tagcache and playlist code or do something else that
has the same benefit. Leaving these out for now does not make anything
unusable. All the basics are done.
Phone app code should probably get vetted (and app path handling
just plain rewritten as environment expansions); the SDL app and
Android run well.
Main things addressed:
1) Thread safety: There is none right now in the trunk code. Most of
what currently works is luck when multiple threads are involved or
multiple descriptors to the same file are open.
2) POSIX compliance: Many of the functions behave nothing like their
counterparts on a host system. This leads to inconsistent code or very
different behavior from native to hosted. One huge offender was
rename(). Going point by point would fill a book.
3) Actual running RAM usage: Many targets will use less RAM and less
stack space (some more RAM because I upped the number of cache buffers
for large memory). There's very little memory lying fallow in rarely-used
areas (see 'Key core changes' below). Also, all targets may open the same
number of directory streams whereas before those with less than 8MB RAM
were limited to 8, not 12 implying those targets will save slightly
less.
4) Performance: The test_disk plugin shows markedly improved performance,
particularly in the area of (uncached) directory scanning, due partly to
more optimal directory reading and to a better sector cache algorithm.
Uncached times tend to be better while there is a bit of a slowdown in
dircache due to it being a bit heavier of an implementation. It's not
noticeable by a human as far as I can say.
Key core changes:
1) Files and directories share core code and data structures.
2) The filesystem code knows which descriptors refer to same file.
This ensures that changes from one stream are appropriately reflected
in every open descriptor for that file (fileobj_mgr.c).
3) File and directory cache buffers are borrowed from the main sector
cache. This means that when they are not in use by a file, they are not
wasted, but used for the cache. Most of the time, only a few of them
are needed. It also means that adding more file and directory handles
is less expensive. All one must do in ensure a large enough cache to
borrow from.
4) Relative path components are supported and the namespace is unified.
It does not support full relative paths to an implied current directory;
what is does support is use of "." and "..". Adding the former would
not be very difficult. The namespace is unified in the sense that
volumes may be specified several times along with relative parts, e.g.:
"/<0>/foo/../../<1>/bar" :<=> "/<1>/bar".
5) Stack usage is down due to sharing of data, static allocation and
less duplication of strings on the stack. This requires more
serialization than I would like but since the number of threads is
limited to a low number, the tradoff in favor of the stack seems
reasonable.
6) Separates and heirarchicalizes (sic) the SIM and APP filesystem
code. SIM path and volume handling is just like the target. Some
aspects of the APP file code get more straightforward (e.g. no path
hashing is needed).
Dircache:
Deserves its own section. Dircache is new but pays homage to the old.
The old one was not compatible and so it, since it got redone, does
all the stuff it always should have done such as:
1) It may be update and used at any time during the build process.
No longer has one to wait for it to finish building to do basic file
management (create, remove, rename, etc.).
2) It does not need to be either fully scanned or completely disabled;
it can be incomplete (i.e. overfilled, missing paths), still be
of benefit and be correct.
3) Handles mounting and dismounting of individual volumes which means
a full rebuild is not needed just because you pop a new SD card in the
slot. Now, because it reuses its freed entry data, may rebuild only
that volume.
4) Much more fundamental to the file code. When it is built, it is
the keeper of the master file list whether enabled or not ("disabled"
is just a state of the cache). Its must always to ready to be started
and bind all streams opened prior to being enabled.
5) Maintains any short filenames in OEM format which means that it does
not need to be rebuilt when changing the default codepage.
Miscellaneous Compatibility:
1) Update any other code that would otherwise not work such as the
hotswap mounting code in various card drivers.
2) File management: Clipboard needed updating because of the behavioral
changes. Still needs a little more work on some finer points.
3) Remove now-obsolete functionality such as the mutex's "no preempt"
flag (which was only for the prior FAT driver).
4) struct dirinfo uses time_t rather than raw FAT directory entry
time fields. I plan to follow up on genericizing everything there
(i.e. no FAT attributes).
5) unicode.c needed some redoing so that the file code does not try
try to load codepages during a scan, which is actually a problem with
the current code. The default codepage, if any is required, is now
kept in RAM separarately (bufalloced) from codepages specified to
iso_decode() (which must not be bufalloced because the conversion
may be done by playback threads).
Brings with it some additional reusable core code:
1) Revised file functions: Reusable code that does things such as
safe path concatenation and parsing without buffer limitations or
data duplication. Variants that copy or alter the input path may be
based off these.
To do:
1) Put dircache functionality back in the sim. Treating it internally
as a different kind of file system seems the best approach at this
time.
2) Restore use of dircache indexes in the playlist and database or
something effectively the same. Since the cache doesn't have to be
complete in order to be used, not getting a hit on the cache doesn't
unambiguously say if the path exists or not.
Change-Id: Ia30f3082a136253e3a0eae0784e3091d138915c8
Reviewed-on: http://gerrit.rockbox.org/566
Reviewed-by: Michael Sevakis <jethead71@rockbox.org>
Tested: Michael Sevakis <jethead71@rockbox.org>
The plugin buffer was used only to avoid reparsing the playlist, so non-essential.
But when it was used it conflicted with the playlist viewer which already uses
the plugin buffer for playlist purposes simultaneously. It only works by
accident.
Since the reparse avoidance is non-essential don't do it for now. A temp buffer
can be passed to playlist_save() to enable it but the only caller (as of now)
does not do that.
Change-Id: I3f75f89d8551e1ec38800268b273105faba0efbf
add_event_ex is added that takes an extra user_data pointer. This pointer is
passed to the callback (add_event and add_event_ex have slightly different
callbacks types). All callbacks also get the event id passed. Events added
with add_event_ex must be removed with remove_event_ex because the user_data
pointer must match in addition to the callback pointer.
On the other add_event is simplified to omit the oneshort parameter which
was almost always false (still there with add_event_ex).
As a side effect the ata_idle_notify callbacks are changed as well, they
do not take a data parameter anymore which was always NULL anyway.
This commit also adds some documentation to events.h
Change-Id: I13e29a0f88ef908f175b376d83550f9e0231f772
This complements offset-based resume and playback start funcionality.
The implementation is global on both HWCODEC and SWCODEC.
Basically, if either the specified elapsed or offset are non-zero,
it indicates a mid-track resume.
To resume by time only, set elapsed to nonzero and offset to zero.
To resume by offset only, set offset to nonzero and elapsed to zero.
Which one the codec uses and which has priority is up to the codec;
however, using an elapsed time covers more cases:
* Codecs not able to use an offset such as VGM or other atomic
formats
* Starting playback at a nonzero elapsed time from a source that
contains no offset, such as a cuesheet
The change re-versions pretty much everything from tagcache to nvram.
Change-Id: Ic7aebb24e99a03ae99585c5e236eba960d163f38
Reviewed-on: http://gerrit.rockbox.org/516
Reviewed-by: Michael Sevakis <jethead71@rockbox.org>
Tested: Michael Sevakis <jethead71@rockbox.org>
This fixes the radioart crash that was the result of buffering.c working
on a freed buffer at the same time as buflib (radioart uses buffering.c for the
images). With this change the buffer is owned by buflib exclusively so this
cannot happen.
As a result, audio_get_buffer() doesn't exist anymore. Callers should call
core_alloc_maximum() directly. This buffer needs to be protected as usual
against movement if necessary (previously it was not protected at all which
cased the radioart crash), To get most of it they can adjust the willingness of
the talk engine to give its buffer away (at the expense of disabling voice
interface) with the new talk_buffer_set_policy() function.
Change-Id: I52123012208d04967876a304451d634e2bef3a33
As well as using an index, which breaks when a file is added or
removed, use the crc32 of the filename. When the crc32 check passes the
index is used directly. When it fails, the slow path is taken checking
each file name in the playlist until the right crc is found. If that fails
the playlist is started from the beginning.
See http://www.rockbox.org/tracker/6411
Bump plugin API and nvram version numbers
Change-Id: I156f61a9f1ac428b4a682bc680379cb6b60b1b10
Reviewed-on: http://gerrit.rockbox.org/372
Tested-by: Jonathan Gordon <rockbox@jdgordon.info>
Reviewed-by: Jonathan Gordon <rockbox@jdgordon.info>
format_track_path currenyly corrects for things like windows volumes and
relative paths in playlists, but does not handle external media like SD
cards correctly, resulting in some seemingly valid playlists not working
because of rockbox's mount point for external media. Correct this by checking
to see if a playlist is on external media and then formulate the path correctly
if it is.
Unfortunately, this breaks the playlist_save logic if the CWD is on an external
device. Its not clear to me why we should be checking the CWD when saving a
playlist, as the only apparent use of this is to let people save relative
paths on the virtual keyboard. As far as I can tell, this is actually more
difficult to do then using an absolute path given that we insert the CWD
onto the virtualkeyboard by default. Therefore, I'm removing the option
to use '..' in playlist save paths since its seems useless.
Change-Id: I47946cc45d776c7a72ecbd0ecc720dbf85550f6f
Reviewed-on: http://gerrit.rockbox.org/270
Reviewed-by: Michael Giacomelli <mgiacomelli@gmail.com>
Tested-by: Michael Giacomelli <mgiacomelli@gmail.com>
When enabled, if the user has set "Start File Browser Here" (config.cfg:
start directory) to anything other than root and "Auto-Change Directory"
is set to "Yes" or "Random", the directory returned when an auto change
is required will be constrained to the value of "start directory" or below.
Change-Id: Iaab773868c4cab5a54f6ae67bdb22e84642a9e4b
Reviewed-on: http://gerrit.rockbox.org/182
Reviewed-by: Nick Peskett <rockbox@peskett.co.uk>
Tested-by: Nick Peskett <rockbox@peskett.co.uk>
This makes playlist_save() properly restore playlist buffer values,
so the buffer can be used afterwards.
git-svn-id: svn://svn.rockbox.org/rockbox/trunk@31481 a1c6a512-1295-4272-9138-f99709370657
Now all threads need to ack the connection like on real target, dircache is unloaded and playback stops accordingly.
git-svn-id: svn://svn.rockbox.org/rockbox/trunk@31009 a1c6a512-1295-4272-9138-f99709370657
This enables the ability to allocate (and free) memory dynamically
without fragmentation, through compaction. This means allocations can move
and fragmentation be reduced. Most changes are preparing Rockbox for this,
which many times means adding a move callback which can temporarily disable
movement when the corresponding code is in a critical section.
For now, the audio buffer allocation has a central role, because it's the one
having allocated most. This buffer is able to shrink itself, for which it
needs to stop playback for a very short moment. For this,
audio_buffer_available() returns the size of the audio buffer which can
possibly be used by other allocations because the audio buffer can shrink.
lastfm scrobbling and timestretch can now be toggled at runtime without
requiring a reboot.
git-svn-id: svn://svn.rockbox.org/rockbox/trunk@30381 a1c6a512-1295-4272-9138-f99709370657
The buflib memory allocator is handle based and can free and
compact, move or resize memory on demand. This allows to effeciently
allocate memory dynamically without an MMU, by avoiding fragmentation
through memory compaction.
This patch adds the buflib library to the core, along with
convinience wrappers to omit the context parameter. Compaction is
not yet enabled, but will be in a later patch. Therefore, this acts as a
replacement for buffer_alloc/buffer_get_buffer() with the benifit of a debug
menu.
See buflib.h for some API documentation.
git-svn-id: svn://svn.rockbox.org/rockbox/trunk@30380 a1c6a512-1295-4272-9138-f99709370657
Namely, introduce buffer_get_buffer() and buffer_release_buffer().
buffer_get_buffer() aquires all available and grabs a lock, attempting to
call buffer_alloc() or buffer_get_buffer() while this lock is locked will cause
a panicf() (doesn't actually happen, but is for debugging purpose).
buffer_release_buffer() unlocks that lock and can additionally increment the
audiobuf buffer to make an allocation. Pass 0 to only unlock if buffer was
used temporarily only.
buffer_available() is a replacement function to query audiobuflen, i.e. what's
left in the buffer.
Buffer init is moved up in the init chain and handles ipodvideo64mb internally.
Further changes happened to mp3data.c and talk.c as to not call the above API
functions, but get the buffer from callers. The caller is the audio system
which has the buffer lock while mp3data.c and talk mess with the buffer.
mpeg.c now implements some buffer related functions of playback.h, especially
audio_get_buffer(), allowing to reduce #ifdef hell a tiny bit.
audiobuf and audiobufend are local to buffer.c now.
git-svn-id: svn://svn.rockbox.org/rockbox/trunk@30308 a1c6a512-1295-4272-9138-f99709370657
* Rename stuff to not re-use the term dircache
* Move cache to own struct
* Encapsulate retrieving entries a bit
git-svn-id: svn://svn.rockbox.org/rockbox/trunk@30242 a1c6a512-1295-4272-9138-f99709370657
Use the plugin buffer to save the playlist copy if there isnt enough buffer already allocated to the inram copy of the playlist
git-svn-id: svn://svn.rockbox.org/rockbox/trunk@30184 a1c6a512-1295-4272-9138-f99709370657
It breaks playlist viewing when playback is stopped (the code path wasn't so unused).
git-svn-id: svn://svn.rockbox.org/rockbox/trunk@30150 a1c6a512-1295-4272-9138-f99709370657
Dircache IDs can be 0, so to invalidate -1 must be used.
Update the memset calls to reflect this.
git-svn-id: svn://svn.rockbox.org/rockbox/trunk@30125 a1c6a512-1295-4272-9138-f99709370657
cache new pointers to dircache items when dircache goes
offline and comes back onlineagain (during tagcache commit). This
should prevent wrong filenames to appear in playlist.
git-svn-id: svn://svn.rockbox.org/rockbox/trunk@30047 a1c6a512-1295-4272-9138-f99709370657
Only integer IDs are exposed from dircache with this. This way the cache is isolated from other modules.
This is needed for my buflib gsoc project.
git-svn-id: svn://svn.rockbox.org/rockbox/trunk@30038 a1c6a512-1295-4272-9138-f99709370657
For RaaA it evaluates user paths at runtime. For everything but codecs/plugins it will give the path under $HOME/.config/rockbox.org if write access is needed or if the file/folder in question exists there (otherwise it gives /usr/local/share/rockbox).
This allows for installing themes under $HOME as well as having config.cfg and other important files there while installing the application (and default themes) under /usr/local.
On the DAPs it's a no-op, returing /.rockbox directly.
Not converted to use get_user_file_path() are plugins themselves, because RaaA doesn't build plugins yet.
git-svn-id: svn://svn.rockbox.org/rockbox/trunk@27656 a1c6a512-1295-4272-9138-f99709370657
The simulator defines PLATFORM_HOSTED, as RaaA will do (RaaA will not define SIMULATOR).
The new define is to (de-)select code to compile on hosted platforms generally.
Should be no functional change to targets or the simulator.
git-svn-id: svn://svn.rockbox.org/rockbox/trunk@27019 a1c6a512-1295-4272-9138-f99709370657
This is to a) to cleanup firmware/common and firmware/include a bit, but also b) for Rockbox as an application which should use the host system's c library and headers, separating makes it easy to exclude our files from the build.
git-svn-id: svn://svn.rockbox.org/rockbox/trunk@25850 a1c6a512-1295-4272-9138-f99709370657
Fixing it because correcting the event api prototypes causes many warnings.
git-svn-id: svn://svn.rockbox.org/rockbox/trunk@23301 a1c6a512-1295-4272-9138-f99709370657
* Move strncpy() from core to the pluginlib
* Introduce strlcpy() and use that instead in most places (use memcpy in a few) in core and some plugins
* Drop strncpy() from the codec api as no codec used it
* Bump codec and plugin api versions
git-svn-id: svn://svn.rockbox.org/rockbox/trunk@21863 a1c6a512-1295-4272-9138-f99709370657
giving well defined behavior and useful interaction with insert,
and making things like insert next followed by many inserts work.
git-svn-id: svn://svn.rockbox.org/rockbox/trunk@20247 a1c6a512-1295-4272-9138-f99709370657
If insert was used to create a new playlist (e.g. inserting without audio playing), the insert position wasn't updated. Thus, the playlist created was in reversed order (except for the first song).
This was the reason "Insert last" was actually used as Insert in this case. BUT, this one doesn't update the insert position eiterh, but the order of the songs is fine, at least (due to appending).
Now, insert always updates the insert position properly, so that the aforementioned bugs are fixed. Insert is always used now.
Other impact: If you create a playlist using insert, every subsequent insert will append songs at the end of the playlist,if you start playback pressing select on songs, every subsequent insert will insert after the current track.
git-svn-id: svn://svn.rockbox.org/rockbox/trunk@20241 a1c6a512-1295-4272-9138-f99709370657
This should be a good first step to allow multi-driver targets, like the Elio (ATA/SD), or the D2 (NAND/SD).
git-svn-id: svn://svn.rockbox.org/rockbox/trunk@18960 a1c6a512-1295-4272-9138-f99709370657
If this commit causes problems with restarting playback open a bug report (getting testers was difficult...)
Settings which are stored in the nvram.bin file will be reset with this commit. this includes resume info, runtimes, "last screen" and a few others.
git-svn-id: svn://svn.rockbox.org/rockbox/trunk@18555 a1c6a512-1295-4272-9138-f99709370657
* Remove gui_splash()
* Rename gui_syncsplash() to splashf() and remove its voice
capabilities.
* Rename the internal splash() to splash_internal() and introduce an
externally visible splash() that handles simple splashing without
printf functionality e.g. splash(HZ, ID2P(LANG_FOO)); or splash(HZ,
"foo"); if a LANG_* id is passed it will be voiced.
* Adjust all places that called gui_syncsplash() to use the correct
variant from above.
* Export both new functions to plugins and adjust places calling
rb->splash() to use the correct variant so that we now have naming
consistency between the core and plugins.
* Fix one latent bug that would cause my sim to crash with the above
changes and correct P2STR and P2ID macros, thanks to pondlife.
git-svn-id: svn://svn.rockbox.org/rockbox/trunk@18282 a1c6a512-1295-4272-9138-f99709370657
