KDEPIM 4.6 prob^Wimpressions

[Duncan]

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 
indeed! =:^)

(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
> which.
> 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.

FWIW, here...

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 
you...)

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 
freedomware principles!)

> 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 
displayed.

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.
Archives: http://lists.kde.org/.
More info: http://www.kde.org/faq.html.