parser not working passing url

[bjoernpetersen]

parser not working passing url

[BjoernPetersen]

There are three overloaded M3uParser.parse() methods:

• fun parse(m3uFile: Path, charset: Charset = Charsets.UTF_8): List<M3uEntry>
  • This one loads an .m3u file from your local filesystem
• fun parse(m3uContentReader: InputStreamReader, baseDir: Path? = null): List<M3uEntry>
  • This one loads the .m3u content through the given InputStreamReader, which is just the abstract notion of a "stream of characters". Those could come from a file, a streamed HTTP response, or basically anywhere, but you as the caller will have to take of this
• fun parse(m3uContent: String, baseDir: Path? = null): List<M3uEntry>
  • This one expects the content of an .m3u file as a String

What you're doing is passing your URL to the third variant, so it's interpreted as the content of an m3u file, so your result is just a single M3uEntry with the URL you passed in. This behavior is intentional, the parse method is not trying to do anything "smart", it simply parses the content of a single m3u file.

There is the M3uParser.fun resolveNestedPlaylists(entries: List<M3uEntry>): List<M3uEntry> method that will recursively resolve any entries that point to another m3u file. This only works for local files, though. The library will never try to follow HTTP(S) URLs. Implementing that would involve a lot of complexity (retry logic, proper error handling, error communication to the app using the library) and some security/privacy risks (so there should be an opt-in toggle for people that want to avoid us making HTTP calls). Since I'm not actively using this library myself right now, I probably won't take the time to implement remote m3u resolution anytime soon.

As a workaround, you could just download the m3u file in your own app (to a temporary file, or even just in-memory), and pass the content to this library. Looking at your specific example though, the m3u you're referencing just contains a single URL (http://stream.webradio.bz:8000/vivalaradio3), so if that m3u is your only use case, and you're not expecting the m3u to change in the future, you don't need this library at all.

[ArcaDone]

Your explanation is absolutely clear. I don't know if it will always remain the same however I have seen that using the link you provided me as a solution everything actually works correctly. Thank you very much for your contribution and I think we can close this issue. Thanks

[BjoernPetersen]

You're welcome!