Rockbox Development > Feature Ideas

Move to next song after delete

<< < (2/2)

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:

--- Quote from: Llorean on June 17, 2011, 03:18:37 PM ---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?

--- End quote ---
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.

--- Quote ---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.

--- End quote ---
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.

Navigation

[0] Message Index

[*] Previous page