| Summary: | video files no longer play from network shared directories | ||
|---|---|---|---|
| Product: | [Applications] dolphin | Reporter: | dr.ue |
| Component: | general | Assignee: | Dolphin Bug Assignee <dolphin-bugs-null> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | kdedev, kfm-devel |
| Priority: | NOR | ||
| Version First Reported In: | 25.08.1 | ||
| Target Milestone: | --- | ||
| Platform: | unspecified | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | KIO 6.19.0 / Dolphin 25.08.2 | |
| Sentry Crash Report: | |||
Tested step 1 not with Dolphin, but with PCManFM and Thunar. PCMan prompted whether to remember the credentials and for how long during step 2. Then gwenview worked as expected (well, the navigation arrow keys worked to move from jpg to mp4, but nav arrows seemed to stop working from then). But video files could play in Gwenview from network shared location, if opened from PCManFM not Dolphin. Thunar was a similar experience, but it did not prompt to login to the smb, so where ever PCManFM was storing the credentials, Thunar seems to have had access to. Dolphin does not appear to have access, as it's behavior did not change, even after logging in to the share via PCManFM. I believe this isn't a Gwenview issue anymore, but Dolphin (or wherever Dolphin stores credentials, or whatever process is responsible for accessing and sharing the credentials, assuming it is a different process than what PCManFM and Thunar use). I have used the "Browse" function in Gwenview to replicate the error. So something about how Dolphin and Gwenview accesses and saves the credentials is broken, where Thunar and PCmanFM can successfully pass the credentials to Gwenview (and presumably ffmpeg). The popup window for entering the credentials is different, so it makes sense there is some different underlying process for accessing the smb location. But I don't know enough to tell why one works and the other doesn't. Thanks for the bug report, and the detailed troubleshooting. I wasn't able to reproduce this on git-master I tested with a samba share that requires authentication, checking "Remember password" In Dolphin, I selected a png file and opened with Gwenview, it was opened. I also tested by connecting using an entry in /etc/fstab and playing an mp4 video I am able to reproduce the bug with Plasma 6.4.5, so it looks like this has been fixed, and should be in Plasma 6.5.0 (or the 6.19.0 kio framework) |
SUMMARY STEPS TO REPRODUCE 1. navigate to a network share location (smb or sftp tested) in Dolphin 2. Dolphin prompts for login credentials 3. After login, double click video file *.mp4, *.webm (or 'open with' gwenview if double click action on file type doesn't default to gwenview) OBSERVED RESULT Media does not play EXPECTED RESULT Media should play (and did before updating) SOFTWARE/OS VERSIONS Windows: macOS: (available in the Info Center app, or by running `kinfo` in a terminal window) Linux/KDE Plasma: (tested Tumbleweed and Fedora 43 RC) KDE Plasma Version: 6.4.5 KDE Frameworks Version: 6.18.0 Qt Version: 6.9.2 ADDITIONAL INFORMATION Here is a debug log at bottom. It seems like the worker retrieves the password correctly from cache but doesn't successfully pass it to the codec (ffmpeg). Not sure if that is a KIO issue, a QT issue, a gwenview issue, or a ffmpeg issue. Only happens with video files. JPGs from the network share open fine in gwenview, it's interfacing with ffmpeg that fails to play. File permission is the same (644). This functionality worked before an update that was pushed around 4-5 months ago. Worked for years prior. Sep 24 16:40:25 localhost.localdomain kioworker[5921]: kf.kio.workers.smb: QUrl("smb://user@192.168.0.10/path/er") Sep 24 16:40:25 localhost.localdomain kioworker[5921]: kf.kio.workers.smb: checkURL QUrl("smb://user@192.168.0.10/path/er") Sep 24 16:40:25 localhost.localdomain kioworker[5921]: kf.kio.workers.smb: checkURL return3 QUrl("smb://user@192.168.0.10/path/er") Sep 24 16:40:25 localhost.localdomain kioworker[5921]: kf.kio.workers.smb: updateCache "/path/er" Sep 24 16:40:25 localhost.localdomain kioworker[5921]: kf.kio.workers.smb: Starting discovery. Sep 24 16:40:25 localhost.localdomain kioworker[5921]: kf.kio.workers.smb: auth_smbc_get_dat: set user= user , workgroup= WORKGROUP server= 192.168.0.10 , share= path Sep 24 16:40:25 localhost.localdomain kioworker[5921]: kf.kio.workers.smb: updateCache "/path" Sep 24 16:40:25 localhost.localdomain kioworker[5921]: kf.kio.workers.smb: libsmb-auth-callback URL: QUrl("smb://192.168.0.10/path") Sep 24 16:40:25 localhost.localdomain kiod6[5321]: kf.kio.kpasswdserver: User = "user" , WindowId = 0 Sep 24 16:40:25 localhost.localdomain kiod6[5321]: kf.kio.kpasswdserver: key= "smb-192.168.0.10:-1" expire= 1 window-id= 0 keep= false Sep 24 16:40:25 localhost.localdomain kioworker[5921]: kf.kio.workers.smb: got password through cache "user" Sep 24 16:40:25 localhost.localdomain kioworker[5893]: kf.kio.core.connection: Socket not connected QLocalSocket::PeerClosedError Sep 24 16:40:25 localhost.localdomain kioworker[5893]: kf.kio.core: An error occurred during write. The worker terminates now. Sep 24 16:40:25 localhost.localdomain gwenview[5867]: [smb @ 0x7fb60c0022c0] File open failed: Permission denied Sep 24 16:40:25 localhost.localdomain gwenview[5867]: qt.multimedia.ffmpeg.mediadataholder: Could not open media. FFmpeg error description: Permission denied