Data abort error during playback of files in a certain folder?

[richteratmosphere]

I have folder of music that has 320 files in it. I have adjusted the settings to allow up to 400 files per folder and up to 1000 files per playlist.

When playing songs from this folder, after I skip past around 15 or so files, I get this error message:

Data abort
at 30810704
FSR 0x8
(domain 0, fault 8)
address 0xEA000006

The only other thing that makes the files in this folder different than the others on my Clip+ is that the files are numbered with four digits (i.e. 0101, 1013, 1705, 2016, etc.).

Anyone know what the problem is here?

[CrowdAds]

[lestatar]

Check to see if it is the same file causing the crash - you may have a corrupt file and it is choking RB/Clip+.

If you can determine a suspect file, try playing it using the original firmware to see if a crash occurs too.

You can also use stuff like:
- foobar2k file integrity verifier plugin to see if any music files may be corrupt;
- http://www.gromkov.com/faq/repair/mp3_validator.html
- http://www.softpedia.com/get/Multime...ioTester.shtml

Start with these diagnostic steps is what I say, at least to try and narrow down your problem.

good luck,
-les

[richteratmosphere]

I installed the file integrity plugin to foobar. I verified that it was installed and enabled. Loaded all of the songs into the queue, played about a second of each song and skipped to the next one, and it didn't report any errors.

I also installed the Audio Tester. No files reported errors.

They're ogg files.

I did boot the Clip+ to original firmware, and it did crash after I skipped through about 16 songs. I didn't notice this problem before, but then again, I don't think that I skipped or listened to more than about two or three songs in a row from this particular folder until I noticed this problem yesterday.

Anyone else have any input?

Is it possible that it's the four digit numbering system that I used for these files?

[ABIdude45]

perhaps when the system loads the file names of the four digit numbered files it changes some values?

or it could be a problem with the file system

run CHKDSK (if running windows) and see if the file system is corrupt, if so it will automatically repair the errors otherwise if it is a file system error then back up your songs and reformat

If not then I have no Idea

[Confuseling]

You could also do a binary search, i.e.;

Remove the files to your computer. Divide the files in half. Copy over the first half, try playing. Delete, replace with the second half, and try playing. If one half works and the other doesn't, you've narrowed down your suspects. So cut whichever half didn't work in half, and try those, and so on... Shouldn't actually take *that* long.

ETA - I'd also add that if you do narrow it down to a file, it would be good to keep it. The devs may well want to take a peek (assuming it isn't private), because my understanding is that even a broken file shouldn't cause a data abort - it should just refuse to play.

[skip252]

Originally Posted by richteratmosphere

I installed the file integrity plugin to foobar. I verified that it was installed and enabled. Loaded all of the songs into the queue, played about a second of each song and skipped to the next one, and it didn't report any errors.

I also installed the Audio Tester. No files reported errors.

They're ogg files.

I did boot the Clip+ to original firmware, and it did crash after I skipped through about 16 songs. I didn't notice this problem before, but then again, I don't think that I skipped or listened to more than about two or three songs in a row from this particular folder until I noticed this problem yesterday.

Anyone else have any input?

Is it possible that it's the four digit numbering system that I used for these files?

As far as the data aborts the culprit for me in the past has been disk problems. You can check for those using chkdsk /f or Windows built in disk checker. Right click on the drive in Windows Explorer, Tools, Check Now...,Automatically fix file system errors. There's been a few times when I tried test builds I've had data aborts but when I've changed to a current build and checked the disk they stopped.

BTW Foobar2k's file integrity verfier doesn't work off small samples like that. It has to check the entire file. Just queue up all the files you want to check and right click, choose Utilities, Verify Integrity and let it work. It's very fast and will check hundreds of files in a few minutes.

[lestatar]

Good catch as usual skip252...Indeed, I missed how Richer did the tests. For sure, the foobar2k integrity verifier needs to completely scan the files. Same with all the other apps I linked.

And yes, it is very quick.

[ABIdude45]

Originally Posted by lestatar

Good catch as usual skip252

hey didn't I just basically say what he just said

[lestatar]

ABIDude: lol...yes...but I was referring to this specific part of skip252's post:

"BTW Foobar2k's file integrity verfier doesn't work off small samples like that. It has to check the entire file. Just queue up all the files you want to check and right click, choose Utilities, Verify Integrity and let it work. It's very fast and will check hundreds of files in a few minutes."

You were both providing great suggestions in terms of chkdisk/scandisk stuff which I failed to mention - FYI, skip252 is awesome around here

Thanks man and I didn't mean to slight you!

[ABIdude45]

its ok I just wanted to feel like I was contributing

BTW OP does this even solve your problem ?

[skip252]

Originally Posted by ABIdude45

its ok I just wanted to feel like I was contributing

BTW OP does this even solve your problem ?

We all contribute in various ways. I just added instructions on how to do the disk check. Not everyone knows how. I also added the part about how to use the integrity checker in fooby2k.

Plus we've learned to overlook lestatar's little oversights. You know how it is when you get up in age.

[Marvin the Martian]

Originally Posted by skip252

Plus we've learned to overlook lestatar's little oversights. You know how it is when you get up in age.

[lestatar]

Originally Posted by skip252

We all contribute in various ways. I just added instructions on how to do the disk check. Not everyone knows how. I also added the part about how to use the integrity checker in fooby2k.

Plus we've learned to overlook lestatar's little oversights. You know how it is when you get up in age.

roflmao.... i love you guys...truly Thanks for being so understanding

[richteratmosphere]

Okay, as far as I can tell, the sound files themselves were not corrupt. I had some jpg files embedded as album art in the ogg files. My first attempt was to remove all tags, including album art, then re-tag, and re-embed the art. I still got the error. When I removed all tags and removed embedded album art then re-tagged and didn't embed the art, all of the files play okay. Maybe it was something weird about those particular jpg files.

I was embedding album art in ogg files, because I thought that my Cowon S9 was displaying album art when playing albums using an m3u playlist because the art was embedded. I just learned through trial and error now that the S9 will now display album art if there is a cover.jpg file in the particular folder that you are playing the playlist from. That used to be the case if you were playing music using folder mode.

After I add music to my S9, I add the same stuff to my Clip+. Now that I know about the album art situation with the current S9 firmware, I won't be embedding art in the sound files anymore, since it's not really necessary or helpful.

Anyway, problem solved.

[saratoga]

If you take one of those Ogg files with the JPG art and then put it in a folder by itself, does it play normally?

[richteratmosphere]

Not sure. Once I was able to get the files to play, I deleted the ones with the embedded art, because I was so happy to have finally solved the problem.

[saratoga]

Oh thats too bad, I'd like to fix this bug.

[richteratmosphere]

These files also weren't playing on my Cowon S9. I was getting an "invalid file" error on my S9. So it didn't appear to be a bug limited to the Rockbox firmware.