Sorry but I couldn't find the ebuild submitting guide line so I'll try to improvise... I suggest media-video as the category for this ebuild. I've tested it and it works fine... :)
Created attachment 2469 [details] kxine 0.4 ebuild
I've committed a masked ebuild under media-video/kxine. the reason it's masked is that it builds (after I added a gcc3 patch) but nothing happens when I run it - nothing it all, doesn't print anything to the console, and it doesn't return either. Please test it.
I must say it still works great here... I'm running: gcc-2.95.3-r5 glibc-2.2.4-r9 qt-3.0.4.20020606-r1 kdelibs-3.0.2-r1 kdebase-3.0.2 xine-lib-0.9.12-r1 By the way, where did you get that patch from? // Qerub
I wrote that patch myself, it's quite simple. There is however a very remote possibility that on gcc3 systems (mine but not yours) it actuall breaks something. I've asked for testing among gentoo developers, once I get a least one confirmation that it works ok with gcc3 I'll unmask kxine and send the patch upstream.
I've had a few reports of this, and it seems to be something wrong with the DCOP layer, which is used by the KUniqueApplication (though I am not 100% sure of this, it needs further investigation). Hopefully I'll get some free time soon to take a look at it. Regards, Mark Thomas. (markbt@users.sourceforge.net)
Mark: how common is this problem, then? If other people besides me report it I don't want to unmask the ebuild yet. BTW what do you think about my gcc3 patch? (was going to send it to the author before you showed up :-)
I'm not sure how common it is. I've had three reports of it so far, but I can't pin the exact cause at the moment. My current hunch is that it's something to do with compiling kxine with gcc3 against a kde dcop library built with gcc2.95 (I have no idea why, but this seems to be the common factor). One trace I've had so far indicates that the dcop call to try and discover if the app already exists (it's a UniqueApplication), fails. Could someone who is experiencing this checkout the latest CVS, try it, and if it fails, send me the whole output, plus details of the gcc versions used to build kxine and the kde libraries. If that person could try compiling it with gcc2 also (if they still have it around ;-) and seeing if that works, I would be extremely grateful. Regards, Mark Thomas (markbt@users.sourceforge.net)
Oh, and the gcc3 patch is to add "using namespace std;" lines, right? I keep forgetting those (silly gcc2 not requiring them), but they should all be in CVS now. Regards, Mark Thomas (markbt@users.sourceforge.net)
My sysem is wholly compiled with gcc3.1. I compiled kxine from cvs, same result except that now it outputs: Kxine: starting process Kxine: building first instance But still nothing appears on the screen. However, if I run it rom gdb I get: Starting program: /usr/bin/kxine [New Thread 1024 (LWP 25237)] Kxine: starting process Kxine: building first instance ERROR: KUniqueApplication: DCOP communication error! Program exited with code 0377. I'm using the current kde cvs for kdelibs btw, if you think it's worthwhile to test against 3.0.2 also tell me. Do you want an strace or something?
Hi, Attempted fix commited to CVS, but I can't test it as I can't reproduce it. If you could give it a go I would be grateful. If it doesn't work, then the output would be useful. Regards, Mark Thomas.
No, nothing changed afaics. Same output everywhere. Any other test I can do?
Hmmm... Can you try the simplified test at: http://www.doc.ic.ac.uk/~mbt99/misc/kuniquetest-0.1.tar.gz This is a simple app (just a window), which only does the uniqueness stuff that kxine does. If this doesn't work, then we know where our problem lies.
This says: Calling start Creating first instance newInstance called And shows an empty window. Only one instance can be started. Looks like it works.
The mystery deepens: I found a KDE app, kjobviewer, that is a KUniqueApplication that comes with KDE. The kjobviewer in /opt/kde3/bin does not work. It exhibits the same problem you are having. However, if I get the source from my distro, and recompile it, it works. Something is very much amiss. For now, I have made the use of the KUniqueApplication an option at configure time. If you check out the latest CVS, then the default compile will work, but running kxine again will give you a second instance. For people whom it works for, then can add --enable-unique to the ./configure call and it will be compiled in. I'll have to speak to the KDE people about this: it appears to be a bug in KUniqueApplication.
Sory i didn't get back to you before. I tried the latest cvs and still nothing happens. Now it doesn't even print those 2 lines after starting, it just doesn't return. Last few lines of an strace are: --- access("/usr/qt/3/plugins", F_OK) = 0 writev(3, [{"b\0\6\0\17\0\0\0", 8}, {"XInputExtension", 15}, {"\0", 1}], 3) = 24 read(3, "\1\0X\0\0\0\0\0\1\224`\251\0\0\0\0\1\0\0\0\1\0\0\0\310"..., 32) = 32 rt_sigprocmask(SIG_SETMASK, NULL, [RTMIN], 8) = 0 rt_sigsuspend([] ---- And if I run it from gdb it doesn't say anything after: [New Thread 1024 (LWP 14992)] Hope you can make some sense out of all this.
Hi, I spent yesterday installing gentoo ;-) [SuSEconfig overwrote my custom libGL for the last time!] It's quite nice. I especially liked the addition of the "-j2" flag to "make" so it took full advantage of my two processors -- nice touch. The good (well sort of) news is that now the problem happens to me, too. When I get home from work tonight I will start working on the problem. I have a few ideas what it might be (I think qt's threading is interfering with xine's threading, causing a deadlock in certain circumstances). I'll let you know how I get on...
Hi again. I think I have found out what was wrong: Xine uses the XLockDisplay function to lock the display. Qt uses a completely separate mutex. The result? Synchronisation chaos. (I had tried to fix it, but failed). The only fix for this is to patch xine-lib. I've made a patch that works for me; if you could test it, and let me know if it works (and if it breaks the normal xine-ui, which for me it does not). There are also some changes in cvs kxine so you will need to check that out again. If it all works, then I'll submit the patch to G
Hi again. I think I have found out what was wrong: Xine uses the XLockDisplay function to lock the display. Qt uses a completely separate mutex. The result? Synchronisation chaos. (I had tried to fix it, but failed). The only fix for this is to patch xine-lib. I've made a patch that works for me; if you could test it, and let me know if it works (and if it breaks the normal xine-ui, which for me it does not). There are also some changes in cvs kxine so you will need to check that out again. If it all works, then I'll submit the patch to Günter and the other xine developers, and I'll back-port the changes into kxine-0.4 and produce a patch for that (cvs is some way off of becoming 0.5, as you have probably noticed). Regards, Mark Thomas (still very pleased with his gentoo installation).
Created attachment 2879 [details, diff] Patch for xine-lib 0.9.13 to let kxine work Note: this is for xine-lib 0.9.13. Gentoo currently only has 0.9.12. 0.9.13 can be downloaded from http://xine.sf.net/
Now it works. I finally get to see the kxine screen :-) I'll make a masked test ebuild lib-xine-0.9.13-r1 and ask people on gentoo-dev and -core to test if it breaks their regular xine. Please let me know about the integration of the patch into upstream xine-lib, too.
*** Bug 6320 has been marked as a duplicate of this bug. ***
Hi Again. A few developments have been made: the previous patch is not sufficient for all types of video out (it works for Xv but not XShm). A new patch is on http://kxine.sourceforge.net/ Unfortunately, this breaks binary compatibility, so it will not be part of official xine-lib until 0.9.14 (which has a new API and breaks binary compat anyway). We can either: a) Patch all xine-lib dependent things in portage (although the patch is trivial, I'm not sure how much the writers of sinek and totem would like it), or b) Leave kxine masked until 0.9.14 comes out (may be some time though). I'm okay with either of these. Thanks for all your help, btw.
I vote for patching xine-lib. As kxine.sf.net says, its very minor and wont hurt anything... sinek and totem should work fine with it. And if they didnt work after the patch then we can just stick kxine in the package mask and wait for 0.9.14. but I would love to use kxine.
OK. I've worked out what the patches for totem, sinek and toxine are (interestingly, toxine isn't in gentoo...), and they're located in: http://www.doc.ic.ac.uk/~mbt99/misc/ They're the patches that end in _kxine-fix-3.patch Note that these are *UNTESTED*. I don't have gnome on my system, so I can't test sinek or totem. As for toxine, well, I'm lazy (and my system is loaded out compiling kde-3.0.3). I still think we should wait, at least for kxine-0.5 to come out (0.4 is *so* behind compared to CVS, but CVS only has 25% implemented playlists). I got the whole of next week assigned to kxine development (and playing final fantasy IX---probably share time between them 50:50). With a bit of luck and a following wind, kxine-0.5 will be out on the last day of August.
OK, then let's wait for xine-lib .14. Then, lots of people will be interested in updating and testing totem and the other frontends. We can then use a cvs snapshot of kxine if 0.5 takes too long (a patch against 0.4 would be monstrous I expect). I also happen to be playing FF9 at the moment, and even suspended my Vagrant Story and Xenogears for it (it's a really good game). So I like to delay things whenever possible :-)
...And, of course, we're in a freeze now... I hope xine 0.9.14 will be here soon.
People on kdemultimedia say xine .14 won't ne released before kde 3.1...
I think I've solved the problem, anyway. Current CVS works with a vanilla xine-0.9.13, I think (needs testing, though). I'm working on the playlist at this very moment. Once that's done, and provided there are no problems with the current "solution", I'll be releasing kxine 0.5 When is kde-3.1 going to be released, and how will that affect kxine?
Well, kdemultimedia 3.1 has xine_artsplugin, a video plugin for noatun/kaboodle/etc that uses the xine backend. I don't know how this will affect kxine, that's for you to say :-)
Hi, Back again. Finally got some time to work on Kxine. I'm currently preparing for a release. A Release Candidate tarball is at: http://kxine.sourceforge.net/kxine-0.5-rc1.tar.gz Just waiting on translators now [note: this tarball doesn't have an up-to-date .pot file---that is in CVS] It currently requires Qt 3.0.5, which is OK because Gentoo has that :) It compiles and installs fine on my system, but I thought you might like to check it. I'll post here again when I have finished. Regards, Mark
Well, I'm busy packaging kde 3.1 right now, so I think I'll wait for the final/stable release, or at least a week or so after kde 3.1.
Killing private buglist, everything lives at kde@gentoo.org now...
already in portage tree
