search

pycousin / gnome-mplayer

Automatically exported from code.google.com/p/gnome-mplayer
GNU General Public License v2.0
0 stars 0 forks source link

gnome-mplayer accesses all possible cdda:// tracks on file open #397

Closed GoogleCodeExporter closed 8 years ago

GoogleCodeExporter commented 8 years ago 
What steps will reproduce the problem?
1. Open a video file

What is the expected output? What do you see instead?
With random frequency and without obvious causes, gnome-mplayer quite 
often hangs when opening a video file. What happens is that it tries to 
access all possible cdda:// tracks, hogging resources (it gets to 
cdda://50 in less than 5 sec). Several times this caused an Xfce-freeze, 
while most often it helps to xkill gnome-mplayer or switch to a virtual 
terminal and killall it. This happens either with or without an audio CD 
in the tray. I couldn't get debugging info because of the randomness of 
the event and the freeze of the desktop. 

What version of the product are you using? On what operating system?
gnome-mplayer 0.9.9.2
liviu@debian-liv:~$ uname -a
Linux debian-liv 2.6.30-2-amd64 #1 SMP Mon Dec 7 05:21:45 UTC 2009 x86_64 
GNU/Linux

Original issue reported on code.google.com by landroni...@gmail.com on 5 May 2010 at 12:09

GoogleCodeExporter commented 8 years ago 
I'm gonna need to see a gnome-mplayer -v log of it doing this. gnome-mplayer 
should
only access the cdda device when you select, file -> open disc -> open audio cd

Can you also post your $HOME/.mplayer/config file?

Original comment by kdeko...@gmail.com on 5 May 2010 at 12:58

GoogleCodeExporter commented 8 years ago 
There isn't much in it: 
liviu@debian-liv:~$ cat .mplayer/config 
# Write your default config options here!

[gnome-mplayer]
vo=xv
msglevel=all=5
ao=alsa
vf=eq2

As for the -v log, whenever this occurs I kill the app asap, otherwise I risk a 
system freeze and a reboot. Is it possible to redirect the log output to a file 
that 
will survive the app kill?

Original comment by landroni...@gmail.com on 5 May 2010 at 1:24

GoogleCodeExporter commented 8 years ago 
The logging is not enabled unless you add -v to the command line so something 
like
this should work.

gnome-mplayer -v > ~/gnome-mplayer.log

So you are saying it doesn't happen all the time?

Also, is there a /etc/mplayer/config or /etc/mplayer/mplayer.conf file? 

Also what version of mplayer do you have?

Original comment by kdeko...@gmail.com on 5 May 2010 at 1:28

GoogleCodeExporter commented 8 years ago 
No, it happens randomly, usually couple of times in a week. This log command 
works 
fine, so I'll send a debug as soon as I encounter the behaviour again. 

See /etc/mplayer/mplayer.conf attached.

Original comment by landroni...@gmail.com on 5 May 2010 at 2:00

Attachments:

GoogleCodeExporter commented 8 years ago 
What version of mplayer do you have?

Also, I run gnome-mplayer all the time, and have never seen this behavior. Is it
possible you have the default playlist enabled? Edit->Preferences->Interface 
(4th
checkbox down) and it has cdda items in it?

Original comment by kdeko...@gmail.com on 5 May 2010 at 3:06

GoogleCodeExporter commented 8 years ago 
[deleted comment]
GoogleCodeExporter commented 8 years ago 
Synaptic says it's 1.0.rc2svn20100313-0.0 (on Debian testing)

liviu@debian-liv:~$ mplayer -v
MPlayer SVN-r30656 (C) 2000-2010 MPlayer Team
CPU vendor name: AuthenticAMD  max cpuid level: 1
CPU: AMD Turion(tm) X2 Dual-Core Mobile RM-72 (Family: 17, Model: 3, Stepping: 
1)
extended cpuid-level: 26
extended cache-info: 33587520
Detected cache-line size is 64 bytes
CPUflags:  MMX: 1 MMX2: 1 3DNow: 1 3DNowExt: 1 SSE: 1 SSE2: 1 SSSE3: 0
Compiled with runtime CPU detection.
get_path('codecs.conf') -> '/home/liviu/.mplayer/codecs.conf'
Reading /home/liviu/.mplayer/codecs.conf: Can't open '/home/liviu/.mplayer/
codecs.conf': No such file or directory
Reading /etc/mplayer/codecs.conf: Can't open '/etc/mplayer/codecs.conf': No 
such 
file or directory
Using built-in default codecs.conf.

"Use default playlist" is unchecked, and the playlist contains no cdda items.

Original comment by landroni...@gmail.com on 5 May 2010 at 4:56

