https://bugs.kde.org/show_bug.cgi?id=524893
[email protected] changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEEDSINFO |CONFIRMED Ever confirmed|0 |1 Resolution|WAITINGFORINFO |--- --- Comment #8 from [email protected] --- (In reply to finn from comment #3) > Thanks for following up. Sorry for the account mix-up, I no longer have > access to the account I originally reported this with, but I am the same > reporter (kydkunlf). No worries! Thank you as well for responding so promptly, and with further troubleshooting info. > I was able to narrow this down using a different M3U playlist as a test > case, and it looks like the root cause is broader than just YouTube-link > parsing: relative paths in M3U playlists appear to be resolved against the > process's working directory instead of the playlist file's own directory. > ... > I'd guess the playlist parser needs to resolve relative entries against the > M3U file's own path (QFileInfo(playlistPath).absolutePath() or similar) > rather than the application's CWD. I did a bit of testing tonight on my own machine, and was able to reproduce the issue with some of my own m3u playlists, generated by Haruna via "Save As...". Not only that, but I also uncovered a little more about it as well through compiling from source, after modifying some of the source code with `qDebug()` to print paths to the console in the m3uparser.cpp . Source cloned from the github master branch for this testing (Commit b8ed91b, specifically) In short, Haruna's m3u playlist parser (on this current commit) does actually handle relative links correctly, however as experienced, this behaviour seems a bit inconsistent. When relative, absolute, and URL paths are mixed, things seem to break (especially so if the playlist file does not begin with `#EXTM3U` to hint its type, which only the compiled-from-source build seems to do for my setup). I'll perform more extensive testing tomorrow and try to narrow down the exact ways it breaks however. Will also as look into patching/updating the parser to detect and handle M3U playlists a bit better. Since M3U format does not have a formal specification, some older playlists, or ones that simply do not conform to Extended M3U conventions, may cause undefined/buggy behaviour due to the parser silently failing. Better handling for these cases is perhaps needed, since so long as a path is valid, it should be handled appropriately and not cause an error. Personally would like to try writing a patch to get more familiar with KDE development as a whole, however if either you or the developer go about this first, that's ideal! I certainly am not the most skilled dev out there, but have written enough parsing scripts that this shouldn't be too difficult to add better support for. If you're experienced with programming as well (especially Qt), I highly encourage looking through at the source and contributing as well! At any rate, will work on this a bit more this week and report back any new findings and note any pull/merge request here should that be done. Besides all that, setting this report to Confirmed status, and changing title for accuracy. -- You are receiving this mail because: You are watching all bug changes.
