KDEPIM 4.6 prob^Wimpressions

[Alex Schuster]

Duncan writes:

> Alex Schuster posted on Thu, 21 Jul 2011 16:07:33 +0200 as excerpted:
> > Duncan writes:

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

Sounds good! Also the thing about window settings you posted.


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

Yes, I'm indeed thinking about this. Alas, when I've done this in the past, 
even in the 3.x days, it never helped that much. But I will give it a try. 
It will take a while to re-create things as they were. And I'll have to 
decide which things to keep. Archives of the comic plasmoid, customized 
starters, window rules, all those little files in share/*/. Well, let's 
see., I think I'll start bare, and maybe copy application configs back 
later.

> 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, 

I hope you are right.

> be sure and back it up, so you can restore a clean
> but customized backup. =:^) 

Sure, I do this all the time. I still have about 35 backups of my .kde 
directory, and that's only because I already deleted many.


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

Well, I didn't think it could have to do anything with phonon. Let's see if 
it happens again, it didn't for some days now.


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

Wow, I'm a little surprised about these problems. Sending sound to a device 
doesn't look so complicated to me. Looks like it probable deals with more 
than I thought.


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

I wasn't surprised, but it would have been nice if it had survived.


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

Nah, I'll spend the time in starting from scratch now.

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

My fear is that I make errors, and they are not so obvious. And much later, 
strange things happen because of them, so things have gotten even worse, but 
I don't address them to my changes.


> I'm still running on the same kde subdir I've been using since kde-2 (!!
> ).

(!!!)


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

Both may be true. I have some reputation for attracting bugs. 


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

[snip]

Um, there's a misunderstanding here. I never run KDE applications as root. 
But I'm very sure that I was not able to kill all of the 2x2 kded4/knotify4 
processes because they were owned by root. I wondered a little how that 
could be. Maybe because I made some changes with systemsettings? Or is it 
KDM itself who does this?
BTW, I often noticed these processes while I am not on my desktop, working 
on it via an NX session, but without KDE applications. So I did not even 
notice this, but another user of system complained that all is so slow, and 
his niced processes are nearly stalled.

Now I feel sorry because you wrote so much about the being root issue :(


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

Would you mind sharing the script? I also kill those processes sometimes, 
but manually, just in case they are making trouble.


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

I have it installed and use it sometimes, after bigger KDE upgrades. I don't 
like to reboot, somehow I find it just inelegant. it also takes quite a 
while, and my desktop PC also acts as CVS and Git server and runs a Wiki, so 
I try to minimize downtime.


> > 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 know :)  Normally, I don't run Acrobat, but I have it installed for cases 
when I need to do more complex things with PDFs, like editing my tax forms.

But why is it started by Okular?!

Removing .kde4 now. Let's see what happens.

	Wonko
___________________________________________________
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.