Playlists
Playlist files read into queue items (#490): the M3U lists people keep their music in and other players export, PLS lists, XSPF lists, and cue sheets.
M3U and M3U8 that are not HLS, which always carries
#EXT-X-tags: each line that is not a comment names an item.#EXTINFgives the title of the item after it,#EXTARTand#EXTALBits artist and album, and#EXTVLCOPTlines forhttp-referrerandhttp-user-agentitsRefererandUser-Agentheaders, as IPTV lists write them.PLS: the
FileNentries in their number order, with theirTitleN.XSPF: each
<track>'s first<location>, with its<title>,<creator>and<album>.A cue sheet (#456): each audio track as an item of its file with a MediaClip, from its
INDEX 01to where the next track of the file begins, its pregap played at the end of the track before it, with itsTITLEandPERFORMERand the sheet'sTITLEas its album. So an album ripped to one file with its.cueplays as its tracks.
A relative address is resolved against the list's own: a path beside a list on disk, with the backslashes of a list written on Windows read as separators, and an address beside a list on a server. A file:// address becomes the path it names. The text is read as it is given; see KitePlayer.readPlaylist for a list's bytes.
Functions
Where entry, an address a playlist at base names, points: an address beside a list on a server resolved as RFC 3986 says, and a path beside a list on disk, as parse resolves every entry. An address with a scheme of its own stands, except a file:// one, which becomes the path it names. For a caller that reads a playlist parse does not, such as an HLS master playlist whose backup variants it wants to open (#440).