Limitations/specs for database_changelog file? (was: "Runtime not functioning")

[KindOfBlues71]

I have a 30GB 5G Video iPod and both Runtime stats and the database_changelog.txt file suddenly stopped updating last week.  I was using tdtooke's r16430 custom build when this happened.  I tested and verified that both issues were still present using official builds r17158 and r17205 with my current database_changelog.txt file.  Are there any limitations on the file itself, such as size or number of entries?  It's currently at 340KB with 775 entries.  The only way I could get runtime and the changelog to work again (both for official and custom builds) was to delete my changelog file and start from scratch.  Any ideas what I can check my changelog file for to try and figure this out?  I'd really like to have my runtime stats back!

Thanks,
-KindOfBlues71

Edit: I changed the title to be more specific

[zajacattack]

Seeing as you were using a custom build, it's better to ask on the topic for that actual build. It very well might have effected your database_changelog.txt file.

[KindOfBlues71]

Seeing as you were using a custom build, it's better to ask on the topic for that actual build. It very well might have effected your database_changelog.txt file.

That's definitely a possibility but my post is within the forum rules since I verified both issues are present in two different official builds from last week.

My questions are more specific to the database_changelog file so I changed the thread title.  Are there are any limitations for the file itself like max number of entries, max file size, formatting (default is Unix/Ansi), and whatever else anyone knows about the file so I can troubleshoot the issue?

Thanks,
-KindOfBlues71

[bascule]

I don't know whether there is a limit, but your statistics above seem quite modest.

...database_changelog.txt file suddenly stopped updating last week.

This confuses me a bit, as generating the changelog is a manual operation; you make it sound a part of auto-update.

If the database/runtime stats are not working, I would have thought the best bet would be to re-initialise the database, then re-import the changelog (which is what it was designed for). At least then you would be back to where you were.

I see no reason to delete the changelog, as it is a plain text file and should not get 'corrupted/confused' like the set of database files themselves sometimes appear to. It exists as the backup for the database.

[Llorean]

The problem is, the database changelog was created with a custom build which may in fact be the cause of its corruption. Testing it with an official build and saying "it doesn't work any more" may just mean "The unofficial build broke it, and it doesn't work with the official build now."

This is my point: You need to start from scratch when testing something with the official build. As you said, if you delete your changelog, the official build seems to work fine so far according to your description. Verifying that a file broken from an unofficial build doesn't work with official builds isn't verifying that the problem is present in the official build. You'd need to verify that the official build breaks the changelog itself.

It's very similar to saying "X build corrupted my MP3 file from a recording, and when I copied it over to the current build, it couldn't play the MP3 file either so it must also be a bug in the current build." It doesn't work that way, you'd need to re-produce the original conditions for creating that MP3 with the current build and see if it still comes up corrupted.