Data Abort at 0004ECCC (0)

[Sir_Brizz]

Hi all, I have an iPod Color (4G) and I loaded Rockbox on it a few years ago. Everything worked fine back then, then I loaded all my music on it and it was still working fine.

Today I decided I should update to the latest release, so I went and got Rockbox Utility and installed it, Rockbox came up just fine, but when it started initializing the database I got this error on a white screen:

Data abort
at 0004ECCC (0)

I've tried everything except formatting my device. I've uninstalled and reinstalled rockbox numerous times (including removing the rockbox folder off of my device).

If it matters, I'm running Rockbox Utility on Kubuntu 10.10. The program seems to be operating properly, though. This seems to be some problem with the database. The error comes up when it says something like "Setting Database (3/9)".

Any thoughts?

[bluebrother]

Theres a problem, possibly bug with the database. If you don't use the database just delete all database files (/.rockbox/database_*.tcd) and disable auto update of the database. If you use the database do the same, rebuild the database and check if the problem persists. And update to the latest build if you haven't already

[jaygeekay]

so i'm not the only one. i've always stayed fairly up to date with rockbox releases and have not had any sort of problem at all for at least a year - i say at least because i can't remember the last issue i had, so it could be far longer

but the latest 3.8 seems to have issues. the first is with the database. update did not work the first time i tried it. so i tried an initialise instead and that *seems* to have worked - though it was very quick, i think too quick, so i'm not confident everything is ok. and i wonder if that is the reason i have been getting that same Data Abort message? it is the same song that makes it happen each time. i don't know yet if it will happen with others, i haven't had 3.8 for that long.

in the meantime, i have had two other freezes as well - have no idea what was up with those - maybe they are based on the same issue.

i will go back to 3.7.1 when i get a chance and look back in a week or two to see if things have been fixed.

jim.

by the way, if there is any debugging i can do to help ye figure these issues out just let me know. i'm a software developer - debugging is part of my life - just make sure to give instructions

[erdnuesse]

same here.

Since I used both, database AND folder structure for playback (wanted the possibility to switch back to original fw in case of hangups or errors, since i used the actual builds, not only the "stable" ones) it was not that big of a downtime for me.

Well at least, I got rockbox running again today, thanks to bluebrother - with a little issue left.

What I tried:
A1. Reinstalling the stable build
no result

Here's what worked for me (partly):
B1. I deleted the database files like bluebrother mentioned
B2. I installed the actual build
result: Rockbox boots and playback via file/folder structure works as always
Database initializes, but stops at some point. Opening says that it's not ready.

Trying C right now...
C1. I deleted the database files like bluebrother mentioned
C2. I installed the stable build
result: ... wait, I'm doing this live : )
Database is being built - aaaaaaaaaaand again the 0004ECCC.

Back to B - let's see if the database will initialize completely.
[tbc.]

[Update:]

Well, Friends, Users and Contributors, I got it working again for me, without downgrading.

1. I deleted all the database files like bluebrother mentioned
2. I installed the actual build
3. I disabled the "Load to RAM" Option in Settings -> General -> Database
4. Finally I initialized the db new from scratch.

result: Rockbox boots and playback via file/folder structure works as always. The database initializes, commits and playback seemed possible. Even after a reboot (which is now incredibly fast! - guess because of the loading to Ram function) it does not crash anymore.

My issue is that I have double entries for any file, because it added songs twice to the database.

I'll head on and delete the database files, initialize from zero and see what happens.

[tbc.]

--
"because I can."

[Chronon]

There's an older bug with similar phenomenology, but a different address for the data abort:
http://www.rockbox.org/tracker/task/11642

It would be good to file a new bug report for this abort with as much information as possible (like the dependence on "Load to RAM").

[erdnuesse]

[Update:]

So, finally i killed the db again, means deleted the according files, and initialized once again. Seems like the db should only be initialized once and, after that, only should be updated. Oops, i guess that's the kind of stuff to be in a manual (which i did not read, because rockbox is so good, it's just self explanatory - shame on me...) After that I re-enabled the "load to ram" function, since I don't bother the slightly longer startup, but can't stand the seconds while browsing my database.

Right now, it's all working.
After all, the "load to ram" was a test to ensure that this is not the root of the problem. I guess, it would have worked without changing it. I could downgrade to stable to reproduce the error and give more detailled information, but deleting the db-files, run an upgrade, and re-initialize from zero should do it just fine.

But now, there's another thing, about which I am not sure that it results from the same problem:

I can now not play directly the files in my folder structure. But - if I go for the files I want to play in the database - I can play them. As far as I know by now I have the according files only copied into my folders directly, means not via syncing with any Itunes-like client (Itunes itself, mediamonkey, etc.) So I wondered first why these files should be in th db in the first place. On the one hand it's a strange behaviour, on the other hand, I can play them via the db. (But I admit that I do not know whether rockbox adds the files, which lie under any custom folder, automatically to its own database)

[tbc.]

--
"because I can."

[Chronon]

The database might be finding files that were added in MTP mode.  These won't be located in the normal /Music directory.

I don't use the database much but I tried to replicate this: I installed 3.8 on my e280 v1 and initialized the database with no problem (tried it both with and without "Load to RAM" enabled).  My database was not initialized prior to this.

[PickupBetty]

I got a similar Data abort, at 0004ECB8, on my Ipod Photo 4th Gen.  I deleted the database files but left Rockbox Stable as is.  I rebooted, then disabled "Load database to RAM."  Rockbox regenerated the database and seemed to play fine.

However, I couldn't play from the File menu.  So I reinstalled the current build, and got the Data abort at 0004ECCC (O).  Installed the current build, and all seems happy again.

I should note that I had edited the metadata on the two files I'd loaded before the Data abort, which may have funked the Ipod out.  I deleted them before installing the current build.  After installation, I re-loaded them and generated a database.  No problems!

I've loaded the same edited files on my Sansa e200, with no problems whatsoever.

[erdnuesse]

Well, in conclusion to everything we've tried, I'd say the "load to RAM" Option was only for narrowing th source of the error, but has nothing to do with it.

My solution: If you haven't got the current release but the 3.8 stable on an Ipod Photo 4. gen. you HAVE TO get the current release in order to fix the error, but first, you have to delete the database.

Having edited metadata in the files was no part of my scenario, so I would exclude that possibility.

However, I know now how to fix it for me, but if you (developers) want to trace the error/bug down, you could tell us what to do, maybe we can help. (maybe starting with the debug mode)
[Edit:]
I was wondering whether I should open a bug report for 3.8 stable, even whe the issue seems fixed in the current release.
Suggestions?

[AlexP]

If these issues are fixed in current, then we can do an 3.8.1 with just the fixes.  I'll try to have a look at the status this weekend.

[erdnuesse]

If these issues are fixed in current, then we can do an 3.8.1 with just the fixes.  I'll try to have a look at the status this weekend.

Thanks.
So the thing left to test will be if the issue occurs when updating from one of the builds before 3.8 to the current build, i guess.

[jaygeekay]

Current build fixes it for me anyways. Thanks

[erdnuesse]

Well, then I guess this thread can be renamed to [solved].
Thanks for participating and helping, guys.