0.8b6 slow interface & takes 15 seconds to load installed file

[GoogleCodeExporter]

0.8b6 suddenly has a really slow interface- takes 2 to 4 clicks to move between 
and select menu items.

Also it takes 15 seconds before it will load the installed file.  

I have another wii with the same setup except with 0.8b4 where the interface is 
fast-as-you-can-click and it loads to the installed file in 4 seconds.

Original issue reported on code.google.com by edif...@gmail.com on 17 Jan 2013 at 11:45

[GoogleCodeExporter]

I just downgraded to 0.8b3 and have the same issues.  Could be a probelm with 
just this wii.  IOS80 SMv513.

Any ideas?

Original comment by edif...@gmail.com on 17 Jan 2013 at 11:50

[GoogleCodeExporter]

unplug the usb and see if it makes a difference

Original comment by dac...@gmail.com on 18 Jan 2013 at 5:39

[GoogleCodeExporter]

Same result with USB plugged and unplugged.  This one has me puzzled, 
especially since the software is mostly the same.

The one difference is the slow console is an RVL-101 (USA).

Both of them are loading the priiloader cfg loader forwarder (silent) as an 
installed file.

Original comment by edif...@gmail.com on 18 Jan 2013 at 7:00

[GoogleCodeExporter]

unplug sd as well, if its still slow then then i dont know what is going on :/

Original comment by dac...@gmail.com on 18 Jan 2013 at 10:27

[GoogleCodeExporter]

I've tried with no sd and no USB with the same result.

