Bug 157488 - Totem could not startup
Summary: Totem could not startup
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: totem
Version: 4
Hardware: i386
OS: Linux
medium
medium
Target Milestone: ---
Assignee: John (J5) Palmieri
QA Contact:
URL: http://fedoranews.org/tchung/fc4-test...
Whiteboard:
Depends On:
Blocks: FC4Target
TreeView+ depends on / blocked
 
Reported: 2005-05-11 23:07 UTC by Thomas Chung
Modified: 2013-03-13 04:48 UTC (History)
6 users (show)

Fixed In Version: 1.4.0-2
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2006-04-23 15:47:55 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description Thomas Chung 2005-05-11 23:07:13 UTC
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:

Comment 1 John (J5) Palmieri 2005-05-12 16:09:30 UTC
Can you get a backtrace of this?  I just did an update and totem works fine.

Comment 2 Thomas Chung 2005-05-12 20:21:46 UTC
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

Comment 3 John (J5) Palmieri 2005-05-12 20:26:40 UTC
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.

Comment 4 Thomas Chung 2005-05-12 20:46:18 UTC
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

Comment 5 John (J5) Palmieri 2005-05-12 20:58:49 UTC
Bastien, do you have any idea about this?  It is not a crash.  What resource is
totem trying to grab that it can't?

Comment 6 Thomas Chung 2005-05-12 23:01:38 UTC
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


Comment 7 John (J5) Palmieri 2005-05-12 23:04:17 UTC
Can you post any relevent output from /var/log/messages?

Comment 8 Thomas Chung 2005-05-12 23:16:09 UTC
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

Comment 9 Bastien Nocera 2005-05-13 10:27:24 UTC
I guess that this is alsa/alsasink suckiness.

Try replacing "alsasink" with "osssink" in gstreamer-properties (Multimedia
Systems Selector in the preferences menu).

Comment 10 Ronald Bultje 2005-05-13 10:52:29 UTC
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

Comment 11 Thomas Chung 2005-05-13 16:46:53 UTC
(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

Comment 13 Thomas Chung 2005-05-13 16:52:23 UTC
(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



Comment 14 Thomas Chung 2005-05-13 17:01:20 UTC
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



Comment 15 John (J5) Palmieri 2005-05-13 17:08:35 UTC
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.

Comment 16 Thomas Chung 2005-05-13 17:17:54 UTC
(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


Comment 17 Tim Lauridsen 2005-05-17 08:45:08 UTC
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)





Comment 18 Thomas Chung 2005-05-17 16:44:22 UTC
(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


Comment 19 Thomas Chung 2005-05-17 16:53:48 UTC
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

Comment 20 Ronald Bultje 2005-05-19 09:03:49 UTC
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.

Comment 21 John 2005-06-12 19:16:22 UTC
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. :)

Comment 22 John 2005-06-12 19:25:13 UTC
One more step:

4) run /sbin/pam_console_apply to immediately apply the new set of console
permissions.

Comment 23 Thomas Chung 2005-06-13 20:53:06 UTC
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

Comment 24 Tim Lauridsen 2005-06-15 09:57:08 UTC
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)

Comment 25 Thomas Chung 2005-06-15 17:04:15 UTC
(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


Comment 26 hussain 2005-06-17 20:53:59 UTC
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

Comment 27 hussain 2005-06-17 21:26:37 UTC
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.

Comment 28 Ronald Bultje 2005-06-18 07:45:06 UTC
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?

Comment 29 hussain 2005-06-18 12:07:18 UTC
(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.

Comment 30 hussain 2005-06-19 11:43:24 UTC
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.


Comment 31 jarki 2005-06-21 18:24:48 UTC
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

Comment 32 John Thacker 2006-04-15 15:39:30 UTC
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.

Comment 33 John Thacker 2006-04-15 19:54:36 UTC
"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.

Comment 34 John Thacker 2006-04-23 15:47:55 UTC
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.)


Note You need to log in before you can comment on or make changes to this bug.