TheSaint

I discovered a bug and have fixed and re-upped. This would have been present in the first version as well, and somehow I overlooked.

Updated to MD5Compare v1.2 I decided to add a couple more basic features to make it more complete ... even though I do use other software for those.

Goodo. I remember having issues once upon a time (some years ago) with surround sound (multiple channel) wav files not being recognized as such, due to some header issue etc.

And you can also use other methods, especially if this is just a text file. A very simple approach if you know your insertion point, and it is based on unique text, is to FileRead your file, then use StringSplit with the unique text, then add all three parts together and then FileWrite back to the file with that, overwriting it. The only tricky bit, is if you are not familiar with an array, which is what StringSplit creates. But as suggested, back your file up first, just in case. Have a play, and any further questions, keep asking here.

Just a little project of mine, that I thought I would share. Basically, I have a scenario sometimes, where two files have the same size, but have somewhat different file names, but I suspect them of being the same file, one renamed. An example of that, would be something like a pdf file in a zip file, that is a game manual, and the game got updated to v1.1, and that zip file was renamed to suit, and is the same file size, but could possibly be different. I have that happen a lot with downloads from the ZOOM Platform game website. So rather than relocating a copy to another folder (as I have so often done), and renaming it to match the other file, and then testing with something like TeraCopy, I eventually decided to build my own simple MD5 checker that compares the MD5 value of two files, which it has calculated. You populate the source fields by drag & drop, preferably to the GREEN and BLUE 'Source' labels. Version one of the program was a simple affair, but then I decided to play around with progress bars, because I'd had it mind for a while, to develop my own for the Hash Encrypt function, which I use in several of my programs. The speed of incrementation of the progress bar, is tied to the previous calculation (file size & time), so at best is only approximate, so not much more than a guide, but hey, something is better than nothing. The first thing I needed to do, was create a separate command-line based EXE file (MD5checker.exe) for doing the checksums. It records the file size and time taken and checksum values in a 'Setting.ini' file, shared with the calling program (MD5 Compare.exe). That calling program uses the AdLib commands, to check on the progress of the hashing, while waiting for it to complete for each file being compared. MD5 Compare v1-2.zip (29 + 1 previous downloads) Enjoy! P.S. If you want to use an algorithm other than the MD5 one, be my guest. I know we can use better ones, but as I sometimes use my program for other scenarios, that involve a recorded MD5 value, I've just stuck to MD5, which is reliable enough.

Yeah, tell me about it. And my usage essentially hasn't changed, from the first 18 months, where I had no real issue, until now. What has changed, is updates to my device, so clearly they screwed something or the number of ebooks on my device is a factor ... though to be sure, my Kobo device still has much more space free than used. And as usual, I always treat my devices and drives well, which is carefully. I also never charge my devices, until almost flat ... be that ereader or phone or tablet etc. I eject properly, store and transport properly, etc etc. My money is on nerdy coders and flawed management as being the real issue ... and I've seen that across many devices.

Latest v1.4 update now available, see the first post. Some more improvements came to mind. Latest Changes Been busy, so missed doing the v1.3 upload. For Your Interest I finally managed to fix all the images on my Kobo device. This involved the images for the newest ebook additions to my device (around five), plus all the side loaded ebooks, where the images were either black & white instead of color or were badly sized, or in many cases, both. I then double checked the lot to be doubly sure all were now present & acceptable. I did that last with my program, and also with my Kobo device. A Rehash Of My Situation Latest News So anyway, I finally had the image situation on my Kobo device, like I wanted. But then of course, I needed to do a sync, to get my latest ebook purchase. On this occasion a surprise waited for me ... Sync appeared to be working and actually completed ... WTF ... Why? The first inkling I had of this, was my latest five acquisitions at Kobo, automatically went into 'Pending' status after the list was updated. They then proceeded to download, one after the other, then the device went into the 'downloading covers' state, which always takes a while to complete, but after several minutes did finish, then it did 'Annotations' etc and then the Sync completed. WOW ... I could not believe it. Reflections So that's it for now, and going forward I will probably only reply further if new revelations come to light, or in response to posts from others. I will finish up by saying how nice it is to see all the cover images on my Kobo device, when browsing or when putting the device to sleep. It had been too long since that was regularly the case. Fingers crossed.

Latest v1.2 update now available, see the first post. Some more improvements came to mind, and I discovered a rare file name issue. Latest Changes Some of this will come in handy when I get around to addressing (fixing) black & white and wrong size cover images, next time the battery in my Kobo device is flat.

A note about the new orange row entries. I've discovered, that some ebooks share the same sub-folder numbers. Three ebooks worth of images (9 in total) in the same folder, is the most I have seen so far, so the numbers on many occasions are not unique to just one ebook. Mostly though, when it occurs it is just images for two ebooks (6 in total). The new right-click 'Mismatch' option is great for revealing all such cases. And now a reminder, that it isn't just images for ebooks on your Kobo device that can appear in the number sub-folders. It appears that some other images show up, that are either advert related or related to a specific author or ebook. So in some cases, the extra or additional ebook(s) in the number sub-folders are that type. This occurs even more in the device sqlite file.

