The new totem ebuilds (2.18.0 and 2.18.1) have silently dropped the ability to compile totem with the xine backend, which was done before with the xine USE flag. If 2.18.x is emerged now it defaults to the gstreamer backend. DVD playback doesn't work with the gstreamer backend. When you try to play a disk totem gives the error message: "Totem cannot play this type of media (DVD) because you do not have the appropriate plugins to handle it." xine backend support should be re-added into the ebuilds. I tried to do this so I could submit a patch but for some reason it was automatically stripped and I do not know enough about writing ebuilds to know why (perhaps eautoreconf). Reproducible: Always Steps to Reproduce: 1. Put in a DVD 2. Play the DVD with totem 3. Actual Results: Totem gives the error message "Totem cannot play this type of media (DVD) because you do not have the appropriate plugins to handle it." and does not play the DVD. Expected Results: The DVD should play. See forum thread: http://forums.gentoo.org/viewtopic-p-4030202.html#4030202 I am running AMD64 with the ~amd64 keyword.
It was dropped for several reasons : 1) upstream decided to switch the default build to gstreamer (even if DVD playing is sub par) 2) most (if not all) gnome herd members used the gstreamer backend and therefor found it too much work to test everything with xine too 3) totem's xine backend was also giving the gentoo xine folks a headache as most bugs could not be reproduced using gxine or xine-ui. It's unfortunate but bugs kept piling up without anyone really fixing them. Sorry. For reference, you can still play dvds with totem from a shell running "totem dvd:///dev/dvd".
We're no longer supporting the xine backend.
*** Bug 181421 has been marked as a duplicate of this bug. ***
(In reply to comment #2) > We're no longer supporting the xine backend. > Then remove it from the tree do no force people who do not use gnome but use totem to install 3/4th of gnome just to use the tool. If it is the much of a problem recruite people. The fact is most of gnome herd is useless and dang does all the work leaving him as the only person mantaining anything gnome related.
Created attachment 121582 [details] updated ebuild with xine support Here is the ebuild that is too much too support even tho I threw it together in less then 5 mins.
(In reply to comment #4) > (In reply to comment #2) > > We're no longer supporting the xine backend. > > > > Then remove it from the tree do no force people who do not use gnome but use > totem to install 3/4th of gnome just to use the tool. If it is the much of a > problem recruite people. The fact is most of gnome herd is useless and dang > does all the work leaving him as the only person mantaining anything gnome > related. > Totem is a _gnome_ app. Upstream (gnome devs) decided they don't have enough people who care about xine backend to keep maintaining it and there is a bunch of bugs with it anyway, so they just dropped it. We won't continue supporting what upstream dropped support for. If you feel it's is wrong, then please complain to upstream.
Listen Bugs, First of all, insulting people won't get you very far. I already believe I'm wasting my time answering, but here's to hoping you may actually listen. The problem isn't the ebuild, the proof being you made one yourself in 5 minutes. The problem is the XINE BUGS THAT WE CAN'T FIX. There, I said it. For months/years, there has always been hard and tedious work trying to fix xine bugs in Totem with the xine team in Gentoo, with the Totem upstream and with the xine upstream. Bugs kept piling and there's nothing we could do about it. Our solution, _drop_xine_support_. If you want it, fine. Do it in an overlay, that's what overlays are for. If you want upstream to care about it, provide patches. But stop whining here, our reasons are well known and well explained. Thanks for understanding.
what about restoring the xine USE and put a big fat warning which says not to complain about bugs and problems? totem's ./configure still supports xine-lib and I never saw those big problem you're talking about (maybe I'm lucky?). I consider the inability to play dvd with menu a bigger problem. Finally gentoo is about choice, give us users the way to choose. Thanks
(In reply to comment #8) > what about restoring the xine USE and put a big fat warning which says not to > complain about bugs and problems? > Yes please. It is annoying to have to maintain a separate totem build just to watch dvd's.
when did actually upstream dropped xine support? as i see in change logs they have even push new fixes for xine in unstable 2.19.x...
well unlike some have stated here... xines future with totem isnt clear upstream and thank you bugs for the ebuild ... it works fine here... gstreamer isnt a good replacement for xine yet
The return of xine backend in any form in portage tree depends on resolving upstream bug http://bugzilla.gnome.org/show_bug.cgi?id=459539 This is also somewhat mentioned in GNOME 2.18 Upgrade Guide.
*** Bug 191120 has been marked as a duplicate of this bug. ***
first some facts: * www.gnome.org/projects/totem/ clearly states the support of xine * other linux distribution ship totem 2.18.x with the xine back * I was not able to find any hint (beside this bug and the upgrade guide) why upstream dropped the xine-backend looking at this, it is obvious that there are quite a few comments of unhappy users in the gentoo forum about totem not having xine anymore. for me it seems to be a gentoo decision, and would it be stated as such I could live with this. but the only offical gentoo explanation is that "upstream is going to drop the xine-backend" and this is really hard to verify. and if you suddenly miss something, you look for a reason. when I found out that totem did NOT drop xine until now and the ebuild can be easily rectified, I was really irritated. I as well other, as you can read in the forum, will keep their overlay ebuild of totem with xine support until upstream REALLY drops it.
We _know_ all this, please stop. The problem _we_ have is that we don't have enough resources (time, people actually testing and willing to fix things) to maintain it. Like I said a few days ago on another bug, if you want xine support back, start fixing bugs!
Just to be clear, it was only a misunderstanding that xine backend would be dropped for 2.18. Bastien Nocera clarified the situation a while ago on his blog iirc (and by a while I mean months) saying that he will continue to maintain the xine backend as long as DVD support isn't provided by gstreamer (I mean menus, ...). Now from the point of view of the gnome herd, afaik, nobody uses the xine backend so it's hard to fix bugs that you can't even test or reproduce. xine backend support will come back either when a dev will take care of the xine part and/or when the backend will be runtime selectable though some team members might want to correct me if I'm wrong here.
Created attachment 136951 [details, diff] totem-2.20.1 xine support I'm not sure if I should post this, but perhaps it will be useful to some folks. Here's a patch which adds support for the xine backend to the latest totem ebuild, via the "xine" USE flag. Compiles cleanly, without warnings. Sorry for repeating what others have proposed, but here goes: Since this was the only method for playing DVDs with menus properly (mplayer's dvdnav support doesn't quite work), and I've never had any xine backend-specific problems, wouldn't it be ok to include the USE flag in the official ebuild? People would still have to enable it themselves (gstreamer is still the default). If necessary, a warning could be printed saying that this backend isn't officially supported by Gentoo so people shouldn't file bugs unless they've got patches. The xine dependencies aren't that hard to maintain (there's just one dep :) ). At least it would be less hassle for people to enable the USE flag as before rather than having to maintain a spare ebuild in an overlay.
Again, it's not the ebuild that's hard to maintain but the bugs that come from using xine. Thanks for posting the ebuild, I'm sure people who want proper DVD menus in totem will like it, but for now, we won't commit that ebuild to portage.
*** Bug 224183 has been marked as a duplicate of this bug. ***
*** Bug 230907 has been marked as a duplicate of this bug. ***
OMG the bugs from xine ? Reasons to reenable the xine use flag for totem. : 1. Freedom of choice 2. gstreamer backend crashes easily ( play an mpeg2 video and scroll back and forth fast ) 3. gstreamer backend still does not support accelerated playback xvmc ( play an mpeg2 video and compare cpu consumption to an xine based player - in my case instead of idling gstreamer playback makes my cpu go to full frequency wasting money ) 4. As far as I know by reading on the web gstreamer backend still does not deinterlace e.g. mpeg2 videos - I cant check it because totem with gstreamer backend crashes before I can skip to a position in a video where I can check it. Go ahead and fix those bugs in gstreamer - until then remove gstreamer support from totem and make xine the only backend ( following your own arguments ). ( Patch to add xine use flag to totem-2.22 https://bugs.gentoo.org/show_bug.cgi?id=230907 )
(In reply to comment #21) > OMG the bugs from xine ? (snip) > Go ahead and fix those bugs in gstreamer - until then remove gstreamer support > from totem and make xine the only backend ( following your own arguments ). Please leave the condescending tone outside bugzilla, we have no need for it. *We* will be the ones to triage and fix bugs, *we* will be the ones having to take care of things when they break, therefor *we* don't want Xine back for now. Simple. As for your "freedom of choice" argument, you're 100% free to make your own ebuild in an overlay without ever telling us about it _because_we_don't_care_! Thanks
