rockbox/apps/playlist.c, branch quake5

FS#12887: Fix playlist order after moving a track before current

2019-07-24T18:20:03+00:00

Original patch by Juan Gonzalez
Updated by Igor Poretsky

Change-Id: I913d96df906e56fb4063485a6725cd13e395f165

playlist.c suppress playlist access error on usb plug

2019-01-04T04:28:26+00:00

Change-Id: I6bf446ecb17f5526c2f37158e672f06a5435f5a9

Fix tree.c->tree_get_entry_at() buffer overflow

2018-12-14T07:28:17+00:00

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

Fix truncation warning playlist.c, tree.c

2018-07-25T16:34:53+00:00

Change-Id: I0c62f06fea3ccb55efa21b719a44a263dedc32e2

Make playlist CRC the correct path when saving resume info

2017-10-07T18:38:46+00:00

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

Restore dircache hookup in the database ramcache.

2017-02-10T10:05:23+00:00

Do a few other changes to dircache and file code flags to
accomodate its demands.

Change-Id: I4742a54e8cfbe4d8b9cffb75faaf920dd907cf8a

Reenable database ramcache and playlist dircache

2017-01-17T20:27:47+00:00

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

Fix track formatting problems in playlist.c

2017-01-08T00:10:02+00:00

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

m3u playlist parser: Check size limit before using buffer

2014-12-20T12:14:19+00:00

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

Correct some file permissions.

2014-09-08T14:04:39+00:00

Change-Id: I4a092a19d6a9c66dfeb2777c9655aa4b19d11e16