[vlc-devel] .xspf, ml and Windows

[Rafaël Carré]

On Tue, 23 Jun 2009 19:40:31 +0200
Jean-Baptiste Kempf <jb at videolan.org> wrote:

> 
> Blocking the release is still the various xspf issues and file:/// vs
> file:// issues:
> 
>  - ml.xspf is never opened at start because it tries to open
>    file://C:\...\ml.xspf instead of file:///C:\...\ml.xpsf. Therefore
> it is rejected...

should be fixed iiuc

>  - saving a playlist in .xspf works well, but opening fails to
> recognize file:///C:\file.mp3 like elements saying it cannot open
> '/C:\file.mp3'

[a654d4a14edf1a3925cfa731c965652832f01ef2] didn't handle windows, this
is easy to fix.

courmisch thought (rightly) that xspf shouldn't decode file URIs to
file paths.

When I proposed this patch (signed off by courmisch, ahem) my main
concern was that qt4 and ncurses interfaces (at least) would show ugly
URIs (file:///folder%20music/music.mp3).

Perhaps the OSX interface is concerned as well, and perhaps other parts
of the code using input_item_t->psz_uri like a file path.

I didn't (and don't) want to check all the code for that and proposed
this quick solution.

Now I reverted this part on master, so no URI conversion happen in XSPF
mux/demux.

As for 1.0 I prefer to leave the code like it is, unless someone checks
that there is no problems with it of course (I won't check myself).

> As far as I am concerned, this is blocking the release.

What else?

Re-reading my commit I found that album art support will likely be
broken on windows for the same reason (file:///C:/folder/img.jpg will
be decoded to /C:/folder/img.jpg), so an helper function to decode file
URIs to file paths would be a nice to have.

-- 
Rafaël Carré
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <http://mailman.videolan.org/pipermail/vlc-devel/attachments/20090623/52e38bea/attachment.sig>