Is this a known bug? (-37:54)

More details please?

First, do you know how to use the TIME feature on the remote control? (Press the 1 key.)

Second, is this happening on VBR files with incorrect VBR header data?

Okay, your update with the image clears up the first question. How about the second?

Sorry Tony. I messed up on attaching the file the first time around.

I'll look into that. I'm useing LAME w. --alt -preset standard. Over 90% of the "Artists" playlist has such files but some of the others do not.

If you've got more than about 24 days worth of music in your "Artists" playlist, then this could happen, I guess -- I could have sworn we did our sums in 64-bit, though, so you'd need about 292 million years of music (I think -- Doug?). What figures do you get when you go into the "Artists" playlist? Does it all add up? Anything suspiciously large (or negative) in there?

You could be being bitten by an old bug, which I thought there was code to fix in emplode -- essentially, the "duration" tag is figured cumulatively, but was occasionally getting stored on the player, resulting in a doubling of the duration every time you looked at the properties of a playlist. This one was fixed ages ago, though -- including code in the sanity checking to remove the "duration" tag from playlists.

If you find any tracks with suspiciously large durations, try "Reset Metadata" on them, and see if it fixes it.

In Emplode I get negative numbers, on some songs, in the tracks field that are fixed rate encoced. These also show up in the properties field of a particular song.
I don't have any negatives in the duration fields like you have.

Weird. Have you tried resetting the metadata on any of those tracks and letting emplode rebuild it?

Greetings!

I have the same problem, but attributed it to the encoder I used (it omitted the Xing header entirely). I have been meaning to run VBRfix on the files to regenerate the header eventually, but that is a long way off unless I can find a way to bulk repair them on the player itself. Note: clearing the metadata does not help in these instances. The rebuild just takes the missing VBR data and recalculates it incorrectly again.

OK I tried the 'reset metadata' and get the following message below. When Emplode is done syncing I get 'initialize errors about the particular file.
I then syncronize everything seems fine no errors but file remains the same.

OK. The way it's supposed to work is that the "Reset Metadata" only zaps the data from the *1 file. You then have to hit sync to save the (empty) fields. In the second stage of the sync, it notices the missing data and gives you that message. If you hit "Yes", it'll fix up the data as best as it can. Then you need to sync again.

If it's not working, you probably have some bogus files.