[Playlist] resolving multiple <location> elements per <track> in XSPF?
Wayne DePrince Jr.
waynedpj at in-giro.xyz
Thu Dec 15 11:05:09 UTC 2016
thanks for the helpful reply and for also updating the SO question.
so i can assume that a resolver could allow the user to choose the
preferred location priorities (e.g. first search local library, then remote
Ogg Vorbis locations, then remote MP3 locations): basically the spec is
intentionally ambiguous as to how the multiple locations are used?
i believe having multiple locations is a great advantage of the XSPF
format, even if it is not being utilized as of yet. once i have my playlist
finished and available i would be happy to submit a bug report to VLC and
Audacious regarding their location support (they also seem to have a problem
with nested xml:base https://wiki.xiph.org/XSPF_v1_Notes_and_Errata#.3Cplaylis
t.location.3E_vs._xml:base but i have to investigate that further). is there
a test suite or something that i could point the developers to for XSPF
compliance besides the validators?
again, thanks for the help as well as the format ;)
Il giorno lun, 12/12/2016 alle 13.36 -0800, Lucas Gonze ha scritto:
> The cardinality of the location element is "zero or more." This was chosen
> instead of "zero or one" with the intention of supporting both of the use
> cases you mention (fallbacks and alternate media types).
> What VLC and Audacious do in only using the last location is an incorrect
> That said, our strategy was to make it easy to build a weak resolver, and
> possible to build a strong one. If VLC or Audacious become stronger over
> time by adding support for redundant locations, that is the process playing
> out as hoped.
> I wonder what we can do to help this happen in the VLC and Audacious
> On Mon, Dec 12, 2016 at 12:45 PM, Wayne DePrince Jr. <waynedpj at in-giro.xyz>
> > ahoy all,
> > for parsing an [XSPF] document, the [specification] states that [a
> > `` element can have zero or more `` elements to define
> > the
> > URI of a resource to be rendered]. for example:
> > <?xml version="1.0" encoding="UTF-8"?>
> > http://xspf.org/ns/0/">;
> > <trackList>
> > <track>
> > http://example.com/song_1.ogg</location>;
> > http://mirror.xyz/example.com/song_1.ogg</location>;
> > </track>
> > <track
> > http://example.com/song_2.ogg</location>;
> > http://example.com/song_2.mp3</location>;
> > </track>
> > </trackList>
> > </playlist>
> > my question is whether this is for allowing:
> > - multiple locations of the same type of resource (e.g. MP3 file at
> > original source and mirror) as in song_1 above?
> > - or for different types of the resource (e.g. use multiple locations to
> > provide both an Ogg Vorbis and MP3 version of a track) as in song_2 above?
> > - or maybe both? and/or others?
> > currently VLC and Audacious both use the last `<location>` provided in a
> > `<track>`, even if it is not available. thus they seem to simply be using
> > only the last `<location>` element, which does not seem to be what the
> > specification intends. either way they do not perform either of the
> > resolve cases i list above.
> > obviously how these locations are interpreted changes the expected
> > behavior of a resolver of `<track>` elements that include `<location>`
> > elements. the first case provides a nice fallback solution. more
> > interestingly for me, the second case simplifies the times when 2
> > playlists would be needed: 1 for Ogg Vorbis and 1 for MP3 versions of the
> > tracks, as would have to be done with M3U and PLS for example.
> > thus: is there an standard or recommended behavior for handling/resolving
> > multiple `<location>` elements for a single `<track>` in XSPF?
> > thanks
> > : http://xspf.org
> > : http://xspf.org/xspf-v1.html
> > : http://xspf.org/xspf-v1.html#rfc.section.184.108.40.206.220.127.116.11.1
> > PS: also posted to StackExchange
> > https://stackoverflow.com/questions/41101769/multiple-
> > location-elements-per-track-in-xspf
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Playlist