• Status Closed
  • Percent Complete
  • Task Type Bugs
  • Category Music playback
  • Assigned To No-one
  • Operating System All players
  • Severity Low
  • Priority Very Low
  • Reported Version Release 3.4
  • Due in Version Undecided
  • Due Date Undecided
  • Votes
  • Private
Attached to Project: Rockbox
Opened by Jaykay - 2009-12-24
Last edited by speachy - 2024-04-21

FS#10874 - no track will play after playing a deleted, semi-buffered track

to reproduce:

1. start a big (20mb or more) track. delete it immidiately after starting it.
2. let the song play until it stops. i guess it stops at the end of the buffer. as an alternative you can ff to the end of the track (which shouldn’t be buffered)
3. now you’re not able to play any track. if you select a new one from the file browser or database, the wps will show up, but nothing is played and the progress bar won’t progress. ff and rw also don ‘t work. only rebooting helps. shutting down needs really long (~15s).

if you delete a fully buffered song, everything works as expected (well, the song continues till the end, and the next song starts. some devs call that “expected” :D ).

tested with r24091 and an e200, although i guess that the bug is target independent and occurs in the last few thousand revisions :)

Closed by  speachy
2024-04-21 13:40
Reason for closing:  Out of Date

Looks like I reported this as well.

Guess I should have searched first.

This seems to fix the problem, but it also seems to introduce a small audio glitch shortly after rebuffering.

Trying to reproduce this, I just hung my ClipV2 so hard that I couldn't even hard-reset it and had to let the battery drain.

kugel, your patch doesn't apply to current svn any longer, and it wasn't immediately obvious to me how to rebase it. I agree that buffering needs to be changed in the spirit of your patch as a safety measure (if that hasn't already happened), but perhaps this particular function (delete from WPS context menu) also should be handled from a higher level by explicitly stopping the current track and advancing the playlist. attempts to fix this issue. testing would be great.

If it can continue playing the deleted song it will, otherwise it will skip it as soon as it is deleted.

MikeS commented on 2012-04-23 16:47

The issue could be manifold. Buffering should simply truncate the file and close it. Some codecs may not properly check the return values of the buffer calls. I'd like a look before introducing and whole host of workarounds that may not address the real reason(s) but just gloss over it(them).

MikeS commented on 2012-04-23 16:58

Does the file/FAT code even properly deal with an open file being removed? I think I left a note or a commit message about something weird in cases of disk corruption where return values were not correct if the file on disk was already truncated.

If codecs don't deal with a buffering fail, then fixing them shouldn't be too hard. Just clean up and quit.

Fair enough, but this isnt the main motivation behind the gerrit patch, just the first example usage.

MikeS commented on 2012-05-03 03:59

Need to know which formats. There are many codecs that don't check return values from buffering and thus would try to pass NULL pointers to their library functions. Some codecs pass the test quite well. Some may have assumptions with seeking but pass in normal streaming to the end of buffered data. Playback only cares about the codec reporting that it has stopped decoding the file. The robustness depends upon the codec to check its stuff and take appropriate action (it IS the one reading the data afterall).

Buffering, as expected, stops and truncates the file at whatever read position it had at the moment of deletion (to my best estimation…the file should have filled the buffer had it been allowed to read it normally but stopped early because I got to deleting it quickl enough). Buffering will return failure if in fact a read is attempted in "no-man's land".


Available keyboard shortcuts


Task Details

Task Editing