Fix empty playlists on restore
The PathProbe
stores the state (the m_splitPath
stack) used by
FsDiscoverer::discover()
. It assumes that the discoverer calls
PathProbe::proceedOnDirectory()
in a certain order (it updates its
internal state accordingly).
If the "current depth level" or the target path (m_splitPath.top()
) is
different from the directory name, the directory is rejected.
For example, here are the successive directories considered to discover
"/home/user/Music/album/track.mp3"
from the entryPoint "/home"
:
-- depth 0
m_path: "/home/user/Music/album/track.mp3"
m_splitPath: ["track.mp3", "album", "Music", "user", "home"]
m_splitPath.top(): "home"
directory: "/home"
directory name: "home"
return: true
-- depth 1
m_path: "/home/user/Music/album/track.mp3"
m_splitPath: ["track.mp3", "album", "Music", "user"]
m_splitPath.top(): "user"
directory: "/home/user"
directory name: "user"
return: true
-- depth 2
m_path: "/home/user/Music/album/track.mp3"
m_splitPath: ["track.mp3", "album", "Music"]
m_splitPath.top(): "Music"
directory: "/home/user/Videos"
directory name: "Videos"
return: false
-- depth 2
m_path: "/home/user/Music/album/track.mp3"
m_splitPath: ["track.mp3", "album", "Music"]
m_splitPath.top(): "Music"
directory: "/home/user/Music"
directory name: "Music"
return: true
...
The problem is that it can only work if the first directory (the entry point) does not contain more than 1 token. For example,
-- depth 0
m_path: "/sdcard/emulated/0/Music/track.mp3"
m_splitPath: ["track.mp3", "Music", "0", "emulated", "sdcard"]
m_splitPath.top(): "sdcard"
directory: "/sdcard/emulated/0"
directory name: "0"
return: false
Since the initial directory is "/sdcard/emulated/0"
, the directory name
("0"
) does not match the first token of the target path ("sdcard"
): the
internal state of PathProbe
is inconsistent with the sequence of calls
it expects from the discoverer.
This commit quick-fixes the problem by handling the entry point
separately to "consume" all the initial path tokens, so that the
internal state of PathProbe
is synchronized with the calls it receives
from the discoverer.
This fix is not very elegant (it adds another assumption on the order of the calls by the discoverer), I would like to discuss with @chouquette for a proper solution. :)