After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 391654 - Argument is out of range.
Argument is out of range.
Status: RESOLVED FIXED
Product: banshee
Classification: Other
Component: Importing
0.12.1
Other All
: Normal normal
: 2.x
Assigned To: Banshee Maintainers
Banshee Maintainers
: 434828 435412 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2007-01-01 21:25 UTC by Technodude
Modified: 2008-02-07 14:58 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Technodude 2007-01-01 21:25:48 UTC
Please describe the problem:
When importing some of my mp3 files, I get the following message.

Argument is out of range.
Parameter name: index

This doesn't happen with all of the files, just some. The error gets listed under import errors. The files play fine in banshee using the open location command. I've tried deleting the database file.

Steps to reproduce:
1. File --> Import Music
2. Using Either Local Folder or Local Files
3. Error is shown in import errors.


Actual results:
Argument is out of range.
Parameter name: index

Expected results:
I would expect them to import into the music library without any errors.

Does this happen every time?
No. It only happens with some of my mp3 files. Not: I have been previously able to get these files imported into the library in version 11.2 but after I had a start-up problem, I deleted the db file and updated to the newer version. I got the message "index is less than 0 or more than or equal to the list count" when I tried the same thing in version 11.2

Other information:
Comment 1 Michał Sawicz 2007-01-28 23:24:31 UTC
Yes I have the same problem, I thought it was related to special chars in metadata, but I can't find any pattern. Nothing gets put on the console in --debug either.
Comment 2 Andrés G. Aragoneses (IRC: knocte) 2007-02-05 21:41:19 UTC
Same happenning here with two files of about a library of thousands. Perhaps we should post the files somewhere for the devs to examine? We should change the version of the bug since it's happenning for me in 0.11.5 (I have to try 0.11.6 though).
Comment 3 Michał Sawicz 2007-02-05 23:47:08 UTC
Yeah it's still here in 0.11.6...
Comment 4 John McGee 2007-03-15 20:49:17 UTC
I am also having this bug with version 0.12 under ubuntu feisty.  I would be more then willing to submit a sample of a few mp3's for testing purposes.
Comment 5 Ruben Vermeersch 2007-03-25 13:32:25 UTC
I used to experience this, but I am unable to reproduce this nowadays. Can somebody test this with SVN trunk and verify it it is indeed fixed. If not, let me know, I'd like one of those problem causing songs then. Let's nail this bugger.
Comment 6 Michał Sawicz 2007-03-25 14:16:47 UTC
Yes I was actually unable to reproduce on my 0.12 install on my second machine either... I'll try and get it working here on my primary machine and confirm if it's fixed.
Comment 7 Thomas McKay 2007-03-28 04:32:23 UTC
i am using 0.12.0 svn, and I am still experiencing this problem.

however, all of the files affected are from the same album, so perhaps it is being caused by some shady mp3 encoding. there should be some sort of tolerance to this, as the file is still playable with gstreamer.
Comment 8 Ruben Vermeersch 2007-03-28 07:42:13 UTC
Can you email me such a file (no copyrighted works in the bugzilla), with the original filename?
Comment 9 Andrés G. Aragoneses (IRC: knocte) 2007-04-18 01:02:07 UTC
Same here with 0.12.1. It seems that this bug even got more present in this version (I see more problems at importing with this symptom).

I have just sent an e-mail to Ruben V. with a sample mp3 file, so it would be nice to remove the NEEDINFO status (I don't know if this is done automatically after posting this commit, let's see...).
Comment 10 severedcross+bugzilla 2007-05-06 16:53:59 UTC
I had a similar issue with importing MP3's come up, and this is what I did to ascertain the nature of the error and fix it.

1. Modify Banshee.Base/Sources/ImportErrorSource.cs to give more information about the error on the commandline. The change that needs to be made is the addition of four lines to   public void AddError(string path, string message, Exception e):
	
Just add: Console.WriteLine(e.Message);
	  Console.WriteLine(e.Source);
	  Console.WriteLine(e.TargetSite);
	  Console.WriteLine(e.StackTrace);

After the existing call.  This will then spew out all kinds of information on the errors during the import process including the exact error message, the source, the target site and most importantly the stack trace.

2. From these traces, I ascertained that there was bad metadata in the files that were erroring out on import (the exceptions were traced back to TagLib) and used eyed3 to wholly strip the metadata from those files, then Kid3 to recreate metadata based on the filenames, which reflected the correct metadata.

