From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.8) Gecko/20050510 Firefox/1.0.4 Description of problem: Installed a fresh copy of Fedora Core 4 Test 3. Installed latest updates as of today (2005-05-11) Opened Totem Movie Player from Applications > Sound & Video Totem crashes with message "Totem could not startup. Resource busy or not available" Version-Release number of selected component (if applicable): totem-1.0.1-1 How reproducible: Always Steps to Reproduce: 1. Installed a fresh copy of Fedora Core 4 Test 3. 2. Installed latest updates as of today (2005-05-11) 3. Opened Totem Movie Player from Applications > Sound & Video 4. Totem crashes with message "Totem could not startup. Resource busy or not available" Actual Results: Totem crashes with error message "Totem could not startup. Resource busy or not available" Expected Results: I expected Totem to be open properly wihtout any error message. Additional info:
Can you get a backtrace of this? I just did an update and totem works fine.
Can you give me suggested command line for backtrace? I used gdb with totem. Here is the screenshot with same error. http://fedoranews.org/tchung/fc4-test3/bug/gdb-totem.png Thomas Chung
I need you to install the totem-debuginfo and gtk-debuginfo packages and attach the backtrace from gdb to this report as a text file. Thanks.
I installed totem-buginfo but yum could not find gtk-debuginfo [root@localhost ~]# yum install gtk-debuginfo Setting up Install Process Setting up repositories development 100% |=========================| 1.1 kB 00:00 extras-development 100% |=========================| 951 B 00:00 Reading repository metadata in from local files primary.xml.gz 100% |=========================| 985 kB 00:02 developmen: ################################################## 3599/3599 Added 21 new packages, deleted 21 old in 2.31 seconds primary.xml.gz 100% |=========================| 344 kB 00:01 extras-dev: ################################################## 1010/1010 Added 39 new packages, deleted 0 old in 0.76 seconds Parsing package install arguments No Match for argument: gtk-debuginfo Nothing to do [root@localhost ~]# rpm -q gtk-debuginfo package gtk-debuginfo is not installed [root@localhost ~]# rpm -q totem-debuginfo totem-debuginfo-1.0.1-1 Here is result: http://fedoranews.org/tchung/fc4-test3/bug/gdb-totem.txt Thomas Chung
Bastien, do you have any idea about this? It is not a crash. What resource is totem trying to grab that it can't?
I have an additional information. I ssh into from remote machine. When I run totem and I received a little different error message this time. "Could not access ALSA device "default", check its permission" http://fedoranews.org/tchung/fc4-test3/bug/totem-alsa.png Thomas Chung
Can you post any relevent output from /var/log/messages?
I can't seee any relevent information so I'm posting entire /var/log/messages at http://fedoranews.org/tchung/fc4-test3/bug/messages Thomas Chung
I guess that this is alsa/alsasink suckiness. Try replacing "alsasink" with "osssink" in gstreamer-properties (Multimedia Systems Selector in the preferences menu).
Hi Thomas, do you by any chance have a TV card or a modem or something? I've seen this in a default install once. The problem with TV-cards is that their modules were loaded before ALSA, and thus taking hw:0 (or in the OSS age, /dev/dsp), so that my actual sound card would take /dev/dsp1 or hw:1. Can you run these commands for me to get some more insight? Make sure the audio output in gstreamer-properties is still set to alsasink when doing this! export GST_DEBUG=alsa*:5 totem &> /tmp/log It will once again give the famous error dialog, but it will write some debug info to a logfile (/tmp/log)which you should attach to this bug report. Thanks, Ronald
(In reply to comment #9) > I guess that this is alsa/alsasink suckiness. > > Try replacing "alsasink" with "osssink" in gstreamer-properties (Multimedia > Systems Selector in the preferences menu). Sorry, it didn't help. 1) http://fedoranews.org/tchung/fc4-test3/bug/multimedia-alsa.png 2) http://fedoranews.org/tchung/fc4-test3/bug/multimedia-alsa.png 3) http://fedoranews.org/tchung/fc4-test3/bug/totem.png Thomas Chung
Correction in URL: 1) http://fedoranews.org/tchung/fc4-test3/bug/multimedia-alsa.png 2) http://fedoranews.org/tchung/fc4-test3/bug/multimedia-oss.png 3) http://fedoranews.org/tchung/fc4-test3/bug/totem.png Thomas Chung
(In reply to comment #10) > do you by any chance have a TV card or a modem or something? Nope. No TV card. No modem. > Can you run these commands for me to get some more insight? Make sure the audio > output in gstreamer-properties is still set to alsasink when doing this! > > export GST_DEBUG=alsa*:5 > totem &> /tmp/log > > It will once again give the famous error dialog, but it will write some debug > info to a logfile (/tmp/log)which you should attach to this bug report. Sorry, it did not write anything. Thomas Chung
I have an additional information. If ssh as a root not as a user, I was able to open totem remotely OK. I'm beginning to suspect this is really a permission issue and perhaps related to SELinux. Thomas Chung
If it is related to SELinux you should get log messages in /var/log/messages. If you have the audit daemon installed it would go somewhere else in /var/log. Try booting with selinux disabled to see if it fixes the problem.
(In reply to comment #15) > If it is related to SELinux you should get log messages in /var/log/messages. > If you have the audit daemon installed it would go somewhere else in /var/log. > Try booting with selinux disabled to see if it fixes the problem. Thanks. Acutally, I already tested with selinux disabled (/etc/sysconfig/selinux) but no go. Thomas Chung
I have the same problem, but if found out the by selecting 'XWindow (No Xv)', as default video sink, in the Multimedia System Selector then i can start Totem without any errors. But if i play some video in Totem, it dont look very good :-)))). If i select 'XWindows (X11/XShm/Xv)' and press the 'Test' buttom then i get an error "Faild to construct test pipeline for XWindows (X11/XShm/Xv)" I Have the following video card: (lspci) 01:00.0 VGA compatible controller: VIA Technologies, Inc. VT8378 [S3 UniChrome] Integrated Video (rev 01)
(In reply to comment #17) > I have the same problem, but if found out the by selecting > 'XWindow (No Xv)', as default video sink, in the Multimedia System Selector then > i can start Totem without any errors. But if i play some video in Totem, it dont > look very good :-)))). > If i select 'XWindows (X11/XShm/Xv)' and press the 'Test' buttom then i get an > error "Faild to construct test pipeline for XWindows (X11/XShm/Xv)" Yes, I can confirm that works for me too. > I Have the following video card: (lspci) > 01:00.0 VGA compatible controller: VIA Technologies, Inc. VT8378 [S3 UniChrome] > Integrated Video (rev 01) > I have following video card: 01:00.0 VGA compatible controller: nVidia Corporation NV38GL [Quadro FX 1300] (rev a2) Thomas Chung
Additional note, In addition to ximagesink (no xv) http://fedoranews.org/tchung/fc4-test3/bug/totem-noxv.png sdlvideosink works as well. http://fedoranews.org/tchung/fc4-test3/bug/totem-sdlvideosink.png Thomas Chung
OK, so not alsa, but xvimagesink is "busy". That error needs improvement. So for now, use ximagesink... Now, about the nvidia card being busy. Do you, by any chance, have a widescreen display and are you using the 'nv' driver? I've had that problem, too; there's already a bug open for that.
Is this system an upgrade from an earlier version of Red Hat/Fedora? I suspect that the console users (the user logged into X) is not being granted permission to use the ALSA sound devices, /dev/snd/*. pam_console grants these permissions, but older versions of the configuration file don't grant permissions for /dev/snd/*, since ALSA didn't exist yet. You might have an old pam_console configuration file laying around, which RPM didn't replace/update. Check in /etc/security, and see if /etc/security/console.perms.rpmnew exists. If so, 1) Copy /etc/security/console.perms to a backup location 2) cp /etc/security/console.perms.rpmnew /etc/security/console.perms 3) If you made any changes to the old /etc/security/console.perms, make them to the new copy, too. Hopefully that's actually the problem. :)
One more step: 4) run /sbin/pam_console_apply to immediately apply the new set of console permissions.
Since FC4 final has been released this morning, I'll install FC4 (fresh-install) on the same machine this afternoon and let you know the result. Thomas Chung
I have installed FC4 Final (Clean Install) and i still have the problem. 'XWindow (No Xv)' works, but 'XWindows (X11/XShm/Xv)' dont. (See Comment #17)
(In reply to comment #24) > I have installed FC4 Final (Clean Install) and i still have the problem. > > 'XWindow (No Xv)' works, but 'XWindows (X11/XShm/Xv)' dont. (See Comment #17) Yes, I can confirm that on my system (FC4 Final fresh-install). Same result as FC4 Test 3. If I click on "Test" button while selecting "XWindows (X11/XShm/Xv)" for Default Video Sink, I'm getting "Failed to construct test pipeline for XWindows (X11/XShm/Xv)" Here is the screenshot: http://fedoranews.org/tchung/fc4-final/error/fc4-totem-error-01.png Thomas Chung
The same problem occurs with me, and I also have an S3 Unichrome card. However, after installing S3 Unichrome 3D support as shown in the link below, and editing xorg.conf appropriately, Totem started properly and videos played smoothly. But this solution is not practical, as quite a few vertical lines appeared across my monitor when logging onto X with the 3d drivers. Also, direct rendering was still disabled. When I switched back to the VESA driver (generic), I was back at square one - although there were no vertical lines across the screen, Totem refused to open. Therefore, I believe that this problem could be related somehow to the VESA driver. S3 Unichrome 3D instructions: http://sourceforge.net/docman/display_doc.php?docid=26963&group_id=102048
BTW I'm running Fedora Core 4 (final), clean install. (In reply to comment #17) > 01:00.0 VGA compatible controller: VIA Technologies, Inc. VT8378 [S3 UniChrome] > Integrated Video (rev 01) I also have that exact card.
The gstreamer-properties error really isn't useful (and yes, that needs fixing :) ); do you get any messages on the console when clicking the 'test' button with the "XWindows (X11/XShm/Xv)" option selected?
(In reply to comment #28) > The gstreamer-properties error really isn't useful (and yes, that needs fixing > :) ); do you get any messages on the console when clicking the 'test' button > with the "XWindows (X11/XShm/Xv)" option selected? No: [hussain@sempron ~]$ gstreamer-properties [hussain@sempron ~]$ I clicked test with that option selected and nothing came up on the console.
I tried installing the VIA S3 Unichrome driver again and this time followed the instructions properly - last time I must have made an error somewhere. Anyway, it went well and I got direct rendering. Totem could start up without any problems as soon as I switched from the generic VESA driver, I don't know why but it seems like the VESA driver could be causing the Totem bug.
If the VESA driver cause this then you should not that FC4 does not work with Trident driver, the workaround proposed use VESA driver. Please see https://bugs.freedesktop.org/show_bug.cgi?id=2976
How is this for people on FC5? The switch to gstreamer-0.10 (at least totem 1.3.90, possibly with 1.3.1) should make this work a lot better with autovideosink. Make sure that if you run `gstreamer-properties` that the default video output is set to "Autodetect" (autovideosink). As far as the specific problem with a driver not supporting Xv properly, that should be a separate bug. It does appear that the upstream FreeDesktop bug was closed a few months ago, and should be fixed in FC5.
"If ssh as a root not as a user, I was able to open totem remotely OK. I'm beginning to suspect this is really a permission issue and perhaps related to SELinux." This part of the problem is not going to be fixed. When you ssh in remotely, pam_console does not assign ownership of the sound card to you. This is an intended feature, not a bug. Only the person sitting at the console is supposed to be able to use the soundcard. (Otherwise, people can annoy you by logging in remotely and playing sounds.) Of course, root can override this. I'm fairly sure that all the other problems described work fine with FC5.
No response to request for information, closing, since the switch to gstreamer-0.10 should have really changed this. (Except for the "can't get sound device on remote login if not root," as that's not a bug-- remote users shouldn't get the sound device.)