- Status Unconfirmed
- Percent Complete
- Task Type Bugs
- Category User Interface
- Assigned To No-one
- Operating System Iriver H100 series
- Severity Medium
- Priority Very Low
- Reported Version Release 3.13
- Due in Version Undecided
-
Due Date
Undecided
- Votes
- Private
FS#13036 - Deleting a file and rewinding (without stopping replay) causes Rockbox to hang
Rockbox version 3.13
Wenn I delete a file being played, it continues to play (which is OK for me). But when I rewind in this file while playing, Rockbox hangs and does not respond to any key presses. The screen light stays on. I have to press the hard reset or wait until the battery is empty.
This also sometimes happens when I press fastforward, but it always happens when pressing rewind.
Desired behavior:
- Preferred: permit rewinding/fastforwarding (and really delete the file only after stopping the replay)
- ignore rewind/fast forward; alternatively
- skip to the next file immediately after deleting.
Thanks for reading, and please contact me if you cannot reproduce this! I have a Iriver H140 and I must say that all my recordings are in wavpack (recordings made using SPDIF-IN), so I do not know whether this also happens with other file formats and with other players.
-Stefan
Loading...
Available keyboard shortcuts
- Alt + ⇧ Shift + l Login Dialog / Logout
- Alt + ⇧ Shift + a Add new task
- Alt + ⇧ Shift + m My searches
- Alt + ⇧ Shift + t focus taskid search
Tasklist
- o open selected task
- j move cursor down
- k move cursor up
Task Details
- n Next task
- p Previous task
- Alt + ⇧ Shift + e ↵ Enter Edit this task
- Alt + ⇧ Shift + w watch task
- Alt + ⇧ Shift + y Close Task
Task Editing
- Alt + ⇧ Shift + s save task
Does this happen in newer versions? The file system code has been completely reworked since then.
As of now, the file code follows the POSIX specification and removes the actual file data only when all its descriptors have been closed but removes the directory entry immediately. The first listed desired behavior is what will likely occur unless the file had to be reopened, in which case it should just get "not found" and skip ahead.
ETA: For some reason, some codecs pay no mind the buffering return values that they really must heed which can also cause problems. Just my 2 cents on a possibility on why it may misbehave (though I haven't actually checked the codec(s) in question).