• Status Closed
  • Percent Complete
  • Task Type Bugs
  • Category Music playback
  • Assigned To No-one
  • Operating System All players
  • Severity Low
  • Priority Very Low
  • Reported Version Daily build (which?)
  • Due in Version Undecided
  • Due Date Undecided
  • Votes
  • Private
Attached to Project: Rockbox
Opened by PaulJam - 2009-01-13
Last edited by jdgordon - 2009-02-25

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

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.

Closed by  jdgordon
2009-02-25 05:41
Reason for closing:  Fixed
Additional comments about closing:   Warning: Undefined array key "typography" in /home/rockbox/flyspray/plugins/dokuwiki/inc/parserutils.php on line 371 Warning: Undefined array key "camelcase" in /home/rockbox/flyspray/plugins/dokuwiki/inc/parserutils.php on line 407

nice work finding the bug, fixed in r20101.

mud commented on 2009-02-25 02:50

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.

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?

mud commented on 2009-02-25 03:33

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.

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


Available keyboard shortcuts


Task Details

Task Editing