Rockbox

Tasklist

FS#5909 - Likely file system bug

Attached to Project: Rockbox
Opened by Michael Sevakis (MikeS) - Thursday, 31 August 2006, 02:59 GMT
Last edited by Steve Bavin (pondlife) - Monday, 02 October 2006, 07:34 GMT
Task Type Bugs
Category Operating System/Drivers
Status Closed
Assigned To No-one
Operating System All players
Severity High
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

I've talked about a problem before with recorded files (at least with codec system) not having the displayed progress stop a couple of seconds before the true end of the file even though the file actually plays to completion. Well it turns out it's not actually a problem with the recording system at all.

Here's what happened:
* Recorded an 18 second FM Radio segment.
* Test played that and of course progress indication stops at about 16s
* Plugged my x5 into my computer
* Made a copy of the recorded file
* Loaded it in CoolEditPro
* Saved over the copy with CEP (Save extra non-audio information UNCHECKED)
* Played the original...same thing as before
* Played the copy...the copy showed progress to the 18s mark as it should...perfect playback in all respects. Could be a change in the file?
* NO! A file compare shows the original recorded and resaved copy to be IDENTICAL! No difference in data or size!

Now, shouldn't two identical files play exactly the same way?
My hypothesis: This bug must be in the file system functions.

This should be tracked down and fixed by someone knowledgeable in that area with little delay.
This task depends upon

Closed by  Michael Sevakis (MikeS)
Saturday, 10 February 2007, 16:43 GMT
Reason for closing:  Invalid
Additional comments about closing:  Problem was really about switching codec types.
Comment by Michael Sevakis (MikeS) - Thursday, 31 August 2006, 05:57 GMT
Davide-NYC did some H140 testing and this progress bar/time behavior did not occur. x5 only maybe? Nothing appears wrong with the files that recording writes.

BTW: Just copying the file in the Explorer window to make Copy of XXXXX.xxx also makes the copy behave normally so it depends on which device writes the file despite their being identical. No resave by an application is needed.
Comment by Steve Bavin (pondlife) - Wednesday, 04 October 2006, 20:19 GMT
Does having dircache on or off make any difference to this behaviour?
Comment by Michael Sevakis (MikeS) - Thursday, 05 October 2006, 01:24 GMT
No. I tested awhile back and same thing with or without it. I suppose I'll have to look into the code that provides the WPS with its data (directly or indirectly) and see what it returns that's different from from the copy. Some files that "shorten" no longer shorten when follow by something else. Some it makes no difference what follows or even if its the same codec for the next one. But just simply copying the file in Explorer and having the copy show up right in WPS is just wierd.

Loading...