Rockbox

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

Quick links: Bugs · Patches · Rockbox frontpage

Tasklist

FS#9796 - Resuming playback from a plugin produces weird behaviour

Attached to Project: Rockbox
Opened by PaulJam (PaulJam) - Tuesday, 13 January 2009, 19:15 GMT+2
Last edited by Jonathan Gordon (jdgordon) - Wednesday, 25 February 2009, 06:41 GMT+2
Task Type Bugs
Category Music playback
Status Closed
Assigned To No-one
Player Type All players
Severity Low
Priority Normal
Reported Version Daily build (which?)
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Private No

Details

When playback of a folder is stopped and you try to resume playback via the "Audio Playback" menu of a plugin (for example solitaire) some strange behavior occurs:
- When "Auto-Change Directory" is set to "No", then a "loading" splash appears for a short moment and playback remains stopped.
- When "Auto-Change Directory" is set to "Yes", then playback resumes, but the last song of the previous directory gets played.
- When "Auto-Change Directory" is set to "Random", then playback resumes, but the last song of a random directory gets played.

H300 with r19757.
This task depends upon

Closed by  Jonathan Gordon (jdgordon)
Wednesday, 25 February 2009, 06:41 GMT+2
Reason for closing:  Fixed
Additional comments about closing:  nice work finding the bug, fixed in r20101.
Comment by Joshua Simmons (mud) - Wednesday, 25 February 2009, 03:50 GMT+2
Here's a fix. rb->playlist_resume depends on the dirfilter being set to something other than SHOW_PLUGINS, or it skips all of the files in the directory it tries to resume.

patched against r20100

I cannot reproduce any of the described failure cases after this patch and I note no regressions after specific testing and several hours of general use.

As a note to anyone trying to reproduce the original bug, here are instructions that worked for me (nothing else did):
0) I recommend turning Auto-Change Directory to "No', since that is the most obvious failure case (and is the one I generally tested with).
1) Make sure music is stopped (not paused).
2) Go in the File Browser and find a music file.
3) Press "select" to play the music file (in other words, don't use the Context Menu).
4) Stop music playback.
5) Enter the plugin and try to resume the playlist. Note that the failure(s) described above occur.
   fix-9796.patch (3.1 KiB) 
 b/apps/plugin.c                       |    1 +
 b/apps/plugin.h                       |    3 ++-
 b/apps/plugins/lib/playback_control.c |   13 +++++++++++++
 b/apps/tree.c                         |    7 +++++++
 b/apps/tree.h                         |    1 +
 5 files changed, 24 insertions(+), 1 deletion(-)

Comment by Jonas Häggqvist (rasher) - Wednesday, 25 February 2009, 04:20 GMT+2
Please don't take this the wrong way, but this seems a bit like a workaround to me, rather than a proper fix. Why does playlist_resume care about the dirfilter at all?
Comment by Joshua Simmons (mud) - Wednesday, 25 February 2009, 04:33 GMT+2
No offense taken.

playlist_resume cares about the dirfilter setting because down the line it calls ft_load (in apps/filetree.c) which I assume is also used to show directories when browsing and other similar things.

The way I figured it the possible solutions are these:
1) My above patch. Kind of work-aroundish, but seems to work.
2) Separate ft_load's different calling reasons in some way, probably by another argument (bool ignore_invisibles or something like that).
3) Set dirfilter somewhere else in the calling chain to ft_load. Probably not much different than the above patch, but could avoid adding get_dirfilter to the plugin api.

Of course there's always choice 4: something I overlooked.
Comment by Jonathan Gordon (jdgordon) - Wednesday, 25 February 2009, 05:29 GMT+2
I havnt checked the code yet, but I tend to agree with Jonas here, the proper fix is to make sure playlist_resume() makes sure the dirfilter is sane before trying to restart... il maybe check this out tonight

Loading...