Curiously, when I soft reboot (click wii menu from in a game) it loads the 
forwarder immediately.  (it's set to "autoboot:loaded file" , "return 
to:autoboot")

Also the slow interface problem isn't happening anymore.

Original comment by edif...@gmail.com on 22 Jan 2013 at 3:15

[GoogleCodeExporter]

so its all good now? with sd & usb and everything? :s

Original comment by dac...@gmail.com on 22 Jan 2013 at 6:03

[GoogleCodeExporter]

It still takes 15 seconds of black before loading the forwarder on first boot.  
When the Wii restarts it works fine.

Very strange.

Original comment by edif...@gmail.com on 22 Jan 2013 at 6:12

[GoogleCodeExporter]

have you checked the gecko output on your usb device? (unplug your sd , enable 
gecko output and create the issue)

Original comment by dac...@gmail.com on 22 Jan 2013 at 3:02

[GoogleCodeExporter]

Nothing looks particularly out of the ordinary...

Here's the sequence I used to cover most cases:
Cold start from disconnected power (17 sec)
Power off via wii remote (console shows red light)
Power on via wii remote (took 17 sec)
reset via homebutton, wii menu (took 12 seconds)
Reset via front button (took 17 seconds to back screen)
Shutdown by holding front pannel button

--------gecko_output_enabled------
BootState:1
AutoBoot:Installed File
--------gecko_output_enabled------
BootState:3
"Magic Priiloader Word" 'Pune' found!
clearing memory of the "Magic Priiloader Word" and starting system menu...
using 00000098 for booting
LoadHacks : hacks_hash.ini not on FAT or Nand. ISFS_Open error -106
Hacks:0
--------gecko_output_enabled------
BootState:1
AutoBoot:Installed File
--------gecko_output_enabled------
BootState:3
"Magic Priiloader Word" 'Pune' found!
clearing memory of the "Magic Priiloader Word" and starting system menu...
using 00000098 for booting
LoadHacks : hacks_hash.ini not on FAT or Nand. ISFS_Open error -106
Hacks:0
--------gecko_output_enabled------
BootState:3
AutoBoot:Installed File
--------gecko_output_enabled------
BootState:3
"Magic Priiloader Word" 'Pune' found!
clearing memory of the "Magic Priiloader Word" and starting system menu...
using 00000098 for booting
LoadHacks : hacks_hash.ini not on FAT or Nand. ISFS_Open error -106
Hacks:0
--------gecko_output_enabled------
BootState:3
AutoBoot:Installed File
--------gecko_output_enabled------
BootState:3
"Magic Priiloader Word" 'Pune' found!
clearing memory of the "Magic Priiloader Word" and starting system menu...
using 00000098 for booting
LoadHacks : hacks_hash.ini not on FAT or Nand. ISFS_Open error -106
Hacks:0

This is what happens when the SD card is plugged in:
[With SD takes 17 seconds:]
--------gecko_output_enabled------
BootState:1
AutoBoot:Installed File

[With SD (soft reboot from ULGX takes 1 second)]
--------gecko_output_enabled------
BootState:3
AutoBoot:Installed File

Original comment by edif...@gmail.com on 22 Jan 2013 at 8:24

[GoogleCodeExporter]

why do i see so many magic words for SM? :s

in either case indeed nothing weird...

Original comment by dac...@gmail.com on 22 Jan 2013 at 8:27

[GoogleCodeExporter]

I had a hard time finding good documentation on magic words.  I had  assumed 
that they should only show up when an elf or dol purposefully writes them and 
then priiloader would read them and clear them.

When the SD card is out the forwarder (cfg's silent priiloader forwarder) fails 
so maybe it's writing Pune to load the system menu as a failsafe...?

Original comment by edif...@gmail.com on 22 Jan 2013 at 9:25

[GoogleCodeExporter]

that sounds possible and is probably what is going on. does it take a while 
with every dol you install or when you change the boot setting to like SM or 
something?
can you verify its priiloader taking so long and not the forwarder?

Original comment by dac...@gmail.com on 22 Jan 2013 at 9:36

[GoogleCodeExporter]

I can confirm that the delay occurs with any installed file.

It does not happen when Priiloader is set to load the system menu, HBC or 
BootMii IOS.

Moreover if I invoke the Priiloader UI by holding Reset and then select 
Installed File, the total time to actually start the Installed file is 12-17 
seconds from when I started the console (or perhaps from when priiloader 
starts).

So if I hold reset to load the Priiloader UI then wait about 12 seconds then 
choose "Installed File" it will load immediately.  I can even load Priiloader, 
wait 6 seconds and choose "Installed File" and it will go to a black screen for 
6 seconds and then load the file.

Perhaps there's a high CPU load during the first seconds?  Perhaps there's a 
misbehaving timeout?

Original comment by edif...@gmail.com on 22 Jan 2013 at 10:36

[GoogleCodeExporter]

while im investigating the source for possible stuff and changing a few lines, 
does the dvd drive work/spin? does it stop spinning after those few seconds?

Original comment by dac...@gmail.com on 23 Jan 2013 at 7:51

[GoogleCodeExporter]

The DVD drive on this console is toast so it's just got the DVD's control board 
left.  I could solder it back together but another day.  

Original comment by edif...@gmail.com on 23 Jan 2013 at 8:09

[GoogleCodeExporter]

aaaaaaaaaa
that makes perfect sense.
my dvd drive code is async
meaning it sends a command to the dvd drive to shut down, do some stuff while 
its waiting and then at a certain point waits for a response of ios. im 
guessing it indeed time's out with ios...

also, the dvd drive is solderless... how is it broken?

and how many seconds could you live with on boot? :P
i mean, i could add a local timeout (so it proceeds after x amount of 
seconds)...

Original comment by dac...@gmail.com on 23 Jan 2013 at 8:19

[GoogleCodeExporter]

The DVD's main board is still connected but all the motors, sensor and lens 
actuators are disconnected.

I should have thought to mention that, sorry!

If you added a local timeout it could be a little longer than the DVD typically 
takes to shutdown.  Probably 2 seconds.

In any case I'll reconnect some parts if I can find some spares to test with.  
This is an RVL-101 which uses a different DVD drive than the RVL-100.

Original comment by edif...@gmail.com on 23 Jan 2013 at 5:25

[GoogleCodeExporter]

The DVD's main board is still connected but all the motors, sensor and lens
actuators are disconnected.

I should have thought to mention that, sorry!

If you added a local timeout it could be a little longer than the DVD
typically takes to shutdown.  Probably 2 seconds.

In any case I'll reconnect some parts if I can find some spares to test
with.  This is an RVL-101 which uses a different DVD drive than the RVL-100.

Original comment by edif...@gmail.com on 23 Jan 2013 at 5:25

[GoogleCodeExporter]

keep me posted ;)

Original comment by dac...@gmail.com on 23 Jan 2013 at 5:50

[GoogleCodeExporter]

I don't have the right lens assembly, but I was able to get it down to 6 
seconds just by shorting what I presume to be the lens-parked (maybe disc in?  
It's hard to tell without the whole assembly) microswitch.

In any case, anything longer than 6 seconds for a local timeout would have no 
benefit.  I would say if you think there's any danger in not waiting for the 
IOS timeout then don't bother with a fix.  On the other hand if it doesn't 
really matter for Priiloader, a 1 or 2 second timeout might speed up loading in 
many certain cases.

Original comment by edif...@gmail.com on 23 Jan 2013 at 6:05

[GoogleCodeExporter]

well, so its the dvd drive that is causing the slow stuff. 

isn't official code affected by this? is official code (titles & SM and stuff 
like that) not slower too? (like when booting a title from SM )

if it isn't im going to see if i can't do anything about it if you dont mind 
running and maybe even installing a few tests ;)