GoogleCodeExporter commented 8 years ago 
if you create a new account on your machine and don't customize the desktop can 
you
still cause this to occur? I'm wondering if you have a shortcut somewhere that 
is
sending a dbus message to gnome-mplayer to open the cd?

Original comment by kdeko...@gmail.com on 6 May 2010 at 10:25

GoogleCodeExporter commented 8 years ago 
I have trouble replicating this consistently even in my user account. As a 
rule, the 
behaviour always happened when I selected "Open with Gnome-mplayer" from 
Thunar. I 
don't know if any dbus message is being sent when doing so. Now I'm always 
opening 
video files in debug mode, so I hope it's a matter of time to get a pertinent 
log.

Original comment by landroni...@gmail.com on 7 May 2010 at 7:51

GoogleCodeExporter commented 8 years ago 
A small update. Since I began starting gnome-mplayer in debug I never 
encountered 
the offending behaviour. But using the same method as before (double-click in 
Thunar), today I got the beahviour 4 times during five minutes. I'm not sure 
what's 
happening, but I have this theory: 
- in the debug session, the file is played using a `gnome-mplayer -v /path/to 
file 
with spaces' (1st screenshot)
- in the normal file open, Thunar calls `gnome-mplayer 
file:///path/to%20file%20with
%20spaces' (2nd screenshot)

I don't know whether it's the "file://" or "%20" causing the issues, but it 
might be 
a lead.

Original comment by landroni...@gmail.com on 11 May 2010 at 8:09

Attachments:

GoogleCodeExporter commented 8 years ago 
Is gnome-mplayer compiled with gio support? It will tell you when you start it 
with
the -v option. If not, recompile with that support enabled.

Original comment by kdeko...@gmail.com on 11 May 2010 at 12:53

GoogleCodeExporter commented 8 years ago 
It seems that GIO is enabled. 
liviu@debian-liv:~/Videos$ gnome-mplayer -v file:///tmp/copy%20of%20Flashf39k0f 
GNOME MPlayer v0.9.9.2
vo = xv ao = alsa
Running with GIO support
[..]

I finally managed to get a debug, by opening the file as shown above. The 
player 
started playing all cdda:// tracks and towards track 21 (according to 
libnotify) I 
managed to xkill it. CPU was full-throttle. For comparison, I attach a normal 
session (where the video is opened and played as expected) on the same video, 
same 
command, a couple of moments later. 

Is there anything wrong in there?

Original comment by landroni...@gmail.com on 11 May 2010 at 2:30

Attachments:

GoogleCodeExporter commented 8 years ago 
[deleted comment]
GoogleCodeExporter commented 8 years ago 
Minor update: the behaviour is not caused by the "%20" since I get the same 
behaviour on 
liviu@debian-liv:~/Videos$ gnome-mplayer -v file:///tmp/Flashf39k0f 

Sofar I can only think of "file://" causing it.

Original comment by landroni...@gmail.com on 11 May 2010 at 2:34

GoogleCodeExporter commented 8 years ago 
I think the playlist parser is opening the flash file and is thinking it is a 
audio
cd. I would need the flash file to debug this issue. Are you sure these are FLV 
files
and not SWF files. SWF files are not supported by gnome-mplayer.

Original comment by kdeko...@gmail.com on 13 May 2010 at 5:27

GoogleCodeExporter commented 8 years ago 
It happens with just about any MegaVideo file. For example, try this [1]. I 
would 
think they're flash since mplayer plays them and I get video and audio. 
[1] http://www.megavideo.com/?v=E2BFED4D

Item: /tmp/FlasheiLaGF
Type: Macromedia Flash Video
Mime: video/x-flv; charset=binary

Original comment by landroni...@gmail.com on 13 May 2010 at 7:36

GoogleCodeExporter commented 8 years ago 
Sorry, but I do not want to sign up for that site.

Original comment by kdeko...@gmail.com on 13 May 2010 at 7:58

GoogleCodeExporter commented 8 years ago 
Hmm, you wouldn't need to sign up for the site to access a stream. Would you 
prefer 
for me to send you/post a 5sec sample that produces the issue on my system?

Original comment by landroni...@gmail.com on 13 May 2010 at 8:25

GoogleCodeExporter commented 8 years ago 
Yes, a sample would be sufficient, make it 10-15 seconds so something can be 
seen in
mplayer. And attach it to this ticket if possible.

Original comment by kdeko...@gmail.com on 13 May 2010 at 8:39

GoogleCodeExporter commented 8 years ago 
OK, here's a ~15sec sample. After several tries (here, between 5 and 20) it 
should 
produce the offensive behaviour.

Original comment by landroni...@gmail.com on 13 May 2010 at 8:47

Attachments:

