KDEPIM 4.6 prob^Wimpressions
1i5t5.duncan at cox.net
Fri Jul 22 05:12:56 BST 2011
Alex Schuster posted on Thu, 21 Jul 2011 16:07:33 +0200 as excerpted:
> Duncan writes:
>> Alex Schuster posted on Tue, 19 Jul 2011 18:27:59 +0200 as excerpted:
>> > Then there's kded4 and knotify4, I often have two of those processes
>> > running and eating all CPU time until I kill them, this happens on
>> > another KDE4 desktop,
>> > too.
>> I believe that's ultimately down to instabilities in the audio system
>> (alsa, pulse-audio if you use it but I think you don't, etc). Or it
>> could be phonon-backend related. Fortunately, I don't have that sort
>> of issue here now, tho I have in the past.
> No, I don't use pulse-audio. It's not too bad, when I see the CPU
> running, it usually is those two processes, and just kill them. This
> does not seem to harm, I hope this is true. My current strategy is to
> wait for 4.7 and see if it still happens.
I've been very happy with 4.6.95 (4.7-rc2). There was one hiccup but I
couldn't reproduce it. But 4.6.95 has certainly been as stable as a
release version here, and in fact, I'm happier with it than I was with
anything in the normal 4.6 series. The best kde4 versions I've run are
therefore 4.5.4/4.5.5, and 4.6.95. If 4.7.0 and the rest of the 4.7
series turn out as nice as 4.6.95 has here, I'll be a happy camper
(Do note, however, that I'm still on kdepim 4.6.1. I don't think they
released kdepim-4.6.95, or if they did, it wasn't available with the rest
of them, as the ebuilds could never download the sources, so I simply
undid the 4.6.95 unmask for kdepim and remained on 4.6.1. I expect/hope
kdepim re-syncs with the release cycle for the rest of kde sometime
during 4.7, but don't expect a 4.7.0 release at least at the same point
as the rest of kde, and likely not 4.7.1 either. Maybe with 4.7.2 or so,
seems like it'd be reasonable. And shoot for improving monthlies for the
rest of the 4.7 cycle and if we're lucky a nicely stable kdepim-4.8.0 to
go along with the kde 4.8.0 in general. =:^)
Meanwhile/however, given your problems, I strongly suspect that your user
config is screwed up, likely multiple files since you've listed quite a
few problems that I haven't had with the same version (on the same
distro). If that's true, as I suggested in another post, it may be that
you won't get rid of the whole set of constant bugs unless/until you
clean out the config and effectively start from scratch reconfiguring.
As I said when I mentioned that before, I normally don't recommend that
(tho I do recommend bisecting the user config reasonably frequently...
when it's a single problem), because in general that's not a solution I'd
consider valid for me. However, as you were mentioning potentially
switching to a different DE entirely, and you'd have to configure it
essentially from scratch, doing that again for kde isn't any different
than for another DE, except that you're already familiar with the
available settings and where to find them, in kde.
Then once you get a clean config that's actually working reasonably well,
as I expect it will, be sure and back it up, so you can restore a clean
but customized backup. =:^) You have a backed up config now, but it
apparently includes some partially corrupt files as you took it after you
already were having problems, so restoring gets you back to some
semblance of working, but not to stability.
>> There's several possibilities for that. One is setting the phonon
>> output to the dummy audio device -- no effects or kde system sound, but
>> anything using alsa directly, etc, should still work. I believe I did
>> that for a time back in the kde3 era (before phonon, obviously).
> Although there are few system sounds I hear, so I probably wouldn't even
> notice they're gone, I somehow would not like to be without any.
Yeah, but if they begin eating 100% cpu on a core...
I'd just play music (using something that doesn't go thru phonon)
instead. Then I'd not miss the effects. =:^)
>> Another is switching the phonon backend. phonon-xine gave me problems
>> here but I've been very happy with phonon-vlc. Some others have had
>> good results with phonon-gstreamer but quite some time ago I had
>> problems with gstreamer and it's an entire subsystem that I've avoided
>> having on my system every since, tho in fairness the gstreamer problems
>> are very likely long since gone, but I just don't want to load all
>> those dependencies again for one little thing, and since I have
>> everything else using something else, it's /always/ just one little
>> thing, that would be changing over, so I never try gstreamer...
> I'm using GStreamer, and Xine is also on the list. I think I read one is
> deprecated and the other should be used, but I do not remember which was
> And now that you mention phonon-vlc, I remember reading somewhere about
> it and it sounded good. So I emerged it, and switched the backend.
> Whoops, Amarok crashed. But it seems to work fine, let's see if the
> situation with kded4/knotify4 improves. Although it didn't happen for
> 2-3 days now.
As Anne already replied, it's phonon-xine that's deprecated. I don't
have gstreamer installed and wasn't particularly interested in installing
it, so I've not personally tried it, but phonon-vlc worked FAR better for
me than phonon-xine. However, a number of posters have said that phonon-
gstreamer worked better for them but phonon-vlc gave them problems too,
and phonon-gstreamer /is/ both the kde and gentoo default, now.
So now I definitely recommend getting off of phonon-xine as I've just
seen way too many people have problems with it and it IS deprecated. But
phonon-gstreamer or phonon-vlc, which one of those works best apparently
depends on the system.
As for amarok crashing, you're not /supposed/ to switch things out from
under it while it's playing! =:^[ But hopefully all is and remains fine
once the new backend is up and working.
>> > Oh, and plasma, it often hangs, or crashes, forgets its settings.
>> That has been quite stable for me lately, perhaps because after an
>> issue earlier and having to hand edit a very complex
>> plasma-desktop-appletsrc, I've been rather careful about playing around
>> with it.
>> I DID edit out some serious cruft from that file, tho. Few will be
>> willing or able to spend the time I did to figure out the file and hand
>> edit it like that, but wiping it and starting from scratch may help, as
>> it's quite possible there's some cruft in there that's causing
>> instabilities, especially if you're using the same base file as you
>> were back in the early 4.5 era, which is when I had my issues and wiped
>> out the cruft with a hand edit.
> I once fixed some problems with this file, when the desktops had
> switched their order. This happened for again a couple of times, but now
> I just copy back the file from a backup. I did not dare to remove more
> of the cruft, because I am not sure if it really is cruft, or if I might
> damage some things.
Well, you're already doing the copy from backup thing. You might as well
double-check the backups, then edit the file more drastically and see
what happens. =8^0
When I edited it, once I figured out and to some extent traced the
logical tree it uses (which was not easy!, that file is the most complex
ini-style file I've ever seen, and the section names could definitely be
more descriptive!), the orphan sections stood out like sore thumbs. I
figured it was safe to delete them (and I had a backup anyway, if I
turned out to be wrong) and I was right.
Based on that experience, back in the early 4.5 era, I believe there were
some bugs back then that would orphan sections, and those orphan sections
unfortunately still tend to confuse plasma. That triggers a crash when
the logic doesn't add up, and the crash often makes things worse by
creating even more orphans.
If you can get all the orphans out, at least in my experience, plasma is
MUCH more stable after that. However, if there's still some orphans left
in your backup, plasma will appear to work fine part of the time but
won't be stable and will keep causing even worse corruptions when it
crashes, plus will occasionally go off on strange tangents, suddenly
creating new activities on its own, forgetting some or all settings, etc.
As I said above, I believe that's a microcosm of your entire kde setup
right now. You're constantly having problems with this or that, to the
point where it's my belief that the only way to regain real stability is
to start with a clean slate, as if you were setting up kde for the first
time, without trying to use our old config files because once you bring
in a bad one, it'll start that one thing crashing, but that's likely to
trigger other issues, and the problems will likely spread from there.
> The last time I started with a clean .kde directory was June last year,
> with KDE 4.4.4.
... And late 4.5 (4.5.4 or 4.5.5) is when kde4 really hit its stride.
4.6 regressed, but at least for me based on the experience of 4.6.95, it
looks like 4.7 should be pretty good too. But I'm afraid you're not
going to experience it as you should, because you'll still be dealing
with crufty files that are causing you all sorts of problems.
I'm still running on the same kde subdir I've been using since kde-2 (!!
). However, a few months after I switched to kde4, I sorted thru things
and deleted or backed-up-and-deleted, just in case, depending on what it
was, a whole bunch of files and dirs that based on the dates and/or
names, didn't appear to be in active use any longer. IIRC I wasn't wrong
on any of them.
And, I think I've been a bit stricter than you at tracing and eliminating
bugged configs before the bugs start piling up, too. The problem I
suspect you have based on reports is that enough stuff got unstable, than
you can fix one file, but something else crashes soon after, due to a
different problem, and often it'll take with it something you've already
fixed. So you're playing whack-a-mole with the bugs, and the bugs are
winning! It's time to poison the whole lot of them at once and start
clean, which in this case, means starting with a fresh config.
Because otherwise, you're one seriously unlucky guy. Because that's a
LOT of bugs you've been having, more than would ordinarily be explained
by the simple differences in our hardware and general usage, since we're
on the same distro and generally (tho not since I decided to try 4.6.95)
running the same versions.
> Good thing I have my backup. So I just started rdiff-backup-fs in order
> to browse through the snapshots. Right at this moment, or maybe a little
> earlier, system load went up A LOT, to about 45. The cause were kded4
> processes, in total I had 39 of them! Killed them. They were running as
> my user, while those two pairs of kded4/knotify4 I sometimes see run as
> root, at least some of them.
OH!! *THAT* might explain some of the issues! It's extremely seldom
that I run anything kde as root (or any other user), so I don't have two
copies of bits of kde running as different users fighting over the same
resources (sound card, etc).
Nearly everything I do as either root or my admin user, I do in konsole.
Sysadmin-hat file management? mc, in the konsole. Sysadmin-hat
anything, either a non-X VC/bash session, or using sudo in konsole.
If you DO run kde apps as root, please at least turn off all sound-
effects, etc, for root's kde. If you want, set it to system-bell
instead, and then set that to visual-bell (invert-color or single-color
flash), or just turn off root notifications, sound effects, etc. That
way, only your normal user will be trying to access the hardware.
Meanwhile, I /have/ noticed that kded, etc, occasionally don't die when I
logout of kde as my user, when I'd expect them to. That usually doesn't
cause much issue, tho I've configured a kde-shutdown script to shut down
those things that I've noticed, automatically via the script, since
often, when I'm shutting down and then restarting kde it's because I just
upgraded stuff and want to use the new versions. But if the old ones
don't quit, lib_users (a script that reports apps using libraries that
have been deleted, etc, it's in portage...) tells me they're still using
the old and otherwise deleted files instead of the new ones. So since
I'm often shutting down to restart with the new ones anyway, having the
shutdown script automatically stop the kde stuff that wants to stay
running when kde shuts down, so when I restart kde, it uses the upgraded
versions, saves me from having to manually stop the processes every time.
And if you're running kde apps as root and kded, etc, are continuing to
appear after you've finished with whatever the apps were, I'm guessing
you're hitting the same thing with it, only it's causing even more
problems, because now not only do you have stuff still potentially
running old and supposedly deleted libs, but you have two users's apps
fighting over resources, one of which is root! And that's not going to
work very well, regardless!
So... several points, here.
1) Try not to run kde apps as root in the first place, so the problem
can't even start.
2) Configure your root kde notifications to no-audio output (that's under
manage notifications, player settings tab, in kcontrol), and then
optionally, use system bell instead of system notification (that's under
system bell), use visible bell (that's under accessibility, bell tab,
uncheck the two items for audio bell so it's only using the visible
bell). That way, root audio shouldn't get triggered.
3) When you're finished running kde apps as root (or any user other than
the main kde user logged in), ensure that their kded and etc quit with
the apps, and if necessary, kill them. (If it's often necessary,
consider setting up a script that you can easily invoke to do it for
4) While we're at it, consider installing lib_users and running it after
updates to see what apps you need to restart to get them using the new
versions of either them or their libraries. Of course, you can simply
reboot since then, everything will be fresh versions, but doing the
libusers thing may or may not be easier. It's quite possible some of the
issues might be due to inconsistencies with long-running apps still using
deleted versions of updated programs/libs, while new ones try to use the
new versions, thus creating occasional conflicts in memory and other
resources. (This isn't so likely on Linux, but still does happen
occasionally, and I was annoyed enough at seeing bits of kde still
running when I had shut it down and was back at the command prompt that I
setup a script to ensure they were properly terminated or killed if
necessary. That may or may not help explain why I've not had quite the
rough experience you have with kde, but ensuring that the system remains
self-consistent certainly isn't going to HURT matters any!)
> And there was one acroread process eating CPU time. ps -axf shows it was
> started by nspluginwrapper, which was started by 'kdeinit4: konqueror
> [kdeinit] --silent'. What is going on here...
Of course you know my response there... it's proprietary blackbox
software whose authors have already demonstrated a disregard for the
rights of their user, so anybody still choosing to run it... simply ends
up a servant serving at the whims of their proprietary software
masters... That's /one/ thing my freedomware-only installation policy
means I don't have to worry about, here! =:^) (YMMV, do what you like as
it's your system not mine, but the position I take on running stuff like
that on my system is clear. Of course I couldn't legally run it anyway
since I can't agree to the EULA, etc, and those are at the very least
presumed to be legally valid here in the US, which rather eliminates the
possibility of my trying it even if I DID decide to yield a bit on my
> I like to make screenshots of such events, this way I noticed that the
> PrintScreen key no longer starts KSnapshot. I wanted to take a note of
> this in my KNotes KDE4 log, but the KNotes icon in the system tray does
> not react to left button clicks. I had this before once. Other things in
> the tray work, but the KMix icon looks different now (colored, not only
> white as it used to be), and it opens the mixer when pressed, instead of
> showing a volume slider. Oh, and the hidden icons (accessible by
> clicking the little white arrow at the right) are all visible. Well, the
> next login will probably cure this, seems it's about time.
At least with kmix, that sounds like it's running as a normal app, not a
kde system service, which means it thinks it's not running in a kde
environment but in something else (gnome or whatever).
Which could be because of kded issues, or if somehow it's running as a
different user, or...
>> > I did not use webkit yet because I simply did not know how, the
>> > settings dialog in Konqueror only showed KTHML. But browsing through
>> > the package database I found kde-misc/kwebkitpart, and after
>> > installing I have the webkit option.
>> /That/ must be what I'm missing! Sure enough, it's not installed.
> Let's see if this will make you use Konqueror again.
Unlikely. It might have prevented a switch due to the work involved in
switching (getting my bugzilla and various site passwords stored in the
new browser, login cookies for the few sites where I do actually login,
figuring out the differences in how firefox manages those sorts of
things, which I didn't bother with when it wasn't my default browser,
etc), but now that all that's done, the benefits of firefox are clear
enough, it's highly unlikely I'd go back.
Even just one benefit is enough to take the cake. The firefox noscript
extension makes browsing with scripting off by default, while being able
to allow it for exactly the sites I decide to trust, and for that matter
just being able to SEE what sites a particular page is trying to load
scripts from in ordered to even CONSIDER enabling them, so much simpler
than other alternatives I've seen, it's not even funny! Plus, the
noscript surogates feature for stuff like google-analytics, which I block
for privacy reasons, is a feature that's pretty much simply not available
period, anywhere else. (I could hack in the surrogates as privoxy
substitution filters, since I also run it and routinely do similar for
various page sections, css-file sections, etc, but... noscript surrogates
are rather easier in that regard and unlike privoxy filters, apply to
secure connections as well, so...)
>> > Akregator seems to honor it. When Konqueror is set to use webkit, I
>> > can watch embedded youtube videos in Akregator that only show up as
>> > black boxes otherwise.
>> I'll have to try it. Maybe it'll show images for me. akregator
>> doesn't here, at present, despite my having konqueror set to show them.
>> It may be that I have on-disk cache turned off in konqueror, tho, but
>> as I use privoxy, turning that on can cause stale refresh issues after
>> I edit a privoxy filter or set it to bypass.
> Strange, it always showed them here.
I'm almost positive that's a side-effect of having konqueor's disk-
catching turned off -- I think akregator uses that for caching images,
etc, too, so if it's off, they don't get pulled down and thus can't be
AFAIK there's an akregator setting that's supposed to control whether it
uses konqueror's cache, or a separate one, but until now, I thought that
akregator not pulling images might be a feature, not a bug, so I didn't
know to try changing it. (Certainly, there's no akregator config warning
that having konqueror set not to keep a disk cache while having akregator
set to use it, will break images, which is what appears to be happening,
now that I know that akregator /normally/ shows images.)
>> Since I only use the akregator preview pane, and open in (a real)
>> browser instead of in new akregator tab when I click a link, that
>> wouldn't be an issue, here. Then again, if akregator's browser tabs
>> worked more like real browsers, I might actually use them!
> Doesn't this give you lots of browser windows? Or does this open tabs in
> an existing Firefox windows? That's how it is here, but when I have
> multiple windows open, new tabs open in the last window I used, which
> often is not the one I want to have the tab in. So I prefer the tabs to
> be in Akregator itself.
This does give me lots of browser windows, yes. (As for new links
opening new ff tabs or new windows, that's a ff option.) In general, I
don't mind that tho, in fact tending to prefer it to a huge number of
tabs. I only use tabs for same-research-thread related stuff (like
opening article images or diagrams in their own tab instead of a new
window or using the back/forward buttons to refer back to them from the
article). If I'm opening a link from another app, that's very likely an
entirely different article and different thought thread from what's in
existing windows, so I want it to open in a new window.
But with a dual monitor setup, with the working monitor arranged so I can
side-by-side two-half-maximized browser windows, plus have additional
windows on the aux monitor above it if desired, and only generally
opening a half-dozen or so at a time (tho I may have others open on other
desktops), it's not bad.
I'm DEFINITELY not one of those folks who runs a single firefox session,
sometimes with 50 or a hundred tabs, never entirely closing it, for days
at a time, who then complain about firefox eating memory. I'll browse
each thought thread in its own window, closing it when I'm done, so
several times a day at least, I have no browser windows open at all, thus
meaning firefox only runs for minutes or occasionally (if I'm working on
something major and referring back to some page for reference) hours at a
time, with very seldom double-digits tabs per window, and seldom more
than a dozen browser windows open at once either.
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master." Richard Stallman
This message is from the kde mailing list.
Account management: https://mail.kde.org/mailman/listinfo/kde.
More info: http://www.kde.org/faq.html.
More information about the kde