Swizzy

You were using Beta1 not Beta2

I'm This close to a fix -> <-About the updxell issue, probably related to Coronas... nobody mentioned that it doesn't work on those to me untill recently, i know sort of where the problem is, and it's going to be fixed in v0.994 along with the DVD issues...** edit: **I know exactly why it's not working now, and the reason is the same that causes hitachi's to freeze... i've fixed that part... after doing that however i found yet another problem, a couple of months after 0.991 was released the iso9660 support was swapped (the stuff that reads the contents of the disc) and it is not working much at all (crashing due to stack overflow, meaning it's trying to read more data then it can hold because it's to stupid to know when to stop reading) i will need to re-write the whole thing because the old code doesn't work anymore etheir as-is due to to many changes in the other parts of the libxenon code >_<

the "xmplayer.elf" in the folder _DEBUG is not meant to be run at all, it's used for finding the crash location when you have crash information (stackdump) using the command "xenon-addr2line" from the libxenon toolchain a.k.a. ignore it if you don't understand any of this shit

I decompiled your app, all it does is copy the selected file to the directory... it doesn't solve anything, doesn't change anything... all it does is add extra steps...

on RGH xelllaunch requires that you have xell-2f.bin or xell-1f.bin as stated in the readme... the built in one (in the nand) will most likely crash before it even starts loading itself...

Read my guide to updating your Xbox 360, it'll tell you how to do it with just a PC and a USB Memory... (and of course a 360 controller and TV/Monitor) it also includes the steps required to install the Kinect/Avatar stuff...

How are you moving the file?

It's really simple to copy 'n' paste the log tho... and it'll help us fix bugs in the software... maybe there is a bug in the tool, maybe it's just a connection problem with your computer? we don't know untill we see the log... It's ussually "client.log" (for client mode) "update.log" (for update mode) or "filename.log" for build mode... check next to the exe and you'll probably find one of these... ** edit: ** If you want to you can do the update the "old-school" way, not using networking at all... you can read about how to do it here: http://xebuildtut.xeupd.com/

It should find and mount any discs, i haven't tried it tho as i don't have any homebrew on a CD/DVD... but i'll burn a CD and test some

My bad! i've fixed it now tho: http://www.homebrew-connection.org/files/xbox/Emulators/libXenon/dl_mupen64-360_v0.993_beta2.rar it simply wasn't mounting the USB devices properly (i forgot to remove some stuff from the xell code i copied to the mount code of zlx coz i was lazy )

http://file.libxenon.org/free60/linux/distro/ubuntu-10.10-xenon-beta5.zip <--- try this one (might be the one you already have, idk) i used it from a USB drive before... the tool i used to put it on my USB drive was this: http://www.linuxliveusb.com/

http://www.homebrew-connection.org/mupen64-360-v0-993-beta/ <--- i got an ok from GliGli to release a new version compatible with corona, and here it is :)What needs to be tested in XeLL? well, we need to know what bugs are there, and what triggers them... so, basically just use whatever features you know how to, and try to tell us as much as you possible can about each error you get, if you get a segmentation fault (crash) it's VERY useful to have the stackdump information, best would probably be to take a picture, it'd also be good to know what you did when it happend, that'll help us know how to maybe reproduce it...I know of some errors that are completly random, like there's a crash in Xenos sometimes (seems to be quite rare tho) just when it's starting, i don't know why this happens yet, and like i said... it appears to be random and quite rare...Any current homebrew will sadly not work as i've mentioned earlier in the thread (i think? i know i've written it in many places...) anyways, if you want some homebrew updated and know where to find the source code for the last released version i'll fix it for you... or anyone else for that matter, however... don't expect me to just fix it instantly, it may take a few days... i do this on my spare time when i feel like doing some coding...

Normally everytime you build the image it'll be different due to randomness, however... if you supply a dump with the latest xebuild version it should be alot closer to the original...

Make sure your firewall isn't blocking xebuild, and make sure that it's actually running on the console (you need to have the installer open!)If you don't know if it's actually running, try using the standalone version...

If you have UART, could you get me a log of the output?

So you managed to solve it by flashing the NAND with a hardware flasher?

I would however recommend that you leave flash360 and use Simple 360 NAND Flasher instead

Probably if the right person does it It's most likely an installation error like bad soldering or so...

Do you have a Hitachi 0500 or 0502? if so this is a known bug which i have no idea how to fix right now (i don't have a hitachi slim)

Well, if your device is formatted in NTFS it'll be ignored by XeLL can you tell me a bit more about your USB memory/harddisk? (if you know how to get hold of the VID/PID it'd be great to have that, along with some information like what manufacturer and model it is, this will help possibly finding someone around me that can help me out with some really fast debugging with it)

i can recompile it for you a little later maybe... you'll need linux and maybe even edit some of the code... Try rebuilding your nand and updating XeLL that way using Simple 360 NAND Flasher instead

The reason you only get black screen when trying to boot mupen64 is because it doesn't support Corona unless you recompile it using the new (updated) libxenon toolchain No, it makes no difference because XeLL don't support NTFS at this time, i've been working on squeezing that in... but... it's not very easy (the NTFS lib is HUGE and it's not easy to find what can be disabled safely without breaking everything) this stack dump tells me that your USB drive falls down to the "lazy formatter" thingy, i've fixed this bug in XeLL, however... the bug is also present in most homebrew that uses usb devices...https://github.com/Free60Project/xell/commit/0a15d0abfaa365a4c0b024b58fd69732932bbdd6#L0R337 <--- the 2 lines here is the fix

They're all wrong, this crash is caused by something in the USB management, i'll look into it and see if i can find the cause of the error... Could you try another USB memory? do you have anything else connected to your console? does it happen without usb memories also?

Which version exactly? could you also take a better picture showing the entire stack dump plz?what motherboard do you have?

It doesn't make your console boot any better or so... it does however fix some bugs in XeLL, if you ever use that (highly unlikely as most ppl don't really use it much) there's little to no reason to update just because it's out...The new xeBuild GUI, J-Runner, AutoGG etc. will all use the new XeLL Reloaded from now on