GoogleCodeExporter commented 8 years ago 
Ran about 100 tests of it with the SVN code... can't make it do it here. 
Perhaps you
should try SVN.

Original comment by kdeko...@gmail.com on 13 May 2010 at 8:57

GoogleCodeExporter commented 8 years ago 
Yesterday I tried SVN r1699, and I still get the offensive behaviour (less than 
20 
tries is usually sufficient). To be sure, I also confirmed this with a default 
~/.config/gnome-mplayer. Did you make sure to open it as shown below? 
liviu@debian-liv:~/Videos$ gnome-mplayer file:///tmp/Flashf39k0f 

Otherwise, perhaps you could add some temporary debug messages that would help 
isolate the issue?

Original comment by landroni...@gmail.com on 14 May 2010 at 1:44

GoogleCodeExporter commented 8 years ago 
Still can't duplicate it.. I used this as my command line (same command line I 
used
yesterday)

gnome-mplayer file:///home/kdekorte/Downloads/copy\ of\ Flash00TtgC

I also tried

gnome-mplayer file:///home/kdekorte/Downloads/copy%20of%20Flash00TtgC

Perhaps the --reallyverbose option will give a hint to the issue. Please run 
with
that option and upload the output when it fails. I'm guessing when you have 
problems
it will be around "opening playlist", but still unsure at this point.

Original comment by kdeko...@gmail.com on 14 May 2010 at 2:01

GoogleCodeExporter commented 8 years ago 
See attached.

Original comment by landroni...@gmail.com on 14 May 2010 at 3:13

Attachments:

GoogleCodeExporter commented 8 years ago 
Please apply the attached patch and reproduce the error (with --reallyverbose). 
This
will help locate the problem area.

patch -p0 < debug.patch 

in the gnome-mplayer directory

Original comment by kdeko...@gmail.com on 14 May 2010 at 3:24

Attachments:

GoogleCodeExporter commented 8 years ago 
Here's the second --reallyverbose dbg using the patch.

Original comment by landroni...@gmail.com on 14 May 2010 at 4:04

Attachments:

GoogleCodeExporter commented 8 years ago 
ok that is odd... none of my debug code was hit.

Can you add this line to line 160 in dbus-interface.c

printf("Adding %s via dbus\n", s);

should go right before: g_idle_add(add_to_playlist_and_play, g_strdup(s));

also add

    printf("parse cdda with %s\n",filename);

at line 600 in support.c

should go right before: if (g_ascii_strncasecmp(filename, "cdda://", 7) != 0) {

And retest..

Original comment by kdeko...@gmail.com on 14 May 2010 at 4:12

GoogleCodeExporter commented 8 years ago 
With the changse, it seems that the "parse cdda" message caught up, while "via 
dbus" 
didn't.

Original comment by landroni...@gmail.com on 14 May 2010 at 7:46

Attachments:

GoogleCodeExporter commented 8 years ago 
I'm wondering if it something with the desktop file. Perhaps you should put 
single
quotes around the value from Thunar. 

Exec=gnome-mplayer %U

Maybe it should be 

Exec=gnome-mplayer '%U'

Thunar should be passing files with spaces as %20 for the space. Since uri's 
should
not have spaces in them.

Original comment by kdeko...@gmail.com on 14 May 2010 at 7:52

GoogleCodeExporter commented 8 years ago 
Also, I just noticed in the log that the file is being reported by g_stat as a 
block
device. This is obviously wrong in this case. So that is what is triggering the
cdda:// loading code. That code is really early in the loading, and that is why 
it is
happening. So something is causing the filename to be picked up incorrectly.

I noticed something here that could be done a little better around here, so 
please
give SVN r1706 a try.

Original comment by kdeko...@gmail.com on 14 May 2010 at 8:30

GoogleCodeExporter commented 8 years ago 
I don't think this is particularly linked to Thunar, since I could replicate by 
opening the file from the command line. In any case, I'm currently debugging 
via 
Thunar's custom actions "gnome-mplayer -v --reallyverbose file://%f > 
/tmp/gnome-
mplayer.log"

I've just tried r1706 and so far so good. To be honest, today I'm probably 
tired of 
performing an extensive check. But I'll continue opening the files as 
previously and 
should the offensive behaviour pop back, I'll report here. Thanks for looking 
into 
this!

Original comment by landroni...@gmail.com on 14 May 2010 at 9:15

GoogleCodeExporter commented 8 years ago 
Hello
I think it's pretty safe to close this bug. After several days I haven't bumped 
into 
the same issue, so it looks like the fix worked.

Original comment by landroni...@gmail.com on 19 May 2010 at 9:54

GoogleCodeExporter commented 8 years ago 
Fixed

Original comment by kdeko...@gmail.com on 19 May 2010 at 9:56