Bug 365867 - Export to remote storage fails
Summary: Export to remote storage fails
Status: RESOLVED FIXED
Alias: None
Product: digikam
Classification: Applications
Component: Plugin-WebService-FileTransfer (show other bugs)
Version: 5.0.0
Platform: Arch Linux Linux
: NOR normal
Target Milestone: ---
Assignee: Digikam Developers
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2016-07-19 16:07 UTC by Michael Rasmussen
Modified: 2022-01-02 13:07 UTC (History)
3 users (show)

See Also:
Latest Commit:
Version Fixed In: 7.5.0
Sentry Crash Report:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Michael Rasmussen 2016-07-19 16:07:28 UTC
Selected remote storage is an existing directory on the computer running digiKam. 
After clicking to start the export a dialog box appears:

Upload not completed
Some of the images have not been transferred and are still in the list. You can retry to export these images now.

None of the image files are copied to the target location. 
My UID does have write permissions to the location.

Reproducible: Always

Steps to Reproduce:
1. Select images to export
2. Launch dialog
3. Use Select Target Location to navigate to chosen directory
4. Click Start Export

Actual Results:  
Error described above, no image files copied

Expected Results:  
Image files copied to target directory
Comment 1 Maik Qualmann 2016-07-22 10:24:45 UTC
The problem is not to reproduce here, it works as expected. Are your kipiplugins up to date or even on a beta version?

Maik
Comment 2 Michael Rasmussen 2016-07-22 23:19:00 UTC
kipi-plugins are at version 5.0.0-1
libkipi at version 16.04.3-1
(I believe the -1 is the Arch package sub-version)
Comment 3 caulier.gilles 2016-07-23 08:31:08 UTC
Problem not reproducible here too. I can connect to a remote ftp server if i need.

Run digiKam from a console and look the debug traces when you run the tool.

Gilles Caulier
Comment 4 Michael Rasmussen 2016-07-23 15:57:12 UTC
tail of log showing error:
kipi.plugins: Received new thumbnail for url  QUrl("file:///srv/photo/LT_Diskmichaelrpdx_365_05_P1030133.jpg")  for view  KIPIPlugins::KPImagesListView(0x3a2f0230)
kipi.plugins: KIPI host send thumb ( QSize(256, 144) ) for  QUrl("file:///srv/photo/LT_Disk2012-09-02_06-42-17_50.jpg")
kipi.plugins: Update thumb in list for  QUrl("file:///srv/photo/LT_Disk2012-09-02_06-42-17_50.jpg")
kipi.plugins: Received new thumbnail for url  QUrl("file:///srv/photo/LT_Disk2012-09-02_06-42-17_50.jpg")  for view  KIPIPlugins::KPImagesListView(0x3a2f0230)
kipi.plugins: Call for url  "file:///tmp/export" , valid =  true
kipi.plugins: Updated upload button with listNotEmpty =  true , targetUrl().isValid() =  true
kipi.plugins: pass here
Couldn't start kuiserver from org.kde.kuiserver.service: QDBusError("org.freedesktop.DBus.Error.ServiceUnknown", "The name org.kde.kuiserver was not provided by any .service files")
couldn't create slave: "Unable to create io-slave:\nklauncher said: Error loading '/usr/lib/qt/plugins/kf5/kio/file.so'.\n"
couldn't create slave: "Unable to create io-slave:\nklauncher said: Error loading '/usr/lib/qt/plugins/kf5/kio/file.so'.\n"
Comment 5 Michael Rasmussen 2016-07-23 16:14:47 UTC
err, sorry, /usr/lib/qt/plugins/kf5/kio/file.so does exist.
version is kio 5.24.0-1  
on Arch Linux

kuiserver - added to system
Now only create slave errors persist

kipi.plugins: Received new thumbnail for url  QUrl("file:///srv/photo/LT_Diskmichaelrpdx_365_05_P1030133.jpg")  for view  KIPIPlugins::KPImagesListView(0x3a2f0230)
kipi.plugins: pass here
couldn't create slave: "Unable to create io-slave:\nklauncher said: Error loading '/usr/lib/qt/plugins/kf5/kio/file.so'.\n"
couldn't create slave: "Unable to create io-slave:\nklauncher said: Error loading '/usr/lib/qt/plugins/kf5/kio/file.so'.\n"

Checking Google and https://bugs.kde.org/show_bug.cgi?id=360217

Removed files in ~/.cache/ that were created today.

Recreating ksycoca file ("/home/michael/.cache/ksycoca5_en_7Tso86tWbrl0wcB7L7FQ_kr1wIA=", version 303)
kf5.kservice.sycoca: Parse error in  "/home/michael/.config/menus/applications-merged/xdg-desktop-menu-dummy.menu" , line  1 , col  1 :  "unexpected end of file"
Saving
kipi.plugins: Starting Remote Storage export
kipi.plugins: Updated upload button with listNotEmpty =  true , targetUrl().isValid() =  true
kipi.plugins: pass here
couldn't create slave: "Unable to create io-slave:\nklauncher said: Error loading '/usr/lib/qt/plugins/kf5/kio/file.so'.\n"
couldn't create slave: "Unable to create io-slave:\nklauncher said: Error loading '/usr/lib/qt/plugins/kf5/kio/file.so'.\n"
QXcbConnection: XCB error: 3 (BadWindow), sequence: 13078, resource id: 6894025, major code: 40 (TranslateCoords), minor code: 0


Next step?
Comment 6 caulier.gilles 2016-07-23 17:11:10 UTC
Welcome to the insoluble puzzle of KIO slave. This is why we have dropped all KIO slave support in digiKam, excepted for this plugin which is optional at compilation time of course.

So it's typically a packaging and installing problem. It's on your system (config or something like that). Contact your distro team for any help.

Gilles Caulier
Comment 7 Michael Rasmussen 2016-07-23 20:25:12 UTC
Solved and Have a Workaround:

Work Around:
Open graphical file manager. 
Navigate to destination.
Drag and drop images.

Solution:
I will go a long time before reboots and will upgrade the system (pacman -Syu) at least weekly.
Last reboot was June 12.  Between then and today kio and kio-extras were upgraded four times.

A system restart  brought the kio system back into sync. 

Note to developers; Thank you for not suggesting a reboot. Though in this case it was called for.
Comment 8 Luigi Toscano 2017-01-03 22:19:30 UTC
(In reply to caulier.gilles from comment #6)
> Welcome to the insoluble puzzle of KIO slave. This is why we have dropped
> all KIO slave support in digiKam, excepted for this plugin which is optional
> at compilation time of course.
> 
> So it's typically a packaging and installing problem. It's on your system
> (config or something like that). Contact your distro team for any help.

Instead of removing the usage of transparent file systems for users, did you try to raise the issues on the appropriate mailing lists? I don't remember any discussion related to this on kde-devel@, kde-core-devel@ or kde-frameworks-devel@.