instead of cdda://srX/Track XX.wav always opens sr0 track 1

[GoogleCodeExporter]

Hi. I have 1 physical audio cd in sr0 and cdemu mounted image in sr1. The
both are playable in mplayer. I click on the track icon in Nautilus. 
Nautilus does:
# gnome-mplayer "/home/il/.gvfs/подключение cdda на sr1/Track 
49.wav"
With --reallyverbose flag it seems that it correctly converts gvfs path to
cdda URL:
...
cdda://sr1/Track%2049.wav is a device name
...
But then it starts playing sr0 track 1

gnome-mplayer ver: 0.9.8
distro: Archlinux x86

Original issue reported on code.google.com by basini...@gmail.com on 4 Oct 2009 at 12:10

Attachments:

• cdda2.txt

[GoogleCodeExporter]

mplayer seems to want device names a little different than that

mplayer [cdda|cddb]://track[-endtrack][:speed][/device] [options]

Perhaps gvfs is getting in our way here. Can you post the full log and perhaps 
I can
put in a work around.

Original comment by kdeko...@gmail.com on 13 Oct 2009 at 7:05

[GoogleCodeExporter]

The full log was attached in my first post. Or it's not what you need?

Original comment by basini...@gmail.com on 13 Oct 2009 at 7:47

[GoogleCodeExporter]

Sorry, I missed it... I'll see if I can fix it.

Original comment by kdeko...@gmail.com on 13 Oct 2009 at 9:30

[GoogleCodeExporter]

This bug may be related to a similar bug in exaile 

https://bugs.launchpad.net/exaile/+bug/460535

Original comment by james.ki...@gmail.com on 28 Oct 2009 at 6:12

[GoogleCodeExporter]

I think this is a gvfs bug, I think that gvfs should give us the URL in this 
form

cdda://49//dev/sr1

Since tracks no not have names or .wav extensions on them.

Original comment by kdeko...@gmail.com on 16 Dec 2009 at 5:47

• Changed state: Done

[GoogleCodeExporter]

Do you use some gvfs API to convert path? If not, then it's not gvfs fault.
Nautilus passes to gnome-mplayer the path to the existing .wav file. It's the
player's desission to open the disc instead of opening the wav file you were 
given.

Original comment by basini...@gmail.com on 22 Dec 2009 at 8:05

[GoogleCodeExporter]

Yes, I do use the gvfs api... all files being loaded are processed this way..

                if (!device_name(argv[i])) {
                    file = g_file_new_for_commandline_arg(argv[i]);
                    if (file != NULL) {
                        uri = g_file_get_uri(file);
                        g_object_unref(file);
                    } else {
                        uri = g_strdup(argv[i]);
                    }
                } else {
                    uri = g_strdup(argv[i]);
                }

The filename being passed is not a device_name and so g_file_get_uri returns the
cdda:// form of the name that is unusual.

Original comment by kdeko...@gmail.com on 22 Dec 2009 at 10:11

[GoogleCodeExporter]

OK, actually, I've found that if I parse "filename" inside 
gint parse_cdda(gchar * filename)

and alter some lines of code like this:
        av[ac++] = g_strdup_printf("cddb://%s", parsed_uri->device);
        av[ac++] = g_strdup_printf("cdda://%s", parsed_uri->device);
...
        track = g_strdup_printf("cdda://%i%s", num, parsed_uri->device);
, the playlist is filled with some tracks and the playback starts.

But there's another problem: it always starts to play the 1st track. Even with 
no
device and mplayer-style uri like this: "gnome-mplayer cdda://4" 
I can't find the place in the code where the playlist item is set.

Original comment by basini...@gmail.com on 25 Dec 2009 at 11:00

[GoogleCodeExporter]

You should be able to pass cdda://11 to gnome-mplayer now and only that track 
should
be played as of SVN r1612

Original comment by kdeko...@gmail.com on 3 Jan 2010 at 6:13