• Status Closed
  • Percent Complete
  • Task Type Bugs
  • Category Music playback
  • Assigned To No-one
  • Operating System Gigabeat S
  • Severity High
  • Priority Very Low
  • Reported Version Daily build (which?)
  • Due in Version Undecided
  • Due Date Undecided
  • Votes
  • Private
Attached to Project: Rockbox
Opened by reszerve - 2011-01-08
Last edited by bluebrother - 2011-01-21

FS#11865 - WPS Locks up when pause button pressed.

From daily build r28953 on my gigabeat S WPS locks up if I press pause. After this no buttons work, hardware reset switch must be used to restart gigabeat. Prior to using pause it was noticed that the skip buttons are ignored, but other functions, main menu etc. appear to work OK.

Sequence to recreate:
After installing build, reboot.
Check menu is working OK etc. before resuming or starting playback.
Start/resume playback. Check skip buttons are ignored, other buttons work.
Press pause. Screen locks up (though scrolling text keeps scrolling). No buttons work from this point. Currently playing track continues to play.

Closed by  bluebrother
2011-01-21 19:50
Reason for closing:  Fixed

OK, now I’m confused. After the initial occurrence I’ve checked all the daily builds up to the current one r29005, always consistent. So I lodged the bug report.

Now, after initialising the database (why did it tell me needed to do this? The database was fine…) r29005 seems to be working fine???

Can anyone reproduce my issues? Has the database schema changed or something like that???

Yes, the DB schema was updated in r28942. But I have no idea why pausing the song would lock up the WPS when the DB is out of date. AFAIK, the DB is not accessed when pausing, only when starting, stopping, or skipping a track.

I’ve experienced a behaviour which has to be the same issue on h100:

- Start playback. Press stop. Music keeps playing, WPS doesn’t update anymore. Buttons still trigger backlight, but changing screens (to menu etc) doesn’t work anymore, as well as shutting down the player. Need to use the paperclip “debugging tool”.
- Start playback. Try to skip tracks. Track skip beep is audible, but no track skipping occurs. Change to a different screen (like Menu), change back to WPS. WPS shows the track you’ve skipped to but with broken information (bitrate shows up as ??? etc).
- Start playback. Go to the file browser, select a different file to play it back. Player keeps playing the old file, WPS locks up, changing screens not possible anymore.

After bisecting the issue (occurs with 3.7.1 and svn, but not with 3.7) I’ve identified r28608 / r28652 to be the cause. Reverting that commit makes it work as before.

Additional tests showed the following:

Since I was updating from an old Rockbox build the database was using the old format. Trying to access the database from the Main Menu shows a “database not ready” screen (which is not really correct / useful for end users since I have a database that worked in the past. Database auto update is disabled). Rebuilding the database and rebooting makes the crash not appear anymore. However, I’m able to reproduce the crash in case no database is present. Strangely I can’t reproduce the crash-without-database on Ipod Mini but on h100 when deleting all database files.

To sum it up, this looks like
- database format has changed, while the database current on disk is still in the old format
- lockup occurs when Rockbox tries to log runtime stats to the outdated / missing database
- from the commit I assume it waits forever for the database to come ready (which can’t happen, since it’s outdated and an update wasn’t triggered / the database is missing) and locks up the UI.

Since this make the player unusable and requires special tools to reset it on h100 (paperclip, and you might not always have one around when on the road) I consider this a serious issue. If the database can’t be used because it’s outdated it should get ignored or automatically updated.

Additonal note: the original issue r28608 / r28652 was addressing is  FS#11722 

The described issue only appears if “gather runtime data” is enabled.

This still happens on my iPod Nano 2G, using revision 29059. First I thought it was because my custom build had something wrong, but I donloaded the official build and the problems keeps happening.

This is, in detail, what I experience:
1. Turn on the player
2. Open the file browser and select any MP3 file to play
3. The file starts playing and WPS is fully working (I can adjust volume, go to custom menu, text is supposed to scroll is scrolling, etc.)
4. I pause the music using the hardware keys… the music pauses but… 5. The text keeps scrolling, however the volume text indicator won’t disappear (I’m using arboxWidgets and it should disappear) after a while, and I can’t resume music, skip track, or access any of the menus.
6. After a hard reset (the only way to exit out of the non-working WPS), I can do all these steps to get the same result.

NOTE: I haven’t tried re-initializing the DB. It’s something I’m going to do right now and post the results.

As expected… I initialized the DB (it was a bit hard to me because it seems in the meantime, there were DB changes, and I was waiting to see it ask me to reboot one or two times like happened before, but that didn’t happen this time), and this included (most likely unnecessarily) deleting all the DB files (I wasn’t expecting to not have to wait and reboot, like I said).
As expected… now it works perfectly and doesn’t hang when paused!

PS: Unlike Dominik/bluebrother said, I was still having the issue although I had “gather runtime data” disabled.

gbl08ma writes:

PS: Unlike Dominik/bluebrother said, I was still having the issue
> although I had “gather runtime data” disabled.

That’s interesting. Did you have autoresume enabled? This is the other feature that might lead to a hang when the DB does not become ready.

Here’s a patch in the spirit of the fix described by Slasheri on IRC. It aborts the wait for the DB to come online when the DB is not available.

I have reproduced the problem by bumping the DB version number in tagcache.h. Then I applied this patch, and this fixed the hang problem. I also verified that the first track could still be looked up in the DB: Autoresume resumed the first track at the correct offset, taken from the DB.

I don’t think I had the new autoresume feature enabled, if that’s what you were talking about. In fact, I don’t explore the new options in Rockbox for more than a month, as I haven’t used my iPod lately.
If it is the older resume features that resumed playback at startup and at the time position of the song that was effective at shutdown time, then I had it set to resume at the shutdown time position, but not to play automatically at startup.

Now that you speak about something waiting for another to become ready for the program to continue, everything makes sense on my mind: when I pressed pause, the thread that handled the button press was hang waiting for the DB answer, but other threads like the one that handles the scrolling keeps working. It seems the thoughts became too late though, Slasherri spoke before :)

gbl08ma, I doubt my patch will help with your problem then. The code I fixed should only run when either autoresume or gather runtime data has been enabled. Still, it would be good if you could try it and report your results anyway.

PS: Yes, I did mean the new autoresume feature.

My custom build SVN build is overloaded with patches and won’t work very well, however I can try applying your patch later and post the results. Now I can’t, I’m busy updating my iPod Nano theme ports on the theme site.

The attached patch works for me, at least as far as I’ve tested until now.

By the way, the commit message in the patch mentiones  FS#11856  but this task is FS 11865 :)

I can reproduce the pause issue on nano2g with the database not being initalized (removed the database files) and “gather runtime data” enabled. Applying the patch attached fixes the problem for me on nano2g. I’ve committed the patch as r29081.

gbl08ma, can you check against a current svn version? Since I cannot reproduce the issue anymore (but could without the patch applied) I suspect your issues to be related to the patches you’re using in your build.


Available keyboard shortcuts


Task Details

Task Editing