gentoo posted on Tue, 22 Dec 2009 15:46:35 +0000 as excerpted: > Thanks for your reply Duncan, > <snip> > > After re-emerging hal udev dbus pmount I still had no notification > pop-up. Looking harder at this problem, I have identified 2 issues and > rectified them. 1. The dvd drives were not acpi compatible, so I have > changed them and now the tray stays closed. > 2. I have deleted .kde4 and reloaded kde, When I originally installed > kde4 I copied the original .kde3 directory and renamed it .kde4 I now > have kde running properly and if I insert a usb disc or insert a cd I > now get the notification pop-up with the options. So far so good.
=:^) > However, alsaplayer and kscd are still not working. I also have > problems playing dvds in kmplayer or xine, the picture keeps breaking > up. I don't know about alsaplayer, but at least here, kscd seems only able to cope with one CD/DVD drive. If you have more than one, the other one is ignored, tho there's an option somewhere (unfortunately IDR where ATM, but look in "the application formerly known as kcontrol", now unfortunately inaccurately and /waaayyy/ too generically called systemsettings, even tho it controls kde, NOT the system as a whole) to change which one it points to, if desired. The breaking-up picture is probably because you have too much eye candy running for your resolution and graphics card. Try disabling compositing temporarily when you're playing video. There's a keyboard shortcut for it, or it's in desktop effects in "the application formerly known as kcontrol". Also... back in kde3, the powerful media player was kaffeine. There's a live version or pre-release or some such available for kde4, but it's an emasculated wimp compared to its former kde3 self. Fortunately, there's an already quite mature qt4 based media player, smplayer, that's if anything even more powerful than kde3's kaffeine was. =:^) The biggest difference is that while kaffeine is based on xine, smplayer is mplayer based. But most folks interested in media on kde4 will have both installed anyway, xine for the audio backend, and mplayer as a dependency of mplayerthumbs, used to generate video thumbnails, and they both play more or less the same formats, so there's not /that/ much difference. But certainly checkout smplayer, if you'd like the ability to single- frame-step thru your videos, do variable speed playback, etc. It's definitely more powerful than the kde4 default dragonplayer, etc, in that regard. I've been /very/ happy with it! =:^) >> Something else you might consider, tho it's not urgent and AFAIK is >> unrelated to this, but who knows? /dev/hd? indicates that you're still >> using the old kernel ide drivers. Those are now officially deprecated, >> with the newer libata SATA/PATA drivers the encouraged replacement >> (yes, even tho the config still says pata's experimental). They'll use >> sd? notation instead of the older hd? notation, so then you'll not have >> any hd? devices at all. Unless you /know/ that you don't have libata >> support for your old ide/pata chipset, I'd strongly encourage you to >> consider switching... at your leisure, tho. > I have now switch off the old pata drivers and have noticed that my hard > disks are now sga sgb etc. I now use kernel 2.6.31 <snip> > I have been running a amd64 system with a lot of packages that are > marked ~amd64. > So I have decided to go to a full blow ~amd64 system in the hope that my > remaining problems will be resolved. ~arch does mean more and faster updates and that you should be prepared to resort to an alternate boot image, live/rescuecd or the like, in ordered to fix things if necessary, but that's a good idea in any case. And at least a package is normally tested to work on the developer's ~arch system before it's keyworded ~arch, even if it's not tested to the degree that stable is. But a half-stable half-~arch system is a no-man's- land, really not tested, nor practically testable since there's so many possible variants, at all. So if you're running more than a very limited set of ~arch packages (with few dependencies), I'd definitely recommend ~arch over stable with many ~arch packages. At least that's known to work on the dev's full ~arch system, something that cannot be said of a half-way ~arch installation. > Thanks for your time, I'll let you know how things go after the 400 > packages to be built. > Paul =:^) FWIW and as I mentioned in a post a few days ago, I'm in the process of building a new ~x86 system image for my netbook. I had a stickler of a problem with X, due to copying one too many config files from my amd64 machine without editing, so mesa and xorg-server wouldn't build because they were looking in a non-existent (in the 32-bit chroot) lib64, instead of in lib, that took a few days to trace and resolve, but now I'm in the "install hundreds of packages" phase myself, so I know what you're feeling! Let's see... the last stall trying to merge kde4 was ffmpeg. It failed, with 180 packages dependent on it to go. I got that running (use=pic works better on amd64 where it's used for libs anyway, than on x86, so I'm now running use=-pic on the 32-bit chroot image)... It finished 112 out of 180 before the next failure, but I run with --keep-going, so portage is, after dropping kmail and kaddressbook due to the libkleo failure... It has now completed 10 of 56 of the remainder. Assuming no further issues with the remaining 46, when they finish I'll have to look at libkleo and figure out what went wrong with it before trying kmail and kaddressbook again... If I'm lucky, the libkleo failure was a one-off (missing dep or something), and it'll "just work" when I try it again. If not, hopefully it'll be at least as easy to fix as the ffmpeg one was... check bugzilla and it's already reported, with a workaround (use=-pic in that case) available. =:^) If I'm unlucky, it'll be like the mesa and xorg failures, and take me a couple days of hacking to trace and figure out... only to find it was my own config error. If I'm /really/ unlucky, it'll be a real bug that nobody has a fix/workaround for, yet. But those aren't very common, fortunately, and when they are, when it's something as commonly used as a kmail dependency, usually other people start hitting it pretty quickly and /someone/ finds a workaround/fix. -- 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
