Relative URIs don’t work in annotated playlists #3743
Replies: 5 comments 8 replies
-
|
Hi @Moonbase59,
Also, what's the current working directory for the liquidsoap script? |
Beta Was this translation helpful? Give feedback.
-
|
Can’t convert everything, because the same playlists are used elsewhere… But if I convert one (for testing) manually, they work sometimes. My 2-entry test playlist works: but a 63-entry file doesn’t: The latter one only generates silence. The current dir is Relative paths should normally be resolved with respect to the location of the playlist file. |
Beta Was this translation helpful? Give feedback.
-
|
I asked you to manually resolve files for reproduction purposes only. I can confirm that liquidsoap resolves files in annotated playlists relative to CWD, not the playlist file itself. |
Beta Was this translation helpful? Give feedback.
-
|
No offense. Just tried to explain that these are on a NAS and mounted from many different machines, on different mount points, so relative paths were the choice. Of course I did convert a few just to test. :-) Think it would be possible to fix this, i.e. have them resolve to the location of the playlist, much like "normal" playlists work? Thinking of embedded Liquidsoap, like in AzuraCast, it might not always be possible to change the CWD to the location of the playlist… |
Beta Was this translation helpful? Give feedback.
-
|
From a system point of view, I don't think that it is reasonable to expect much from relative URIs. Your assumption that it should be referering to the playlist file is not the usual one. in fact. In most situations, relatives URIs are resolved relative the current working directory (CWD) which is the directory from where the user is typing its command. In general it cannot be expected that all URIs come from a single playlist. URIs can for instance be pushed individually to a In some specific simple case, such as a simple text playlist with relative URIs, it might have been possible to pre-process each URI to resolve the relative URI based on the base playlist. However, as soon at the URIs start being more complex such as one with When that happens, the URI is being processed through a generic protocol resolution making it impossible to resolve relative URIs in a consistent way except from using the CWD. Lastly, the notion of current working directory is essentially a terminal notion, relevant from the perspective of a user being logged into a terminal. When setting up an automated system, it is not wise to rely on this notion. Typically, a daemonization utility such as In conclusion, if you expect your system to be robust, I would absolutely recommend against using relative URIs anywhere. It seems to me that your initial remark is because of a lack of referential consistency: a URI with relative path is resolved relative to a playlist when the URI is just the path but not when it is prefixed. As explained above, this is a discrepancy in the resolving conditions. If anything should be done about on liquidsoap side, I would suggest in this case to remove the simple relative URI pre-processing so as to not confuse the use about what will happen when their simple URIs/playlist start being used in a more comple context with protocols and prefixes. |
Beta Was this translation helpful? Give feedback.
-
|
Couldn't you strip all the protocols from the playlist entry and make the path absolute when you parse the playlist and then re-add the protocols? The liquidsoap/src/core/playlist_parser.ml Lines 76 to 83 in 0d8e6ee |
Beta Was this translation helpful? Give feedback.
-
|
Well, this could be possible but this also assumes that we can detect with certainty that the last element in the chain is expected to be file and is a relative path. In the most general sense, anything after I might design something for it that would more systematic. hold on. |
Beta Was this translation helpful? Give feedback.
-
|
I think it would be great if there would be a separate Syntax for protocol arguments and file/url it is acting on, so liquidsoap can always split it. Something like I already ran into that problem, when I wanted to use my prefix-protocol with a |
Beta Was this translation helpful? Give feedback.
-
|
Thinking about it more: This also means, that the order of execution of protocols is kind of weird right now? E.g. you can't do something like Something like |
Beta Was this translation helpful? Give feedback.
-
|
"Inner to outer" sounds right. I just have this problem using my "Stackable" would really be nice, but as it is, to run an external binary on the files, I have to resolve AzuraCasts |
Beta Was this translation helpful? Give feedback.
-
Describe the bug
I have all my playlists using relative URIs, example
Test.m3u:and they play just fine.
When I try to annotate entries, example:
Test-processed.m3u8:I get an
Nonexistent file or ill-formed URI "../../Other/Jingles/test-5-15-5-15-5s.mp3"!error.To Reproduce
Expected behavior
Relative URIs working with annotated playlist files.
Version details
Install method
.deb
Beta Was this translation helpful? Give feedback.
All reactions