Rockbox

This is the bug/patch tracker for Rockbox. Click here for more information.

Quick links: Bugs · Patches · Rockbox frontpage

Tasklist

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

Attached to Project: Rockbox
Opened by Johannes Linke (Jaykay) - Thursday, 24 December 2009, 12:57 GMT+2
Last edited by sideral (sideral) - Monday, 25 April 2011, 13:23 GMT+2
Task Type Bugs
Category Music playback
Status New
Assigned To No-one
Player Type All players
Severity Low
Priority Normal
Reported Version Release 3.4
Due in Version Undecided
Due Date Undecided
Percent Complete 0%
Private No

Details

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 :)


This task depends upon

Comment by jasontaylor (jasontaylor) - Friday, 01 January 2010, 02:56 GMT+2
Looks like I reported this as well.

http://www.rockbox.org/tracker/task/10885?project=1&type=2&order=dateopened&sort=desc

Guess I should have searched first.
Comment by Thomas Martitz (kugel.) - Wednesday, 27 January 2010, 00:10 GMT+2
This seems to fix the problem, but it also seems to introduce a small audio glitch shortly after rebuffering.
   fix-deletion-while-playing.diff (0.9 KiB) 
 b/apps/buffering.c |    7 ++++++-
 1 file changed, 6 insertions(+), 1 deletion(-)

Comment by sideral (sideral) - Monday, 25 April 2011, 13:23 GMT+2
  • Field changed: Status (Unconfirmed → New)
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.
Comment by Jonathan Gordon (jdgordon) - Monday, 23 April 2012, 15:19 GMT+2
http://gerrit.rockbox.org/r/#/c/224/ 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.
Comment by Michael Sevakis (MikeS) - Monday, 23 April 2012, 18:47 GMT+2
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).
Comment by Michael Sevakis (MikeS) - Monday, 23 April 2012, 18:58 GMT+2
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.
Comment by MichaelGiacomelli (saratoga) - Monday, 23 April 2012, 19:48 GMT+2
If codecs don't deal with a buffering fail, then fixing them shouldn't be too hard. Just clean up and quit.
Comment by Jonathan Gordon (jdgordon) - Tuesday, 24 April 2012, 00:49 GMT+2
Fair enough, but this isnt the main motivation behind the gerrit patch, just the first example usage.
Comment by Michael Sevakis (MikeS) - Thursday, 03 May 2012, 05:59 GMT+2
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".

Loading...