playlist pointing at files with relative filenames, via secondary playlists, wrongly managed by VLC

Hi,

For personal choir rehearsals, I want to launch VLC on a simple playlist1.m3u file (current directory conventionally named here curdir) containing : subdir/playlist2.m3u

subdir/playlist2.m3u containing (here referring to subdir/file.mp3 file) : file.mp3

I expected VLC to read subdir/file.mp3, in the same directory as playlist2.m3u. Exactly what does VLC when directly launched on subdir/playlist2.m3u.

What VLC considers instead is (../curdir/)file.mp3, omitting subdir directory, which of course results in 'File not found'. For me it is clearly a VLC bug.

---

This structure of a primary m3u playlist, simple list of files, pointing at other m3u secondary playlists files, in subdirectories, themselves pointing at mp3 files named with relative paths is essential for me. For information, secondary playlists include bookmarks lists, a very useful added information.

This scheme will permit me to send playlists to other chorists for a direct use within VLC at their home.

This scheme is rotten currently as absolute paths are the only ones working everywhere, but different for each chorist. Manually editing paths is unmanageable by most persons. Other solution is to put all m3u playlists and mp3 files in a single directory, which is not a good solution either.

---

Secondary xspf playlists with relative mp3 filenames give the same results than in m3u files.

Please ask for more information if everything is not clear enough.

Thank you for considering this problem which is very embarrassing to me, breaking a promising working method.

Alain

assigned to @jbk

This is correct. It's a VLC bug.

added Component::Demuxers: Playlist label

added Difficulty::easy label

assigned to @Courmisch and unassigned @jbk

changed milestone to %3.0 FF

Fixed in 2.2.0-git-8395-gf6d5ec36 and 2.2.0-git-9349-g914cb05a

added Status::fixed label

closed

Sorry but the announced fix is not applied in version 2.2.6 !

I am very disappointed about that since I feel I cannot distribute a personal tool + documentation (in French) which promote the use of VLC and m3u playlists, since the bug is a blocking one for sharing playlists with other people.

Just as a reminder of the problem, simply consider 2 playlists and 1 audio file as in : playlist1.m3u (cites) subdir/playlist2.m3u (which cites) audio.mp3

While reading ./playlist1.m3u VLC should access subdir/audio.mp3 and not ./audio.mp3, as currently.

May I hope this ultra basic problem will be solved some day ?

Thanks. Alain

removed Status::fixed label

reopened

This is fixed in 3.0, as said in the ticket.

added Status::fixed label

closed

Milestone renamed

Thanks for the quick answer. I have noticed that 3.0 FF is expected in 4 weeks, not so long to wait... It seems to me you are working very hard to release this new version, many thanks.

I know this is not the right place to ask for such help but where is it ? I will be honoured if somebody from the VLC team would accept to review my documentation (in French) on VLC (annex of 34 pages) mainly in order to avoid propagate errors about VLC.

Thanks in advance. Alain

This is really not a good place to ask that question. Not that many people read bug reports.

Try the web fora or mailing lists.