Nope… same cable.
And I know it is working because I can load OM Lx 2014 and Dolphin reads the same phone with the same cable just fine.
And I would bet that if I re-install 3.03 everything will work perfectly… until that one single system upgrade ruins it, just like before.
Nope… same cable.
if your system is stable after a reinstall of 3.03 you might consider not upgrading until you can find out
more about what caused the problem .
I was using pcman file manager ounce and clicked on one of the buttons under the devices tab for my phone
and it deleted the entry I closed pcman and opened Dolphin , well my phone entry was not there either
I can’t remember what I did to fix it…have to check my notes , pcman still does not worker right , the mouse pointer just spins in a circle and it won’t list my phone when connected by usb.
I was considering that. I suppose I could re-install, and back up prior to each upgrade, restoring to the previous state when the error occurs. Pretty time-consuming methodology… I would prefer pinpoint diagnostics and correction, but it should work if nothing else is available.
What would be great is if you could identify what package is causing the issue. Right now there aren’t any developers with time to try to reproduce this so we need to narrow down the issue for them. An unfortunate consequence of an all volunteer community distro with a small community.
We do have more people developing than we did a year ago so there is progress on that front. But it is still to small of a group to do everything we wish we could. Same for QA-Team which has not grown and suffers even more from a lack of people involved.
Edit: There is a really high probability that this is an ups-stream issue. So dosen’t it make more sense to ask where there are a 100 times more developers available?
Thanks for the reply. I do appreciate the situation.
Probably the best way to conclusively isolate and identify the fault would be to re-install Lx 3.03, and back it up prior to each upgrade, so as to be able to restore it to the previous working state when it does fail. Then at least I could identify the related upgrade files.
While I wish I could offer to provide higher level technical assistance, I think the best I can do for now is to participate at the Q.C. level as a user. Hopefully, I can provide worthwhile input that will assist others as well as resulting in resolving my own dilemmas.
I really do appreciate this distribution, and I would like to help make it better somehow. I’m not that skilled as a programmer, but I am good with the English language in spoken and written and communication, particularly of a technical nature… attention to detail, logically oriented, etc. If you know of any way I might be of greater value to this community, please share your thoughts.
BTW, I did post to the KDE forum site, here is the link:
[KIO client error: Dolphin cannot access Android smart phone • KDE Community Forums]
Someone there referred me to a posted bug report that does appear relevant, and has been confirmed with multiple corroborative posts.
Also I did restart Lx 2014 earlier this evening, and the same hardware works with Dolphin flawlessly.
Thanks again, Ben.
Reporting stuff here does help QA. A lot in fact. And I don’t do a good enough job of recognizing and encouraging that.
And if you do narrow this issue down any I’ll take it to developers myself. Or if someone comes up with something at kde forum.
I did finally find a way:
If you hook up the phone to the computer via USB, while the computer is booting up, and you unlock the phone - you can access the phone no problem (at least that worked for me).
that’s one way for the computer to see it ,
Thanks for the hints.
I know a few ways to access the data on the phones, so I’m not helplessly stranded.
What I really want is to make Dolphin functional again.
what were the two files you updated ?
I sure wish I had copied them down.
Maybe there is a way to determine the file names from system logs.
Or maybe I could get that information from OpenMandriva.
Isn’t it another post on the same issue as,
Thanks for pointing that out. I just closed both of those as there has been no activity for a while.
As mentioned above in post 24 this is an upstream issue:
However it goes further upstream than KDE and turned out not to be a kernel issue rather an issue with udev (under systemd) that users did not see until changes in kernel code with kernel 4.14:
In that report as you can see there were 2 commits on May 27 and June 2, 2018. Post-edit: Removed some comment here that may not be accurate.
Post-edit: I should back up a bit. Those commits were submitted but I don’t know if they have been accepted or deployed yet. Or if they work or …
Oh, what tangled webs we weave…
…even when we don’t practice to deceive!
Some pretty deeply intricate fault tracing going on here.
Upon paying a bit closer attention to what I was reading…
The KDE bug report is still marked “Confirmed” not Resolved. The # 8221 but report against systemd/udev on Github has not even been assigned.
This serves to also point out to users why when they do an update and something happens it is not automatically OpenMandriva that did it other than that we re-package upstream packages and by that problems get passed downstream. The vast majority of packages in Linux distros aren’t developed by the distro but are re-packaged just this way.
This also serves to illustrate why when users do an update and it updates some basic system or tool-chain packages that it may not always be the package it first looks like that is at fault. Most commonly this occurs with kernel updates but does happen with other packages as well.
I hope to heck I’m not being to “preachy”.
I hope to heck I am teaching other users (as well as myself). I definitely am learning as do this “Community Helper” process. And I do learn things from all of you as well. So thanks for that.
You’re doing a great job with a tricky subject, Ben,
(I know it helps to enable the other side to see what you’re up against, so I appreciate your asides.)
Thanks for your assistance AND your comments.
This bug shows a work around for this in Comment # 25. Or maybe it is fixed in KFrameworks packages 5.48.0. We have KFrameworks packages 5.48.0 in main-testing repo right now so we shall see.
Now that bug is showing it as a further upstream issue with systemd. So not fixed yet for users apparently.