Is this using 0.5.1? Do the files have tags? Do the filenames contain any
non-utf8 characters? 

Yes, it's muine 0.5.1 and the tags are set. I've tested the files on iTunes and
rhythmbox and they get recognized. And I've just noticed something: all of the
files that dont get imported or have any problem had the tags created by iTunes.
After I re-save the tag with winamp, it works ok. But rhythmbox seems to have no
problem with those files.

Hrm, do you think you could make a test file available to me?

Sure - here it is: http://www.geocities.com/kaleph_one/08_silver_inches.mp3

Will be fixed once the move to TagLib is complete.

*** Bug 133854 has been marked as a duplicate of this bug. ***

I think I have the same problem with another set of files, the whole album does
not appear in my album list.
How can I confirm this is the same bug?

I am not shure whether this is a bug of muine or my gnome installation:

Muine does not import any files nor folders that contain german umlauts. They do
not appear in the songs.db (according to "strings songs.db") nor in the
program's album list.

When I use "File -> Open Playlist" the folders do not even appear in the dialog.

Any help is appreciated.
Thomas

Muine also doesn't open files with incomplete tags -- mainly those without track
numbers. Is it possible to have it open files without track numbers and do a
search on the file name for ordering? Or just order by filename in that case?

I upgraded to Muine 0.6.2 and it still fails to import folders/ files containing
special characters.

Any ideas how to track down the problem?

*th

No need for tracking down - read up a few comments ;)

Adding more comments to the bug:

I can't import any files that have punctuated characters in the name, such as
"Cadê Teu Suín", "Além do Que se vê", etc. It's not a problem with the metadata
of the file, but rather a problem with the *file name*. If i rename the file
(leaving the metadata as it is), it works.

I can confirm report #12: Using mono 1.0.2, gtk# 1.0.2 and muine 0.6.3, muine
refuses to import filenames with the danish characters in (זרו ֶ״ֵ) using locale 
da_DK on a Mandrake 9.2 system. Metadata is fine, no problem there.

It is really annoying....

More info about #13 & #14 - seems that muine never gets a chance to look at the
files. I added Console.WriteLines to this code:

	private bool HandleDirectory (DirectoryInfo info,
				      ProgressWindow pw)
	{
		System.IO.FileInfo [] finfos;
		
		try {
			finfos = info.GetFiles ();
		} catch {
			return true;
		}
		
		foreach (System.IO.FileInfo finfo in finfos) {
			Song song;

			Console.WriteLine("Checking song:");
			Console.WriteLine(finfo.FullName);

And, it never outputs anything for the files with the "weird" characters in. So,
is this a mono problem? Do we need something special for mono to work?

I've got the same problem with an album. But it doesn't contain any weird
characters. The album consists of 2 cd's. Muine imports cd 2 just fine but it
just does not import cd1. I'm using muine 0.6.3.
I can make a file of cd 1 and one of cd 2 available online if someone's interested.

The problem with special characters could be related to LocalPathFromUri (string
uri) in FileUtils.cs.

I borrowed that code into my own project and it didn't return anything if the
URI contained special characters and international characters.

But a change to use gnome_vfs_format_uri_for_display instead of
gnome_vfs_get_local_path_from_uri solved all my problems:


[DllImport ("libgnomevfs-2.dll")]
private static extern IntPtr gnome_vfs_format_uri_for_display (string str);

public static string LocalPathFromURI (string uri)
{
	IntPtr p = gnome_vfs_format_uri_for_display (uri);

	if (p == IntPtr.Zero)
		return null;
	else
		return GLib.Marshaller.PtrToStringGFree (p);
}

Maybe this is applicable to Muine too?

That shouldn't be, as we only run this one on actual valid uris. (uris with
strange chars that are not escaped are not valid)

If I receive

DragDataReceivedArgs args

and take out the actual string with 

string uriCollection = System.Text.Encoding.UTF8.GetString(args.SelectionData.Data);

It looks like this

file:///home/aex/Desktop/mp3/mix/Th%E5str%F6m%20-%20Keops%20pyramid.mp3

And this must be a valid URI? Or?

gnome_vfs_get_local_path_from_uri handles the %20 ok, but not the others.
The swedish charater å (%E5 in the string) and ö (%F6) makes the function return
nothing. gnome_vfs_format_uri_for_display on the other hand returns a correct
string.

In this case it looks like it is a bug in gnome_vfs_get_local_path_from_uri ..
maybe you could cook up a C testcase we can report with the gnome-vfs guys?

Muine 0.6.3 would not load mp3's that have album art in the id3tag delete that
and they load fine.  That may be the problem some of you are having I was.

i have some strange issue maybe related to this, most of my songs loads allright
into the db, but only 10% - 15% of the albums actually shows up in the album
menu. it even fetches the album images correct as you can see it when you're
playing the song...

I completely forgot about this bug.

I am no C GTK-hacker, so I don't know if I have time cooking up such a test case.
But if I do I'll let you know.

I submitted a similar bug to the gtk# bugzilla today since GnomeVFS# only uses
the broken(?) gnome_vfs_get_local_path_from_uri, and don't implement
gnome_vfs_format_uri_for_display I have been using.

I cooked up a C-example and it works.

So I tried it in my .NET code and now it works somehow.
Even the GNOMEVFS# method works.

Don't know what changed, but the exact same code (I simply uncommented the old
one) didn't work earlier (and hasn't all times I poked at it the last 6 months).

I had a similar problem with a bunch of files that had an associated album image
except that id3info reported:

=== APIC (Attached picture): ()[, 0]: , 120054 bytes

To compare, another album had an embedded image but it was reported by id3info as:

=== APIC (Attached picture): ()[, 3]: image/jpeg, 16524 bytes

I removed the image tag from the first set of files and now they import fine.

I believe this is a duplicate of #162243

I'm marking this bug as a duplicate of #162243. Please reopen if this is not the case.

*** This bug has been marked as a duplicate of 162243 ***