https://bugs.kde.org/show_bug.cgi?id=500740

            Bug ID: 500740
           Summary: Wrong handling of relatives paths when loading from
                    m3u file
    Classification: Applications
           Product: Haruna
           Version: 1.3.3
          Platform: Other
                OS: Linux
            Status: REPORTED
          Severity: normal
          Priority: NOR
         Component: generic
          Assignee: georgefb...@gmail.com
          Reporter: s.we...@web.de
  Target Milestone: ---

Created attachment 178876
  --> https://bugs.kde.org/attachment.cgi?id=178876&action=edit
patch to fix relative path handling in m3u files

SUMMARY
Currently when loading an m3u files which contains relativ paths the paths are
loaded as http urls instead as file paths.

STEPS TO REPRODUCE
1. Create an m3u file with relative paths
2. open the m3u file inside haruna


OBSERVED RESULT
The playlist view shows for each entry an http url and cannot be played.

EXPECTED RESULT
The files are properly shown in the playlist view and can be played

SOFTWARE/OS VERSIONS
(available in the Info Center app, or by running `kinfo` in a terminal window)
Linux/KDE Plasma: Gentoo Linux 2.17
KDE Plasma Version: 6.3.1
KDE Frameworks Version: 6.11.0
Qt Version: 6.8.2

ADDITIONAL INFORMATION
The Problem ist that QUrl::fromUserInput(QString) interprets relativ paths
(e.g. subfolder/video.mp4) as an network uri.
QUrl::fromUserInput("subfolder/video.mp4") -> http://subfolder/video.mp4
>From the documentation https://doc.qt.io/qt-6/qurl.html#fromUserInput
"In order to be able to handle relative paths, this method takes an optional
workingDirectory path. This is especially useful when handling command line
arguments. If workingDirectory is empty, no handling of relative paths will be
done."

Currently haruna tries first loading the m3u entry with a call to
QUrl::fromUserInput only passing the string to it.
And then it checks if the resulting QUrl instance is empty. If so it calls
QUrl::fromUserInput again but now with the path to the folder (where the m3u
file is locates) as working directory.

The proper fix for this is to always pass the location of the m3u file as
working directory.
I have attached an patch which I'm currently using when building haruna from
source under gentoo

-- 
You are receiving this mail because:
You are watching all bug changes.

Reply via email to