Third Party > Repairing and Upgrading Rockbox Capable Players

is unbrick procedure also working for sansa clip zip?

<< < (3/5) > >>

tent:
hello maxwami,
 unfortunately my sansa clip zip still lies there waiting for someone to tell if there is some pins that could be used to do the "last resort" unbrick that is available for clip v1 and v2 also for the zip.. but no news so far I understood... :(
 Also my single guessing trial on two pins was unsuccessfull so far as well and I did not want to continue trying on other random ones, so.. hope someone will sometime show up with good news maybe? I'm convinced that there are two similar pins also in the clip zip.. maybe someone could tell a method to discover them like it was done on v1 and v2 (or was it random trial and error??)

tent:wq

PS: I'm speaking about this procedures listed here: http://www.rockbox.org/wiki/SansaAMSUnbrick for all sansa players BUT not for the ZIP so far..

maxswami:
thanks for the reply
But I am just thinking of leaving the zip alone for a few days.
Maybe it'll help?

[Saint]:
Well...

Unlike getting in there and poking around with something conductive, it certainly couldn't hurt.

The page linked by tent not mentioning the Clip Zip at all documents what is known about this method of recovery for the device. Absolutely nothing.

Matter of fact, very little is known about the recovery process at all for the targets where this does work. It is certainly not an exact science, nor is recovery guaranteed, in fact improper use of this method has killed more devices that probably weren't actually bricked in the first place than it has ever saved.


[Saint]

tent:
Actually I was just trying to get the answer about how did you find those recovery pins to be bridged on the otehr devices!

Maybe it could help me to replicate the finding for the clip zip.

At least I have nothing particular to lose: my device is definitely unrecoverable and went into this status because I rock boxed it first time by using automatic procedure but having wrongly selected the destination drive (I gave drive d: that was another disk, while it being e:). Basically I suppose that bootloader got written but not the filesystem, so at the first reboot it stopped working remeining as described in previous posts in this strange eternal boot logo situation.

So back to topic: are you saying that those two solder points to connect to recover the other device were found by random poking around?? is that what you mean by not exact science? well.. ;)

tent:wq

[Saint]:
Please don't say this.

At least not without any form of "evidence" other than "I did X, and then Y happened".

The situation you describe wouldn't do anything to your device, since you selected an incorrect destination drive. Unless you also did other steps you have not listed, nothing on the device was modified...at least, not by Rockbox Utility.

I admit, if the sequence of events happened exactly as described, I can see why you would draw that conclusion - but an understanding of the underlying processes behind the installation suggest that this simply isn't the case. Until the event that you or someone else manages to repeat this, please do refrain from stating that the cause of this was Rockbox Utility.



[Saint]

Navigation

[0] Message Index

[#] Next page

[*] Previous page