Rockbox

  • Status Unconfirmed
  • Percent Complete
    0%
  • Task Type Bugs
  • Category Music playback
  • Assigned To No-one
  • Operating System Sansa e200
  • Severity Low
  • Priority Very Low
  • Reported Version Release 3.9
  • Due in Version Undecided
  • Due Date Undecided
  • Votes
  • Private
Attached to Project: Rockbox
Opened by Spirit_of_Music - 2011-11-05

FS#12367 - m4a files skip in mid playback. always same point, files are not corrupt.

m4a Songs skip in middle of playback, to next song.
always at same point. fast forwarding beyond this point is fine.
files work fine on other devices/PC.
reverted back to v3.6 and all such problems are gone

Please upload one of those songs.

Here is one of the files that skips. this skips at around 1min.

You’ll need to upload such file to a fileshare and place a link here.

link to the file which i sent before
http://www.filetolink.com/bcc09b83

I have no issues at all when playing this song in a nano2G simulator and on an iPod Video. Are you sure the files are not corrupt? Please try to delete and re-write them on your device.

MikeS commented on 2011-11-07 17:46

Nothing to note here either about the track.

However, I do have mysterious corruption from time to time on long-resident files on e200v1 and less-often on other devices. There is an issue there with data integrity. I can’t say if it’s a USB issue or just using write functions on the device with some bug in the FAT code.

Files work fine on my laptop. there is something with data integrity since if i copy the files and overwrite them the places where the skip happens differs, but this concides with something in the software since reverting to build 3.6 removes any such issues.
one guess i had is that the voltage to reading the usb has been lowered and therefore signal disruptions become an issue. but not knowing the architecture of the business that is only a guess.
in anycase this only happens on Sansa e280v2, rockbox 3.8 and up, with .m4a files.

Well, that this only happens with m4a might be caused by a less error resilient implementration of the decoder. Other codecs might just have a short dropout or inaudible other effects.

If I understood correctly this issue is caused when copying the files to your device – with v3.8 or later. So, this is a “corruption via USB-write” and not a playback issue.

It is not a corruption via USB-write since when i copy the files to the coomputer they are fine, and also since i reverted to v3.6 same file exactly (i.e. didn’t touch the music DB when i copied the 3.6 files onto the device) play fine.

Tomer.

MikeS commented on 2011-11-08 06:31

e200v2 only has 8mb ram. Perhaps there are dynamic memory requirements not being met because of the smaller memory? I’ll wait for Andree to sound-out on that since I did not research that deeply at all.

Hmm, then I understood “there is something with data integrity since if i copy the files and overwrite them the places where the skip happens differs, but this concides with something in the software since reverting to build 3.6 removes any such issues.” wrong.

Let us be precise:
- You have several files on your device.
- Using v3.6 → all play fine fine.
- Using v3.8 or later → several files show issues which we assume are caused by some kind of data corruption. for each affected file this is happening at the same position.
- In both cases copying them to a PC via USB results in files with no issues.
- Re-copying such file from PC to the device results in having the skip-issue at another time position (= integrity is broken at another byte position in the file)
- All of the above means the files are not corrupted in the flash. The corruption is either happening during reading from flash to RAM or in RAM itself.

What is the difference in the use case read buffer from flash (playback) against read to write to USB (copy to PC)? In both cases the flash driver is used and the CPU is boosted. What could cause a data corruption during the read access at the same position?

Michael, the e200v2 has the same codec size (1 MB) as most other devices. The m4a parser or any other dynamic memory requirements of the aac/m4a-codec should not have any impact. The provided files has size ~6350 KB of and a duration of ~3:30 min. As the skip is reported to happend at 1:00 min I do not think any rebuffering is happening at this time.

Hi guys, any idea how to proceed on this?

Loading...

Available keyboard shortcuts

Tasklist

Task Details

Task Editing