So before I never checked md5, didn't Really no a good way to do so. So I always flashed and hoped for the best. It worked out for the most part, but still get those times, when I'm trying to figure out what app is causing problems. When all it was, was a bad download.
So the way I just figured out is, when I use Es File Manager to transfer the Rom I just downloaded to the folder I put all my Rom's in. Well I noticed, if you long click on the rom.zip file. Scroll down to properties, then there's a button called "Show Checksum" then from there you can calculate md5, then gives you an option to copy or save as zip.checksum file, which I open with hovernote. Then its super easy to compare when reading you Rom's thread.
Idk if everyone already knows about this, I just stumbled upon it, when changing permissions to a file. And thought I would share.
Now I have to ask is there even an easier way to check md5, or what method do you use?
Also, since I never checked md5, I wouldn't know, but when/ if the md5 isn't a match. Is it completely different or is it just one number/ letter that's off?
If I helped, show your appreciation with the Thanks Button below.
When I've had mismatches its been way more than one number off. If you use root explorer go to properties it will calculate md5 too.
They differ a lot
No worries, hash functions have a property known as the avalanche effect that causes the output to be vastly different even though the input is the same. Although it can't be avoided, due to the pigeonhole principle, the chances of stumbling upon a pair of sums that share half of their characters are so slim that it is more likely to win a huge lottery three times in a row.
Related
Hi,
I have tested this behaviour on both a N1 and the emulator. Could anyone tell me if that is a problem? How can I avoid the recursive code going forever? What is happening?
If you use any file browser/manager and starting going into /sys/devices/w1 bus master/subsystem/devices/w1 bus master/subsystem it will go inner forever, repeating that pattern devices/w1 bus master/subsystem/ all the way.
So when I run a recursive search it keeps going deeper and deeper and seems never to finish.
What is happening, how to avoid this behaviour?
I tried different file managers and they all seem to be going forever into these folders, although when I do a search through Astro it doesn't seem to get stuck with this loop (It seems to ignore the /sys folder, but I am not sure if this happens also in any other folder).
Some people point me this problem can be related to symlinks, but I didn't find a way of checking for those symbolic links with Android's Java.
I know it can be done (as proved by Astro file manager), I just don't know how.
Hopefully it won't involve any call to functions which I'll have to create using NDK, which would be a pain.
Regards.
astro goes infinite for me on an N1
I think any app needs to do some extra checks instead of following stuff down.
eg the "find" command has the "-follow" option
open a terminal or use "adb shell" and "cd /sys/bus"
now type in "find" and it will display all the files directories and symlinks without following them
now type in "find -follow" - you will need to press Control-C to get out, you will see that each line has an error "too many symlinks" - kernel has protection/limit for symlink levels.
writers of file managers could easily fix this, but you have to ask what you were doing in their anyway?
Lol, I was trying to find some info to address this problem under Android & found a relevant thread I thought might help, only to discover it was you (jfbaro) having this conversation on another forum
Specifically, this thread on anddev.org.
I don't know Android yet, but a getCanonicalPath() like call is always going to be at the heart of spotting in advance & avoiding this type of problem, whatever your environment & language. If it doesn't work either the function is broken or you're making a mistake somewhere, I'm fairly sure.
In the above thread you say this doesn't help you. Can you post what getCanonicalPath returns for both /sys/device/subsystem/ & /sys/device/subsystem/sys/ ?
Let's assume you start your traverse at / & have reached /sys/device/subsystem/. When you check to see if it's safe to follow /sys/device/subsystem/sys you should discover that the latter is actually /sys, and that further, it is in your list of already scanned directories, hence you do not search further down that branch.
Where is this breaking down?
[Edit:] You might also find something of use buried in this bug thread which involves similar issues. Funnily enough it concerns Eclipse, but all that matters is that it's a Java based example of the problem. From a quick scan, getCanonicalPath again seems to be the solution though I think they avoid any performance hit by only using it on files known to be sym-links.
So the signature is encoded over the update.zip right so all we need to do is steal the difference between signed and unsigned update files they have to be the same file but uziping and reziping does so. All that needs to be done from there in my thought is calculate each offsets difference and bam signature. Now create a new update.zip with all rooted files. Clockwork and s-off being all we need. Make the update the same size exactly and add the difference we obtained to it and bam rooted it is
Sent from my T-Mobile G2 using XDA App
public key cryptography 101 says it wont work.
Why won't it work if I may ask.
Sent from my T-Mobile G2 using XDA App
What you are proposing sounds acurate in my head, but everything says it doesn't work that way. I guess some things I will never understand..... Women is another one.
Ill do it on my own and test it when I get home again. MORE COFFEEE!!!
Sent from my T-Mobile G2 using XDA App
Chances are the security will relise something is wrong when doing the update even if everything is set perfectly and thus you may end up with a bricked phone.
Yayy for phone insurance claims then
Sent from my T-Mobile G2 using XDA App
More power to you then my friend, go nuts, maybe youll get something out of it that helps with the perm root.
Dom18 said:
Chances are the security will relise something is wrong when doing the update even if everything is set perfectly and thus you may end up with a bricked phone.
Click to expand...
Click to collapse
I highly doubt that will happen. Look at all the failed updates due to the whole goggles thing.
Quick question though how does one set s-off in the image so I can try this. And to clarify I'm using a hex editor to re-add the diff from the signed and unsigned updates so the calculating will be a headache :/
Sent from my T-Mobile G2 using XDA App
Didn't they say decrypting the signature from or the key would take a lot of time, i mean were talking years?
Just incorrect in every way imaginable. That's not how signature verification works. If cryptography could be circumvented that easily no one would use it. I am not going to explain asymmetric encryption in this thread, there are plenty of resources for that. Let's just say what you're proposing here has no chance of working whatsoever.
Start here: http://en.wikipedia.org/wiki/Public-key_cryptography
and here: http://en.wikipedia.org/wiki/Digital_signature
Unless HTC put an idiot in charge of their crypto, what you are proposing won't work.
Yeah, if you are lucky, they will have put jdkoreclipse in charge of that. I think that is the only way the encryption could be done as poorly as you are suggesting.
funkadesi said:
Didn't they say decrypting the signature from or the key would take a lot of time, i mean were talking years?
Click to expand...
Click to collapse
I forget where I suggested this... but I was thinking someone could write one of the [email protected] or bovine (for those who remember) type application, where the client can run on anyone's machine that tries to crack the key by connecting with a central server in a coordinated effort. All of us G2 owners could run the client on 1 or multiple machines 24/7 and we may get lucky and find the real key.
I'm willing to install it on every machine at work if someone will write that client program ;-)
reference: http://www.distributed.net/RC5/en
To the best of my knowledge unzipping and rezipping it wouldn't break the signature...
I don't want to be insulting but if you do not understand PPK cryptography and how cryptographic signatures work please do not try and "break" something that has been evaluated and probed by numerous security experts in an attempt to find vulnerabilities.
It might be possible to crack ppk based signatures but it is not a simple matter of a diff between pre and post signature files. Again, I don't want to hurt anyones feelings but people A LOT brighter than you who actually understand the mathematics involved are not able to do it.
Put simply I will give you 2 documents, a signature for one of the documents, and a public key to verify the signature. If you can derive the key from which the signature is made or a way to create a valid signature for the second without the key you will be famous overnight since you will have found a vulnerability in one of the cornerstones of modern cryptography. Again it is possible but the chance of success without knowledge of the mathematics involved is monumentally small. Even with knowledge of the mathematics such a crack has not been found by people dedicated to researching such vulnerabilities.
Sorry for the rant but voodoo mechanics is a sore subject for me.
The simplest way I can explain it is the following.
Let's say they put a tag in the file that said "Google signed this". All someone would have to do is move that tag to a new file and it would look like Google signed that new file. So, that process doesn't work.
OK, let's say they put a tag in the file and said "Google signed a document that contained these bytes - blah blah blah", well same problem, someone could move the tag and edit the "blah blah blah" part to match their new file, so that doesn't work either.
So, instead Google puts their signature into the file, then they encode that file in a way that only they know how to do, but using an algorithm that they can make public the way to decode it. So, everyone can still get access to the contents, but nobody knows how the magic "encode" process works so nobody can pretend to be Google and produce a file that has their particular encoding. Since their signature is inside the part that was encoded, it is clear that they put their stamp on it prior to running the encode algorithm so you know for a fact that it was "signed at the Google factory".
Someone can try to put Google's signature in another file and then try to figure out how to do that encoding, but they wouldn't be able to mimic the exact way that Google does it so everyone would know that the encoded file came from someone else. Thus they are foiled.
A few details:
- The encode/decode process is actually a backwards encryption algorithm. Google encodes a file by "decrypting" it (i.e. pretending the real data was encrypted and running a decrypt on it and getting some garbage). The public then decodes this file by "encrypting" it (i.e. using the public keys to encrypt a file for Google and running it on the results of their decryption ends up getting back to the original file). Magic
- They don't really encode the entire file as that would be computationally intensive. Instead they generate a "checksum" of the original file that is both fast to compute and unique (i.e. the chances of a different file generating the same checksum is 1 in a HUGE number). They then encode that checksum (which is much, much smaller than the original file) using their special encode mechanism and not only can nobody produce a file that happens to have the same checksum (it is not known how to produce a different data stream that results in the same checksum), but they also cannot reencode the signed checksum due to the properties that make encryption so safe. (Note that the "checksum" algorithm here is quite a bit more complicated than adding up all of the bytes in the data stream - which would be easy to falsify - but it is still easier to compute than an encryption algorithm).
flarbear said:
The simplest way I can explain it is the following.
Let's say they put a tag in the file that said "Google signed this". All someone would have to do is move that tag to a new file and it would look like Google signed that new file. So, that process doesn't work.
OK, let's say they put a tag in the file and said "Google signed a document that contained these bytes - blah blah blah", well same problem, someone could move the tag and edit the "blah blah blah" part to match their new file, so that doesn't work either.
So, instead Google puts their signature into the file, then they encode that file in a way that only they know how to do, but using an algorithm that they can make public the way to decode it. So, everyone can still get access to the contents, but nobody knows how the magic "encode" process works so nobody can pretend to be Google and produce a file that has their particular encoding. Since their signature is inside the part that was encoded, it is clear that they put their stamp on it prior to running the encode algorithm so you know for a fact that it was "signed at the Google factory".
Someone can try to put Google's signature in another file and then try to figure out how to do that encoding, but they wouldn't be able to mimic the exact way that Google does it so everyone would know that the encoded file came from someone else. Thus they are foiled.
A few details:
- The encode/decode process is actually a backwards encryption algorithm. Google encodes a file by "decrypting" it (i.e. pretending the real data was encrypted and running a decrypt on it and getting some garbage). The public then decodes this file by "encrypting" it (i.e. using the public keys to encrypt a file for Google and running it on the results of their decryption ends up getting back to the original file). Magic
- They don't really encode the entire file as that would be computationally intensive. Instead they generate a "checksum" of the original file that is both fast to compute and unique (i.e. the chances of a different file generating the same checksum is 1 in a HUGE number). They then encode that checksum (which is much, much smaller than the original file) using their special encode mechanism and not only can nobody produce a file that happens to have the same checksum (it is not known how to produce a different data stream that results in the same checksum), but they also cannot reencode the signed checksum due to the properties that make encryption so safe. (Note that the "checksum" algorithm here is quite a bit more complicated than adding up all of the bytes in the data stream - which would be easy to falsify - but it is still easier to compute than an encryption algorithm).
Click to expand...
Click to collapse
I wanna add that most of that process is known because of AOSP and how we sign with the test keys. The only piece missing is google's/t-mobile's/htc's private key (because...who knows who really made the one for the G2?).
my 2 cents
Awaiting OPs response
my last mytouch4 worked out just fine... this ine however is pissing me off
I have done everything i can think of
uninstall-reinstall-wipe cache in recovery and still wont work right. dont get it.. last one worked right out the gate.
nlarge said:
my last mytouch4 worked out just fine... this ine however is pissing me off
I have done everything i can think of
uninstall-reinstall-wipe cache in recovery and still wont work right. dont get it.. last one worked right out the gate.
Click to expand...
Click to collapse
All that ranting, but no information as to what is actually going on. Are you getting an error message? FC?
Still getting ads.....
AFAIK, adfree simply adds a hosts file with the add servers in it, in which case you are seeing adds because either the servers changed or there are new ad servers that haven't been added yet. Devs need incentive to do the work they do, so just be happy that you can even get good apps for free and deal with it.
jdkoren said:
AFAIK, adfree simply adds a hosts file with the add servers in it, in which case you are seeing adds because either the servers changed or there are new ad servers that haven't been added yet. Devs need icnentive to do the work they do, so just be happy that you can even get good apps for free and deal with it.
Click to expand...
Click to collapse
An app is only as good as it works. I have run into the same issue as the op recently. Also I'm getting real tired of reading these smart ass remarks at the end of posts here to just like yours. Its unnecessary!
hey.. try this:
http://forum.xda-developers.com/showthread.php?t=919040
The above methods seem to work for me. I've never used adfree btw...
There is something odd going on with hosts. I have the same problem as you that ads continue. I have traced mine to the fact that the hosts file is continually overlaid by the default blank one. It appears there is some component that continually scans this and wipes it.
I posted this problem a couple months ago but never got a response. The best I did was install GScript Lite and create a script to copy my saved off version of the ad-free hosts file back over the real one. It is not a good solution but the only one I have. I suppose the ultimate solution would be a different ROM. But that would just trade the problem I understand for an unknown number of ones I don't.
ethutch said:
There is something odd going on with hosts. I have the same problem as you that ads continue. I have traced mine to the fact that the hosts file is continually overlaid by the default blank one. It appears there is some component that continually scans this and wipes it.
I posted this problem a couple months ago but never got a response. The best I did was install GScript Lite and create a script to copy my saved off version of the ad-free hosts file back over the real one. It is not a good solution but the only one I have. I suppose the ultimate solution would be a different ROM. But that would just trade the problem I understand for an unknown number of ones I don't.
Click to expand...
Click to collapse
i dont use adfree
ive never had an ad using this hosts file
extract it from the zip, and put it in system/etc
enjoy
Has anyone tried enabling the AdFree option to symlink to /local/data (I think? forgot the exact path it gives in the app). I use that and have never experienced any problems with this on Ice Glacier.
It works for me, perhaps its a device specific problem.
SE7EN- said:
An app is only as good as it works. I have run into the same issue as the op recently. Also I'm getting real tired of reading these smart ass remarks at the end of posts here to just like yours. Its unnecessary!
Click to expand...
Click to collapse
While I somewhat agree with your post, I agree with jdkoren's more. All of the apps you are blocking ads for were free, free because of the ads that help fund the development of the apps. So I think he's just saying, if you can't block the ads, accept it, you have all those apps at no cost... Everything we experience, this forum, these custom ROMs, market apps, all took great amounts of time and effort, I think sometimes we lose sight of that when we think about open source projects.
Can't post yet in Developers, but wanted to share this, since I read that a number of people are literally being tormented by their HTC Droid Incredible (DINC) phones because of a "feature" in the latest (and likely final) OTA stock update to build 4.08.605.15 710RD. The OTA contains a script to force the phone to reboot and rebuild certain files and databases overnight when activity with the phone is anticipated to be minimized. Problems arose when the rebuilding process repeatedly failed to complete, forcing the phone to reboot repeatedly over a series of nights. I know this happened to most of you back in June and July, but the OTA was pushed to me just recently (I got a used DINC a couple of weeks ago) so this could still be affecting people.
My DINC is rooted so I did not accept the OTA and experience the problem, but I really sympathise with folks being awakened at 02h00 night after night by the harsh "DROID" audio accompanying the standard VZW boot animation as it repeatedly rebooted for nearly 3 hours (or until exasperated owners pulled the battery -- which only made things worse!). Also, I happen to find the audio rather offensive at any time of day. Perhaps others do as well, even without this nasty nightime experience, and would like to eliminate it -- or just possibly substitute something else.
There are plenty of apps and scripts out there to help replace the boot video animation, but I have not come across an automated method of removing or changing the audio. (The audio is not integrated, because the "video" is actually a series of pictures, not unlike the sort of video created by flipping through a page-book animation full of still pictures that create the illusion of movement. It only looks high-tech because of the remarkable speed at which even a smartphone processor can "flip" the pages)
For those of you who do not visit the developers portion of XDA or other similar sites, here is a simple (but admittedly technical) fix.
You will need to be rooted. If you are not already so, this might be a good time to give it a try, since the DINC has surely reached the end of its supported lifespan, and is likely well past any warranty that might be invalidated by performing a root. Search the web and pick your favourite method to follow. Mine is the guide posted by Scotty85 here at XDA:
http://forum.xda-developers.com/showthread.php?t=1600904
Once rooting is done, all you need is a good file manager capable of gaining "superuser permissions" (one of the benefits of rooting includes the installation of a superuser app),. I recommend ES File Manager, but there are ones such as Astro and plenty more to suit any taste. For those who want a file manager designed especially for rooted phones, you can pay a little bit for the Root Explorer app. All you need to do after opening the file manager of your choice is to allow it to receive the superuser permissions. After that, it will be able to see anything in the Android setup. That's why it's called super-user!
When you open the file manager, you will probably find yourself looking at all the files on your SD card (/sdcard/), if like nearly everyone you have one installed. Locate the "up one level" button in the menu or on the screen, and touch it to go to the root of your entire DINC. There you will find in the list or collection of folder icons a directory named /system. Touch it to open it, and then touch the following directories as they appear on-screen:
/customize
/resource
Once you are inside the /resource directory, you will see lots of picture and video files. Amongst them is a single .mp3 audio file with the following name:
VZW_Droid.mp3
That is the one making all the noise at boot time!
Hold your thumb down on top of the file's icon until a list of options pops up.
I suggest you rename it with an extra extension on the right end of the file name. That way, if you change your mind and want to revive it, all you have to do is remove the suffix you are adding now.
For example, this is what I did:
VZW_Droid.mp3.ORIGINAL
That's all there is to it! Close the file manager. Restart your phone if you like, to make sure that the phone now boots silently. I promise you it will!
There is an opportunity here to substitute any MP3 audio file you like (but keep it brief - 30-45 seconds at most) . Simply put it in the same location where you found the Droid audio file, and rename it VZW_Drois.mp3. That way, the boot programming will invoke the audio at the right time.
I have tested the silent approach and using substitute audio, and they both work as expected in my DINC.
Sorry this was not more timely for you folks who ended up locking your DINC in the closet (or worse!) earlier this summer, but you can still give yourself some peace and quiet -- or even a bit of nice music to boot by if you like. :laugh:
Cheers!
Good thing I never excepted the update
Sent from my Droid Incredible using xda app-developers app
With root, there is a way out...
zachf714 said:
Good thing I never accepted the update/QUOTE]
So true! There are ways to block both the download and the notification, but only if your DINC is rooted. If pure stock (not rooted), then you must forever resist the urge to hit the Update button on the notification or in your settings. Not an easy thing for device users to do -- we are well trained like Pavlov's dogs to salivate at the sight of a software upgrade!
In case anyone can't resist the urge, at least there is a way to silence the DROID sound. See the opening post for details... :angel:
-- Stopping OTA downloads permanently (or at least until you reverse this fix):
http://forum.xda-developers.com/showthread.php?t=844702
-- Eliminating the notification in your notification bar (harmless, since the download is now stopped up, but perhaps a bit annoying. It actually takes MORE work to do this bit than the really important one regarding the download... :
http://forum.xda-developers.com/showthread.php?t=836120
http://forum.xda-developers.com/showthread.php?t=844702&page=8 (starting with post #73)
Thanks to Senior Member ejdavis72; Member Mach3te; and Senior Member cmlusco for their contributions in these threads.
Oh, and don't forget to use a root-capable file manager (e.g. ES File Explorer) to find and delete that little OTA bomblet hovering in your /cache directory. Alternatively, you can just reboot into your recovery and reformat the /cache.
:good: Cheers!
Click to expand...
Click to collapse
I'm using the stock nook reader and renate's Library.apk. How can you make sure the last read icon on the top bar corresponds to the last read file in the library?
I am not sure where this icon gets its link. It doesn't seem to always open the last read file.
I've been thinking about asking this question (although I am using the stock reader AND library apps). My "reading now" button is getting really cranky of late. It often just goes to the first page (cover) or sometimes it goes to the first page AND displays a two-option message about the different current reading positions in two Nook readers (!) and which one do I want (generally neither is correct). Right now the only sure way to get to the correct page is to go to the Library screen and select the book from there. So the Nook does remember, but the Reading Now button is not functioning properly.
For a time I had a number of B&N apps disabled (renamed ".bak") and gradually discovered the imponderable connections that seemed to render little things inoperable. I've had to restore quite a few of the apps to running to keep everything functioning except Nook Community (because the constant "nagifications" drove me crazy) but this button behavior has me baffled (as does the reference to two Nook readers!)
I wonder, are you using any sort of "cleaning" app? I am using Clean Master and find it helpful in freeing up memory but I'm beginning to think that some of the data it is throwing out might just contain the info that the button needs to function properly. It certainly messes with Tasker.
The "Last Read" icon on the status bar sends out the intent com.bn.nook.launch.LAST_BOOK
This would normally be handled by Home.apk
If you deleted Home.apk and are using my Library.apk it has its own receiver for that.
Depending on which version Nook software you have it will query
content://com.bn.nook.reader.providers.lastreadingpointprovider/
content://com.bn.nook.reader.common.providers.lastreadingpointprovider/
The LRP database is maintained by the Reader(RMSDK).apk.
Checking for the latest modification gives you the last book read.
My Library.apk sends an intent out to open that book.
Currently Library.apk does not update the order of books displayed in "Last read" unless the refresh button is hit.
Two things to look for if you are having problems:
If you let the battery die and the WiFi is always off the clock time will be wrong.
If you crash or shutdown improperly Reader(RMSDK).apk will not get a chance to update the LRP.
P.S. I just noticed a possible anomaly if you read PDF's in the reader too.
Oh! It just occurred to me one thing.
I remember opening a book that you have been reading already and it opens at page 1.
This was tied to opening the book in different ways.
There are different ways to open a book:
Through the "Last Read" icon and stock Home.apk
Through the stock Library.apk
Through my Library.apk
Through a file manager application
The LRP database is /data/data/com.bn.nook.reader.activities/databases/lastreadingpoint.db
Code:
CREATE TABLE lastreadingpoint
(_id integer primary key autoincrement,
ean text, // file URI
luid text,
offsetrmsdk text, // subfile path fragment
lastupdated long, // Unix milliseconds last read
bookdna int, // always 1?
sync_status int // always 1?
);
ean (which normally might stand for European Article Number, i.e. "UPC") is a URI, not a path.
Code:
sqlite> select ean from lastreadingpoint;
file:///sdcard/Books/aboveall.epub
...
There may be cases where a single book gets different ean's.
If you could look at LRP and see if this is so?
I actually managed to locate that db file on my own (!) and what seemed to be a companion with related information (readerlocal.db). They seemed to be full of junk info (books that had since been removed, etc.) although there were no duplicate entries, which is what I had suspected.
Anyway, I got a little "brave" (i.e., foolhardy) and decided to clean up both files in a parallel way. Then I pushed them back, reset the permissions and rebooted.
Yikes. My Nook is set to go to the B&N Home screen only on reboot. That screen flickered and flashed, never filling in any of the images. I could still use the "N" button to access other parts of the system and they were working fine, but any return to the Home screen via the Back button showed it was still in distress.
So....restore from backup...again.
It seems OK for now. I have noticed that the little "refresh" button in the Library does sometimes seem to go on and on and on without any accomplishment. I have suspected the issue was how I accessed the book-in-progress as you described. Since I sometimes read more than one book at a time, I'm all over the place with how I do things (including a Library icon in my App home screen). I'm going to try being more disciplined for a while and see how it behaves.
nmyshkin said:
I actually managed to locate that db file on my own (!) and what seemed to be a companion with related information (readerlocal.db). They seemed to be full of junk info (books that had since been removed, etc.) although there were no duplicate entries, which is what I had suspected.
Anyway, I got a little "brave" (i.e., foolhardy) and decided to clean up both files in a parallel way. Then I pushed them back, reset the permissions and rebooted.
Yikes. My Nook is set to go to the B&N Home screen only on reboot. That screen flickered and flashed, never filling in any of the images. I could still use the "N" button to access other parts of the system and they were working fine, but any return to the Home screen via the Back button showed it was still in distress.
So....restore from backup...again.
It seems OK for now. I have noticed that the little "refresh" button in the Library does sometimes seem to go on and on and on without any accomplishment. I have suspected the issue was how I accessed the book-in-progress as you described. Since I sometimes read more than one book at a time, I'm all over the place with how I do things (including a Library icon in my App home screen). I'm going to try being more disciplined for a while and see how it behaves.
Click to expand...
Click to collapse
Would it be possible to write an app that simulates opening the last read book from only one of the Library apps and then map that to the last read icon to simplify this whole system?
mergen3107 said:
Guys, if you are concerned about why sometimes the last read option goes to the 1st page, then it was already fixed by our forum users somewhere here. (I could hardly remember and trace where it all started but finally it was successfully solved)
Just install a file this package (internal.db deep in the 'data' folder. You could delete 'system' folder - this is hyphenations dictionary for Russian) through cwm or replace it manually (the zip contains detailed path) and here you go.
Click to expand...
Click to collapse
Now that was an interesting trip! Once I had Google do some translating there were a number of really interesting posts that were (mostly) intelligible. I'd want to compare that modified internal.db file with what's already on my Nook before I did any replacing. A lot of the work from that site is "russified" (not surprisingly) and there may be other changes there not really needed/wanted, but it's a good start.
I noticed in another posting there that someone said there is a related issue with in what state the Nook is connected via USB. Apparently the hypothesis is that if you don't connect while in the Library you stand a good chance of scrambling the "reading now" database entry. I've certainly been hooking up with my Nook in all kinds of states, so if that's correct, no wonder my database file was so messed up!
Installation of the internal.db file from the Russian source will not work. I've tried a side-by-side comparison of the file with the one from my Nook (FW 1.21) and there are differences (beyond the region identifier, which is easily changed). It's not at all clear what changes have been made or from what firmware the modified file came. In any case, it causes havoc when exchanged for the native internal.db
The Russian discussion points to this thread on XDA which approaches (and apparently solves) the problem another way. I'm going to give it a try.
nmyshkin said:
Installation of the internal.db file from the Russian source will not work. I've tried a side-by-side comparison of the file with the one from my Nook (FW 1.21) and there are differences (beyond the region identifier, which is easily changed). It's not at all clear what changes have been made or from what firmware the modified file came. In any case, it causes havoc when exchanged for the native internal.db
The Russian discussion points to this thread on XDA which approaches (and apparently solves) the problem another way. I'm going to give it a try.
Click to expand...
Click to collapse
Do I read this correctly, http://bit.ly/Q7MytN from that thread there should be no problem if renates Library.apk is used exclusively and the stock Library.apk has the bug?