Move to next song after delete

[madeinlisboa]

I noticed that when I try to delete a song while it is being played, the player doesn't advance to the next one and eventually crashes. This would be a good feature or bug correction if you intend it that way.

[gbl08ma]

Rockbox is made that way, when you delete a song while it's playing Rockbox should delete it and continue to play the buffered part of it. When the song ends, or when the end of buffer is reached, Rockbox shouldn't crash, but instead skip to the next song (or stop playback, depending on the situation and settings).

Are you sure it does crash when you delete a song and let it play? Or are you just saying that by heart?

[sideral]

Yes, crashes and misbehavior when deleting the currently playing song are a long-standing bug. Check out FS#10874 [1] and its duplicate and related bug reports.

I agree with madeinlisboa that playback should move to the next song when the current track is deleted.

[1] http://www.rockbox.org/tracker/task/10874

[madeinlisboa]

Thank you and sorry for the redundancy of my post

[Yotto]

I agree with madeinlisboa that playback should move to the next song when the current track is deleted.

Respectfully, I do not agree. I use this feature daily and it's actually one of my favorite things about Rockbox. And yes, my player sometimes crashes if I get overzealous and delete a track that's not fully buffered.

[Llorean]

Maybe an improvement would be that if a file is deleted while any part of it is in-buffer, the delete is instead 'queued' until playback is stopped or has moved to the next track?

I imagine the common use for the feature is for people to listen to a track like a podcast and trigger its deletion when near the end so as not to have to come back and 'clean up' later. So you'd want to, typically, ensure the track finishes playing. And of course, crashes are bad.

For those who'd rather have it automatically skip to the next song, it's really only one more button press anyway.

[Yotto]

Maybe an improvement would be that if a file is deleted while any part of it is in-buffer, the delete is instead 'queued' until playback is stopped or has moved to the next track?

I was thinking that deleting anything would trigger a buffer-fill first. It wouldn't *guarantee* that the player wouldn't crash in all circumstances, but it would guarantee it wouldn't crash for me Or, have a "fill the buffer" option in the quick menu, or somewhere easy to access. Or at least have a WPS true/false tag for if the current song is fully buffered so you could see on the screen if it's safe to delete.

I imagine the common use for the feature is for people to listen to a track like a podcast and trigger its deletion when near the end so as not to have to come back and 'clean up' later. So you'd want to, typically, ensure the track finishes playing. And of course, crashes are bad.

This is exactly how I use it, and while crashes are bad they're not that bad, and they don't happen that often when you delete the track in the last 30 seconds or so.
[/quote]

[JdGordon]

this is something which keeps coming up. I suspect it would be possible to change the "delete" option in the WPS context menu to cause a rebuffer before deleting but that is not what alot of people want.
It also doesnt fix the reason why it crashes isntead of failing gracefully when a unbuffered track dissapears (this should cause the same crash if you remove the microSD card mid track).

[Llorean]

Yeah, priority one among this stuff should just be solving that crash. Any logic changes are open to debate but the crash is a problem no matter what.

[sideral]

Llorean's suggestion makes sense to me: I can see how delete-after-playback could be useful.