3. After recreating metadata, import worked correctly without any errors.
Comment 11 Pedro Villavicencio 2007-05-07 01:47:55 UTC
*** Bug 434828 has been marked as a duplicate of this bug. ***
Comment 12 Ricardo Fuentes 2007-05-07 02:22:14 UTC
I comment on the duplicated report, and for try to see that produce the error, i reproduce the mp3 [http://jirah.org/up/gepe-celosia.mp3] with mpg123, and the app show this error: 

$ mpg123 gepe-celosia.mp3 
High Performance MPEG 1.0/2.0/2.5 Audio Player for Layers 1, 2 and 3
        version 0.61; written and copyright by Michael Hipp and others
        free software (LGPL/GPL) without any warranty but with best wishes
[../../../src/audio_oss.c:188] error: Can't open default sound device!
audio: No such file or directory

Playing MPEG stream 1 of 1: gepe-celosia.mp3 ...
[../../../src/id3.c:61] warning: Not ISO8859-1 or UTF8 encoding of text - I will probably screw a bit up!
[../../../src/id3.c:61] warning: Not ISO8859-1 or UTF8 encoding of text - I will probably screw a bit up!
[../../../src/id3.c:61] warning: Not ISO8859-1 or UTF8 encoding of text - I will probably screw a bit up!
[../../../src/id3.c:61] warning: Not ISO8859-1 or UTF8 encoding of text - I will probably screw a bit up!
[../../../src/id3.c:61] warning: Not ISO8859-1 or UTF8 encoding of text - I will probably screw a bit up!
Note: Xing/Lame/Info header detected

        Title:   ��C
e
l
o
s

a
        Artist:  ��G
e
p
e
        Album:   ��H
u
n
g
r

a
 
(
P
r
o
m
o
)
        Year:    ��2
0
0
7
        Genre:   Unknown
        Comment: Ripped by Winamp

MPEG 1.0 layer III, 192 kbits/s, 44100 Hz joint-stereo
[../../../src/audio.c:264] error: No supported rate found
Comment 13 Diego Escalante Urrelo (not reading bugmail) 2007-05-07 03:08:34 UTC
*** Bug 435412 has been marked as a duplicate of this bug. ***
Comment 14 Ricardo Fuentes 2007-05-07 05:30:18 UTC
I reencode the mp3 with lame, with defaults parameters, and banshee can reproduce the result. I think the problem is the encoding.
Comment 15 severedcross+bugzilla 2007-05-12 14:53:30 UTC
I think the MPG123 message makes it fairly clear it's metadata issues...
Comment 16 Thomas McKay 2007-05-12 16:26:13 UTC
okay, i have a recommendation to close this bug. banshee should have a more intuitive error message which explicitly says that the encoding of the file is bad. banshee could even offer to re-encode the tracks as a possible remedy.
Comment 17 Ricardo Fuentes 2007-05-13 18:13:26 UTC
i compile the svn version (0.13), and this problem is fixed, apparently. Thank you, so much!!
Comment 18 John McGee 2007-05-13 19:02:06 UTC
bug is still going on for me in the latest svn.

Thomas, that isn't a solution.  No other players seem to have this problem.  The reencoding thing isnt a half bad idea though.
Comment 19 severedcross+bugzilla 2007-05-31 22:24:53 UTC
I still don't think it's an encoding issue--the MPG123 message to me points to metadata problems. All the errors are in id3.c, and you can see the weird characters before the start of each of the tag frames. I don't understand where everyone's coming up with this encoding issue.
Comment 20 Lari Rissanen 2007-08-06 11:18:21 UTC
I have this same problem with one album I have. 

It is located in '/home/lari/Musiikki/蔡依琳/J-Top冠军精选/'. I thought maybe there is some problem with using chinese characters in folder names, but every other song that is in a folder with characters in the name works (song names themselves are written in characters too).

Amarok adds them to it's database no problem, as does Rhythmbox, but when I try to add them to Banshee database, I get the error 'Argument is out of range. Parameter name: index'.
Comment 21 lmm1987 2007-09-23 11:58:54 UTC
I made a test with a .mp3

Before editing the ID3 tag Banshee would give me the error reported here while trying to import the song.

After deleting the tag using EasyTag and writing it again the problem dissapeared, the song imports and plays fine.

So this is related to ID3 tags.

I use Banshee 0.12.1 in Ubuntu 7.04.

Any solution other than editing all the tags?
Comment 22 Chris Fung 2007-09-24 05:34:19 UTC
I was having the same problems with Banshee 0.12.1.  I tried the solution suggested here and rewrote the ID3 tags on the offending files using EasyTag.  After I rewrote the tags, I tried importing the tracks again, and Banshee accepted them.

I am using Banshee 0.12.1 on Ubuntu 7.04 Feisty.
Comment 23 severedcross+bugzilla 2007-09-26 19:49:59 UTC
(In reply to comment #21)
> I made a test with a .mp3
> 
> Before editing the ID3 tag Banshee would give me the error reported here while
> trying to import the song.
> 
> After deleting the tag using EasyTag and writing it again the problem
> dissapeared, the song imports and plays fine.
> 
> So this is related to ID3 tags.
> 
> I use Banshee 0.12.1 in Ubuntu 7.04.
> 
> Any solution other than editing all the tags?
> 

Fix TagLib? If you do all the stack tracing and look for the errors, you'll find that they generate back to taglib. I can't remember where, and I don't have any MP3 files with which I could reproduce this unfortunately, or else I'd look into it.
Comment 25 Wade Menard 2007-12-28 21:11:44 UTC
Importing of lcid-fire's sample MP3 is fixed in current upstream taglib-sharp.
Comment 26 Andrew Conkling 2008-02-07 03:35:55 UTC
Can everyone test in 0.13.2 (and TagLib# 2.0.3.0) to see if this behavior has been fixed?
Comment 27 severedcross+bugzilla 2008-02-07 05:06:26 UTC
Cannot reproduce with lcid-fire's sample.
Comment 28 Andrew Conkling 2008-02-07 14:58:11 UTC
Cool, thanks for testing.