Original comment by dac...@gmail.com on 23 Jan 2013 at 6:11

[GoogleCodeExporter]

In fact just Priiloader on at boot, but not reboot and only when it's using an 
Installed File.

System Menu and everything else, including channels and wbfs (via ULGX) run 
without delay.

I don't mind installing tests but since this is an RVL-101 (BootMii only as an 
IOS) Priiloader is pretty sacred for recovery.  If the tests are reasonably 
safe I'm game.

Original comment by edif...@gmail.com on 23 Jan 2013 at 6:22

[GoogleCodeExporter]

ill keep that in mind while compiling test dol's. you can leave the DVD drive 
disconnected like before :)

also, the reason only installed file could be infected is cause it waits for 
the DVD drive in those functions.

ill see if i can compile something tonight :)

Original comment by dac...@gmail.com on 23 Jan 2013 at 6:32

[GoogleCodeExporter]

http://upload.dacotaco.com/test.dol
load that dol from priiloader(not hbc!). when the quit msg shows up press A and 
note the value it'll say (about ret)
then press B and do the same. tell me the value's when youre done :)

Original comment by dac...@gmail.com on 23 Jan 2013 at 7:07

[GoogleCodeExporter]

I tested with the Micoswitch open and closed and both times it resulted in:

loaded IOS : 58!

A pressed : probe DVD test 1
ret = 0

B pressed : probe DVD test 2
ret = 0 

Original comment by edif...@gmail.com on 23 Jan 2013 at 7:35

[GoogleCodeExporter]

grmz, so thats not a reliable way to probe it...

also, here is a question. once you have waited the few seconds you never have 
the issue again right?
that makes it hard. ill think of something ;)

Original comment by dac...@gmail.com on 23 Jan 2013 at 8:14

[GoogleCodeExporter]

Yes, after the first time it's not a problem.  

Really, I think the issue is just the DVD hardware.  With the microswitch 
closed the delay is short enough that you wouldn't think it was broken.  (5-6 
Seconds).

Since the issue seems to be limited in scope to Wii's without complete DVD 
hardware you can close the issue if nothing comes to mind. 

Original comment by edif...@gmail.com on 23 Jan 2013 at 8:31

[GoogleCodeExporter]

nope, i want this fixed XD
i was thinking of finding a way to know if the dvd drive is reacting or not so 
the long delay doesn't happen. one think i'd like to know as well is that if 
you disconnect the dvd completely does it happen as well? if it does ill open 
up my wii and do the testing before giving you a test dol. that way youre wii 
is the safest ;)

Original comment by dac...@gmail.com on 23 Jan 2013 at 8:42

[GoogleCodeExporter]

Haha.  I was under the impression that if I disconnected my DVD drive entirely 
my wii wouldn't even boot to priiloader.  But, science...

Original comment by edif...@gmail.com on 23 Jan 2013 at 8:45

[GoogleCodeExporter]

it does. the wii can boot without a dvd afaik. the question however remains if 
the long boot happens then. i hope it does cause then i can reproduce this XD

Original comment by dac...@gmail.com on 23 Jan 2013 at 8:59

[GoogleCodeExporter]

Oh yes, it boots.  Your test DOL still gives "ret = 0" for A or B.

The 12 second delay occurs when the DVD drive is disconnected (!)

Earlier I must have been thinking that ULGX wouldn't be able to load games 
without the DVD drive mainboard connected, which appears to be true.

Original comment by edif...@gmail.com on 23 Jan 2013 at 9:14

[GoogleCodeExporter]

ha! so i can do some testing myself by disconnecting my dvd drive completely ! 
ill be doing that tomorrow night then

...if i dont forget XDDDD

Original comment by dac...@gmail.com on 23 Jan 2013 at 9:19

[GoogleCodeExporter]

issue reproduced :P my dvd drive is disconnected. it'll be though to run tests 
tho :)

Original comment by dac...@gmail.com on 24 Jan 2013 at 6:33

[GoogleCodeExporter]

i have something for you. install this dol if you would , enable gecko stuff 
(and unplug your SD please before you encounter a different bug) and let it 
autoboot to a doll. then post the gecko output here. the check code isn't 
enabled yet, but it should say a value which is important for me to know before 
i enabled the code for your wii :)

http://upload.dacotaco.com/boot_dvd.dol

thanks for sticking around with the issue

PS: i should be in bed... need to work tomorrow and i have a mother here who is 
very pissed at me right now XD

