• Status New   Reopened
  • Percent Complete
  • Task Type Bugs
  • Category User Interface
  • Assigned To No-one
  • Operating System All players
  • Severity Low
  • Priority Very Low
  • Reported Version Version 3.1
  • Due in Version Undecided
  • Due Date Undecided
  • Votes
  • Private
Attached to Project: Rockbox
Opened by rasher - 2009-02-26
Last edited by fg - 2009-05-21

FS#9957 - USB connection not made when action_userabort() is used

Using a bootloader from  FS#9955 , a USB connection is not made if Start Screen is set to WPS, and the user boots Rockbox by inserting a USB cable.

This is possibly also true for other values of Start Screen.

Tested on e280, but I expect it’ll likely be the case on other PP targets with USB

The task blocks this from closing
ID Project Summary Priority Severity Assigned To Progress
10315 Rockbox FS#10315 - ipod doesn't show connecting to PC Very Low Low

A few more
booting, the sansa would either get to the WPS and freeze at 0:00 (before seeking), or show the USB screen, but not actually establish a connection. Unplugging the cable would make playback resume as expected.

I got these messages on the
hub 6-0:1.0: unable to enumerate USB device on port 1

I also have this problem on my e270 when the start screen is set to resume playback, with slighty different symptoms:

For me, a splash screen ‘Error accessing playlist control file’ appears very briefly before the USB screen is shown. Vista does not see the device and no errors are reported in the event log.

On removal of the USB cable,
The main menu appears with a ‘Scanning disk...’ splash, but the sansa is frozen requiring a hard
The screen becomes corrupted with shimmering diagonal lines on a solid-ish background, and again a hard reset is required

According to  FS#9955 , this is also true if the start screen is set to Database. I have not verified this personally though.

fg commented on 2009-05-21 14:28

This patch unifies rockbox usb and hardware bridge init order. It seems to fix the issue on my e200.

fg commented on 2009-05-21 19:10

ok, this doesn’t fix the issue after all...

fg commented on 2009-05-21 21:34

The problem seems to be in apps/action.c, in action_userabort(). This function throws away system events.

This actually makes usb connections not work in more circumstances than just booting with specific start screens. Any long-running task that uses action_userabort() is vulnerable, like e.g. inserting lots of tracks in a playlist.

Also, this isn’t specific to software usb.

fg commented on 2009-06-11 20:43

There’s more than this unfortunately. The recording screen and WPS still don’t work, and sometimes even freeze

fg commented on 2009-06-16 19:12

This is *not* caused by USB grabbing the audio buffer. A special build with a statically allocated buffer behaves exactly the same

It looks to me like root_menu.c switches to the start_in_screen before the USB detection has fully kicked in. This patch does not load the start_in_screen if USB_INSERTED. I’m not sure if it is the correct fix, but it does allow USB mode to work properly on bootup.

fg commented on 2009-10-27 14:49

That patch only makes the window for things to go wrong a bit shorter. It will still fail if you plug in at the wrong time.

It will still fail if you plug in at the wrong time.

Can usb connections be prevented or delayed during these tasks that use action_userabort()?


Available keyboard shortcuts


Task Details

Task Editing