Latest v1.1 update now available, see the first post. My program has now had some significant use by me, and so I've modified a few things and even added some others. It should be pretty close to its final form now. Latest Changes That last modification, can kind of qualify as a bug fix, but unlikely to impact anyone who has less than 700 or so ebooks on their Kobo device. I was impacted at 729. Apart from those five ebooks I mentioned, all my ebooks now have cover images, though I still need to correct a few cover images that are Black & White or wrongly sized.. So that a fix so far for a few hundred ebooks on my Kobo device. P.S. I may yet add some kind of comparison option, to more easily discern if fixed images, do indeed become unfixed by the device software at any point. I've discovered none so far, when I sync, though some ebooks on my device do still lose one or more of their cover files. I guess I will find out soon enough. I am hoping for a permanent fix of course, but that might not be attainable. As it is, newly added ebooks seem to mostly lose their cover images. That last, may be due to how I add them to my device ... syncing fails for me, so I have to pretend each of them is the ebook I want to read now, and so they immediately download and open, and then I close them and reset to 'unread'. And there will still of course be the issue with newly side-loaded ebooks, where they often end up a Black & White variant and or the wrong image size. So I ill likely be using my program somewhat regularly, if only for a few ebooks each time.

Latest update now available, see the first post. Sometimes I make myself laugh ... which is probably a good thing. I can be so sure I've come to end of thinking of new additions and changes, and then something else pops into my brain while asleep or during waking. Such happened today, and so we have another update. Basically, as I was waking, I was contemplating how best to approach working with the Kobo device today. I knew the battery was flat, and that it takes around an hour to charge, so I had that window before I then started getting USB connection issues due to the device being fully charged. So I wanted to make the most of it. That was when it occurred to me that some kind of guide via my program would be helpful in speeding things up etc. That meant having controls (buttons) indicate they were the one to click to get started etc. The first approach I thought of, was using a graphic rectangle around a button, that was colored red, and hide or show that as needed. I'd done that before in a couple of programs, but as I recalled it, it could be a bit tricky ... and I couldn't recall what programs I'd done it to, so would either have to spend time searching for one, or attempt to do it all again from scratch. Then I thought that colored text on the buttons could be almost as effective, so did that instead. Of course, you could color the buttons instead, but you can lose the visual of the push effect. Latest Changes Anyway, I did some of that stuff after creating or adding images to my Kobo device. I managed to process over 100 entries today, and about a third of that was done before implementing the new auto NEXT option. Aside from one ebook, which I need to redo, all the others worked a treat. I'm not sure what happened with that one ebook, but I had connected my Kobo device via wifi a couple of times since building my working list, and sometimes missing number sub-folders and images on them get created during a sync, so it could be related to that. I used my newish 'Restore' option to reset for that entry, but not yet redone it because my Kobo was fully charged and the USB connection started playing up again. P.S. At this point I am not sure, if syncing sometimes causes a loss of number sub-folders and thus their contained cover images. In any case, I have been building a record with my program, and so I guess I will see if that ever happens, or is just the result of my device not downloading everything properly from Kobo.

Latest update now available, see the first post. If I had only realized, there was so little to do, I would have included the changes in my last update. But I was too tired to investigate anything more yesterday. Anyway, I checked today, and determined I needed to do very little, to get the FIX COVERS button code up-to-speed. I've not changed anything substantial in the way it works, just some of the record keeping aspect. See the following details. Please be advised though, that I haven't tested the process yet ... not since I last tested at least 10 months ago. It should work like it did previously, just with extra records. Some related stuff follows. This will hopefully be the last update, at least for a while, unless I find a bug. So I am now seeing my program as version 1, and essentially as a full version, some incomplete aspects aside, which are not a requirement to use the program successfully. As I have stated previously, I probably won't ever complete those lesser aspects ... not unless I find I need to for something. I now intend to use my program in earnest, which will test all the major elements, including the FIX COVERS button code. Enjoy!

Latest update now available, see the first post. I did a stack of work today on the program .... then did a stack more. I started off with some improvements that had occurred to me since yesterday, then discovered a couple of bugs, then thought of some more improvements. Then I discovered my Kobo device was almost flat, so a good time to work with it and test a bunch of things. That led to me finding things weren't as good as I wanted them to be, and that I hadn't completed some stuff that needed to be. So implemented a bunch of things and kept testing, and decided I needed to do a few more, and before you knew it most of the day had disappeared. Eventually my Kobo device was fully charged and so kept connecting and disconnecting, so no more testing, though I still had a bunch of things to code and test without needing my device. Latest Changes While not a huge list, it was a lot of work. I'm pretty sure I still need to do more, especially as I haven't looked at the FIX COVERS code again, yet ... not for 10 months at least. I imagine the process still works okay, just needs some additional Log file recording (perhaps). and some visual updating to the list etc, and perhaps some other records. Anyway, I am pleased to say that the many covers created on my Kobo device today, did the job and worked well. Only a few hundred left to do. Those Fuschia colored rows are successful images copied to my Kobo device. Mostly it was three images per each ebook, but sometimes only one was required. If you look back at a previous screenshot, you can see what has changed.

I thought it was time to amend a few things in the first post, so I've done that, and also added a new update to download there. Latest Changes Hopefully my bugfix did not break anything, as it was somewhat elusive to figure out.

Latest update now available, see the first post. Okay, as I was waking today, it suddenly occurred to me that I had missed a very obvious improvement. This was a Dropzone for quick and easy renaming and copying of a cover image file, in preparation for the main usage of my program. So after pondering on how best to do that, with limited GUI space, I did the following ... optionally repurposed the 'Cover Image' preview field. To do that, you need to enable it via a checkbox on the 'Settings' window. So basically I did the following. That means another level of automation, making things quicker and less fiddly etc. Enjoy!