[00:00:11] *** Quits: zxcasd_ (4857622b@gateway/web/freenode/ip.72.87.98.43) (Ping timeout: 250 seconds) [00:01:59] *** Joins: zxcasd (tom.zxcasd@pool-72-87-98-43.prvdri.east.verizon.net) [00:02:16] Back. Okay, I'm an idiot. My early googling grabbed me an ancient version. Getting current, will give it a shot. [00:02:57] well, this component hasn't changed in several years because changing it could actually brick devices [00:09:41] Nifty. Well, seems to jibe. I grabbed 859, same issue with the ubi file, I'll try the downloads - could you send those two to me again? [00:10:15] nm, sorry, got them in buffer [00:12:07] Nope, same timeout errors on each. [00:12:52] so just to confirm: r876 does fail? [00:14:19] Okay, I'm going to reset on this - I've been tossing all over and I might have multiple versions like that emcoreldr issue. Looking at the builds, I'm quite sure I downloaded the 888s so no idea why I'm showing 859 somewhere else. Should I go all 876? [00:14:53] that's what I just tried on mine, and it worked [00:15:03] but there shouldn't have been any changes since hundreds of revisions really [00:15:10] Okay. Where can I find that? I'm hitting builds.freemyipod.org and only see back to 888 [00:15:27] just swap out the revision number in the url [00:15:54] aha. Been a long time since I've dealt with repositories. Will try that in a new scratch dir, brb [00:17:52] I also verified that emcoreldr.py works with both python 2 and 3 (the latter with a minor fix) [00:18:10] Well, I'm learning all sorts of fun things. Appreciate your patience. Yep - I ran into that earlier; saw the function change. [00:18:28] er, which one? [00:18:35] change in python 2 to 3 for print() [00:18:36] the one that I just spotted wasn't fixed in SVN yet [00:18:47] ldr wasn't running on 3 - the one I had at least [00:18:52] theres a data = "" line that should be data = b"" [00:19:09] that only crashes it when using the download function though [00:19:24] Aha. Well, let me grab this new set here - crash-learning about subversion. :) [00:19:41] the build server isn't really svn-related [00:19:49] Which do you recommend? I was grabbing SmartSVN. [00:19:52] it just happens to build a set of files for each svn revision [00:20:03] you don't really need SVN unless you want to build things yourself [00:20:06] Is there an easy way to download the whole revision at once? [00:20:12] I was just grabbing that tools set the hard way. [00:20:24] well yeah, for that it's useful [00:20:38] are you on windows? [00:20:44] if yes I'd recommend tortoiseSVN [00:20:48] that kind of the de facto standard [00:20:49] :) Might as well learn something. Yep, Win8. ok, will grab that. [00:20:54] Splendid, thank you. [00:26:35] Is there a later driver than the one dated 2/28/10? Thought I'd redo that as well. [00:27:06] as long as DFU worked, that driver should be fine [00:27:10] ok [00:27:22] actually we're having a lot of trouble with newer drivers [00:27:33] Happy to be old school. [00:27:40] if you want to roll your own one (seems most reliable), you can use zadig to build one [00:28:00] That's Advanced Class. I've been management for a decade, so I have no talent left. [00:28:22] oh, using zadig is straightforward [00:28:52] heh. I'll be able to update my resume after this adventure. If you're confident that the one I have should work, I'll stick with it for now - one variable at a time. [00:29:15] hm, actually I'm not confident that the one you're using for DFU is the same :) [00:29:30] but if you were able to install both with the same inf file, it should be [00:29:45] Oh joy. How about the latest stable compiled one? I had no trouble with the driver once I disabled signed checking. [00:29:52] Came right up, no errors. [00:29:54] anyway, all driver issues so far were "didn't work at all" or "bluescreened" [00:30:12] Outstanding. Happy to grab a later stable one, though, if you've got one handy. [00:30:15] so if it does *anything* it should be fine [00:30:18] ok [00:30:32] Got tortoise, going to order IT food and alcohol, back in a short while. [01:27:29] Okay, redid it all from scratch, grabbed 876, same thing. :( [01:27:29] Exception usb.core.USBError: USBError(None, 'usb_release_interface: could not re [01:27:31] lease interface 0, win error: The device does not recognize the command.\r\n') i [01:27:31] n [01:27:31] > ignored [01:27:47] that was on the downloads. [01:31:39] nb also, after the attempt, with recovery still showing on the ipod, the Windows USB-disconnect sound occurs and the device disappears from dev manager, and then approximately every 30 seconds after the USB-connect sound occurs and devmgmt flashes but the device doesn't appear (recovery screen still showing on ipod). [02:09:26] *** Quits: liar (~liar@83.175.90.24) (Remote host closed the connection) [02:37:20] zxcasd: that exception is harmless [02:37:33] it's some kind of "couldn't clean up because someone already did it" [02:38:05] so did it actually download something? [02:40:44] if so, please upload the file somewhere and send me a link to it (privately, copyright issues) [02:41:12] please also note that the dump contains device-identifying information, such as the serial number etc. [02:41:35] Oh - would have been nice if I'd checked. Not on bootflash.bin but the test.bin one created a zero byte file. That's it, though. [02:41:39] if it didn't actually dump something, was there another exception above that one? [02:41:48] I'll c/p the whole set. One sec [02:42:19] Forgive the line breaks. [02:42:20] C:\temp\tools2>python emcoreldr.py download 0x20000000 0x1000 test.bin [02:42:20] Connected to emCORE Loader Recovery Mode on iPod Nano 2G, USB version 1 [02:42:20] Downloading 0x1000 bytes from 0x20000000 to test.bin...Traceback (most recent ca [02:42:20] ll last): [02:42:25] File "emcoreldr.py", line 82, in [02:42:25] parsecommand(dev, sys.argv) [02:42:25] File "emcoreldr.py", line 68, in parsecommand [02:42:25] dev.download(to_int(argv[2]), to_int(argv[3]), argv[4]) [02:42:25] File "C:\temp\tools2\libemcoreldr.py", line 166, in download [02:42:26] f.write(self.read(offset, blocklen)) [02:42:31] File "C:\temp\tools2\libemcoreldr.py", line 129, in read [02:42:31] block = self.__getbulk(self.handle, 0x83, 0x10 + blocklen) [02:42:31] File "C:\temp\tools2\libemcoreldr.py", line 63, in __getbulk [02:42:31] data = handle.bulkRead(endpoint, size, 1000) [02:42:33] File "c:\python27\lib\site-packages\usb\legacy.py", line 159, in bulkRead [02:42:33] return self.dev.read(endpoint, size, self.__claimed_interface, timeout) [02:42:33] File "c:\python27\lib\site-packages\usb\core.py", line 654, in read [02:42:33] self.__get_timeout(timeout) [02:42:37] File "c:\python27\lib\site-packages\usb\backend\libusb01.py", line 483, in bul [02:42:37] k_read [02:42:37] timeout) [02:42:37] File "c:\python27\lib\site-packages\usb\backend\libusb01.py", line 568, in __r [02:42:37] ead [02:42:38] timeout [02:42:43] File "c:\python27\lib\site-packages\usb\backend\libusb01.py", line 384, in _ch [02:42:43] eck [02:42:43] raise USBError(errmsg, ret) [02:42:43] usb.core.USBError: [Errno None] usb_reap: timeout error [02:42:45] Exception usb.core.USBError: USBError(None, 'usb_release_interface: could not re [02:42:45] lease interface 0, win error: The device does not recognize the command.\r\n') i [02:42:45] n [02:42:45] > ignored [02:42:49] ok [02:42:54] the upper one is the interesting one [02:43:02] so it times out again... odd [02:43:09] Yep, consistently. [02:43:24] Still sitting pretty on the emcore loader/recovery screen. [02:44:22] hm... I have an idea [02:44:49] I've got my sledgehammer ready. [02:45:04] in libemcoreldr.py, somewhere at the top, there are these lines: [02:45:04] self.maxin = 528; [02:45:04] self.maxout = 528 [02:45:09] can you change them to 512? [02:45:19] sure, then try again? Or other changes too? [02:45:28] just try the bootflash download again [02:45:32] ok back shortly [02:47:37] (the ; doens't really belong there either, but is harmless) [02:49:01] This thing is so picky... unplug, wait, bounce, wait, plug, cross fingers, try the dfu, if nothing, rinse and repeat. It's odd - when it "fails", the command line says success but recovery mode doesn't come up and I have to do it again... not sure if I'm just not waiting long enough. Grr. [02:51:23] hm, should be fairly straight forward. press+hold menu+select for 5+ seconds, turn on hold switch, run DFU script [02:51:42] that should in theory succeed in 100% of the attempts [02:51:47] So far I've found that I absolutely must unplug/replug it somewhere in there. [02:52:25] kinda odd, because the menu+select reset actually power cycles the whole processor chip [02:52:36] Yep, just did what you said and the dfu says complete but the pod is still black. [02:52:44] so maybe windows takes too long to realize that it's gone or something [02:52:55] Oh, I've no doubt it's Windows. [02:53:27] ffs. Okay, this time I'll wait 10s... I hate inconsistencies. [02:53:40] * TheSeven knows that feeling :) [02:55:37] I'm starting to think my pod connector might be flaky or corroded or something. One sec, grabbing new cable and some deoxit... [02:59:05] Yeah, came right up without the unplug/replug that time. Edited the file, trying the dl [02:59:25] same failure mode [02:59:36] 0 byte file, etc. [02:59:42] grr. [03:00:17] Glad I didn't take my Adderall, otherwise this would drive me nuts. Without it, I enjoy OCDing. [03:00:56] * TheSeven starts to think we should try ruling out a PC/OS-side issue [03:01:12] Fair enough - got an XP PC right here. Driver ok on that? [03:01:21] I'd vote for linux if possible [03:01:32] that completely rules out driver problems [03:02:02] Ugh, that's very difficult right now. I just moved and everything's in storage. Hmmm.. Let me try the XP for giggles; if it fails I'll shelve it until I can get one of my *nix boxes up. [03:02:16] ...or just boot a live CD [03:02:21] no cd drive :) [03:02:28] ...or thumbdrive :) [03:02:45] Hmm... that I can do. Haven't done it before. Point me to an ISO? [03:03:27] It'll take forever to download; riding on neighbor's internet until mine goes in. I'll grab it overnight and try tomorrow - will try XP now while I wait. [03:06:21] http://www.ubuntu.com/start-download?distro=desktop&bits=32&release=latest [03:07:01] Wonderful. Thanks so very much. I'll try XP and pop back with an update if it miracles it back to life, otherwise will hit that when it finishes and check in tomorrow. Thanks so very much for your help! [03:07:23] *** Quits: zxcasd (tom.zxcasd@pool-72-87-98-43.prvdri.east.verizon.net) () [03:07:37] http://www.linuxliveusb.com/en/download [03:09:38] I'll be available again in ~10 hours [06:47:42] *** Quits: TheSeven (~quassel@rockbox/developer/TheSeven) (Disconnected by services) [06:47:52] *** Joins: [7] (~quassel@rockbox/developer/TheSeven) [14:53:23] *** Joins: liar (~liar@83.175.90.24) [14:53:24] *** Joins: zxcasd (~tom.zxcas@pool-72-87-104-91.prvdri.east.verizon.net) [14:53:50] *** Quits: zxcasd (~tom.zxcas@pool-72-87-104-91.prvdri.east.verizon.net) (Client Quit) [15:37:18] *** Joins: zxcasd (~tom.zxcas@pool-72-87-104-91.prvdri.east.verizon.net) [21:34:42] *** Quits: zxcasd (~tom.zxcas@pool-72-87-104-91.prvdri.east.verizon.net) (Ping timeout: 264 seconds) [21:34:45] *** Joins: zxcasdqwe (~tom.zxcas@pool-72-87-102-88.prvdri.east.verizon.net) [21:44:18] *** Quits: zxcasdqwe (~tom.zxcas@pool-72-87-102-88.prvdri.east.verizon.net) ()