GNOME Bugzilla – Bug 391654
Argument is out of range.
Last modified: 2008-02-07 14:58:11 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:
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.
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).
Yeah it's still here in 0.11.6...
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.
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.
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.
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.
Can you email me such a file (no copyrighted works in the bugzilla), with the original filename?
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...).
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.
*** Bug 434828 has been marked as a duplicate of this bug. ***
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
*** Bug 435412 has been marked as a duplicate of this bug. ***
I reencode the mp3 with lame, with defaults parameters, and banshee can reproduce the result. I think the problem is the encoding.
I think the MPG123 message makes it fairly clear it's metadata issues...
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.
i compile the svn version (0.13), and this problem is fixed, apparently. Thank you, so much!!
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.
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.
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'.
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?
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.
(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.
Can be reproduced with http://frontalot.com/media.php/305/Baddd_Spellah_feat_MC_Frontalot_-_Rhyme_of_the_Nibelung.mp3
Importing of lcid-fire's sample MP3 is fixed in current upstream taglib-sharp.
Can everyone test in 0.13.2 (and TagLib# 2.0.3.0) to see if this behavior has been fixed?
Cannot reproduce with lcid-fire's sample.
Cool, thanks for testing.