Rockbox

Does this still happen? Does it happen every time you try to play the same file? If so, posting a file that makes it happen consistently would be most helpful.

Yes this still happens with every *.wv file.
I update regularly rockbox

Could you test this file on your unit: http://www.pvv.org/~thomj/wv.wv? I have had an X5 owner test it, and it works fine. If this file does not work on your unit, you probably have a faulty Rockbox install. If it works fine, could you submit another Wavpack file (preferably a small one, of course) that crashes on your unit so we can investigate it?

I have heard of no other X5 owners complaining about Wavpack files not working. If you do not reply with any new info soon, I'll assume this is due to user error and close the task.

The file that you gave me works perfectly. It's for me very difficult to upload a little file so you can understand my problem. Probably it's only a configuration problem
Thanks for your answers.

I seriously doubt it's a configuration problem. It would be most illuminating to have a copy of one of these files that do not work to figure out why we crash. If you can't upload one, please send one (as small as possible) to thomj@rockbox.org.

I posted you a file. I hope he isn't to big

This file also crashes for me. Will investigate.

This file has the length missing from the header of the first block. The standard WavPack decoder seeks out to the end of the file in this case to determine the exact length, but that is a little more difficult in this implementation because it must be handled outside the WavPack decoder (in the metadata handling functions).

As an interim fix I have checked in code (SVN 16893) that allows these files to be played by making a high-side guess at the length based on the file size and the mode. This works pretty well (the files even play gapless) but the progress bar is off and seeking is a little weird (but usable).

I would be interested in how exactly these file were generated because I can't imagine a situation where the command-line encoder would do this. The most common source is a 3rd party application that fails to seek back to the beginning of the file and rewrite the header once the actual length is known, or the case of a real time recording being interrupted.

Thanks for letting me know about this problem.

Would you say this warrants closing this bug?

If i remember well,but i amn't shure, this file like other was generated by splitting by cue splitter.
How do you determine this error? Please if do you have any time post me a breaf explanation.
Close this post and thanks for your kind and patient competence.