Original comment by dac...@gmail.com on 24 Jan 2013 at 9:54

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

well i need you to have the wii so that it has the long delay. i was gonna say 
"why is the dvd state 0 D:" but as i kept reading i know why XD

wut, is that a drive-less wii? never knew those existed!

Original comment by dac...@gmail.com on 25 Jan 2013 at 7:33

[GoogleCodeExporter]

I'm planning an aluminum case for a real Wii Mini... I wasn't impressed with 
the Canadian Wii-just-as-big which got the feature removal backwards.  It 
should have been driveless with an online store and a smaller process for a 
more efficient processor and a fanless case.

I would have thought that was too much to ask if it weren't for Priiloader, 
ULGX et al so I got out the disk grinder a soldering iron to prove it would 
work.

I'll do the test in the morning, wife is using it for netflix at the moment...

Original comment by edif...@gmail.com on 25 Jan 2013 at 8:16

[GoogleCodeExporter]

haha no problem. not sure why ulgx is beeing a dick, but priiloader is just a 
ios call taking ages because of no drive :) find a way to detect if the drive 
is there and its fixed. why would ulgx need a drive?

Original comment by dac...@gmail.com on 25 Jan 2013 at 8:29

[GoogleCodeExporter]

I presume that ULGX doesn't care but disc titles themselves seem to do 
something with the drive.  Probably nothing unpatchable but no one has figured 
out how yet....or at least I haven't.  That's and Red Button syncing in ULGX 
are on my wishlist.

And here we go:
--------gecko_output_enabled------
8:51:37 : BootState:0
8:51:37 : AutoBoot:Installed File
8:51:38 : DVD state : 1 
8:51:39 : checking DVD drive...
8:51:48 : Entrypoint: 80004000

[Again, this is where the forwarder reboots the console]
--------gecko_output_enabled------
8:51:54 : BootState:3
8:51:55 : "Magic Priiloader Word" 'Pune' found!
8:51:55 : clearing memory of the "Magic Priiloader Word" and starting system 
menu...
8:51:56 : using 00000098 for booting
8:51:57 : LoadHacks : hacks_hash.ini not on FAT or Nand. ISFS_Open error -106
8:51:58 : Hacks:0

Cheers, Ed

Original comment by edif...@gmail.com on 25 Jan 2013 at 4:58

[GoogleCodeExporter]

haha! YES!!

we got it. see that DVD state : 1 ?
the DVD drive's register says the "dvd drive lid is open"
i noticed that bit was only set when there was no disc in the drive or when the 
dvd drive was disconnected. hence why i added the gecko output of that. ill see 
if i can compile a version which checks the bit and will skip the dvd command 
when that bit is set to 1

Original comment by dac...@gmail.com on 25 Jan 2013 at 6:29

[GoogleCodeExporter]

here, try this ;)

http://upload.dacotaco.com/boot_dvd_2.dol

or im imagining things or it actually speeds up boot time of dols (or shutdown 
of wii) even when the drive is connected but not spinning XD

Original comment by dac...@gmail.com on 25 Jan 2013 at 7:28

[GoogleCodeExporter]

Well now my boot times are:
Microswitch closed: 6 sec to ULGX (Same as before).
Microswitch open (it's normally open): 4 sec to ULGX

Fantastic!

Now, if only we could find a way for ULGX to convince games to boot with no 
drive attached- that would be one more layer of circuit board off the WeeWii ;)

I'm assuming that it would be out of the realm of Priiloader's influence, no?

Original comment by edif...@gmail.com on 25 Jan 2013 at 10:56

[GoogleCodeExporter]

yes thats outside of priiloader's code so ye, outside of my power. however i 
still wonder what ULGX is doing (ULGX = usbloader gx right? )

Original comment by dac...@gmail.com on 25 Jan 2013 at 11:26

[GoogleCodeExporter]

Yes, I'm using the current SVN of USBLoaderGX on my WeeWii.

Cyan's not sure exactly sure either...
http://code.google.com/p/usbloader-gui/issues/detail?id=1769#c3218

If someone figures it out I can shave another 3 or 4 mm off ;)

Anyway, thanks for the attention to this rare issue and I'm glad you were able 
to make a small improvement to the code.  Good fun!

Original comment by edif...@gmail.com on 26 Jan 2013 at 2:12

[GoogleCodeExporter]

indeed. 

and i looked at the few lines talked about it @ the issue. all i could say is 
if they could figure out what the games are doing with the DVD drive then you 
could fake it i guess.

Original comment by dac...@gmail.com on 26 Jan 2013 at 8:46

• Changed state: Fixed