- 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 Jonas Häggqvist - 2009-02-26
Last edited by Frank Gevaerts - 2009-05-21
Opened by Jonas Häggqvist - 2009-02-26
Last edited by Frank Gevaerts - 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
| 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.This patch unifies rockbox usb and hardware bridge init order. It seems to fix the issue on my e200.
ok, this doesn’t fix the issue after all...
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.
There’s more than this unfortunately. The recording screen and WPS still don’t work, and sometimes even freeze
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.
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.
Can usb connections be prevented or delayed during these tasks that use action_userabort()?