Rockbox

Is the intention of this patch to create a directory with the md5 hashes of the files in a text file, or to add the md5 to each files tags??
Can you update whether this patch is working correctly?

I will reply you here.

1. This patch was written in december 2007 so it will be totally out of sync with current svn, but as i have plenty of time at this weekend i will sync it this weekend.
2. It has actually somewhat of 2 modes, if i remember correctly, it is possible to generate a file containing the md5 hash for every file in the directory. Or you can just check the md5 hash of a specific file which will be shown in the properties plugin and i think there is also an extra menu entry for this.
3. The patch always worked, what i meant with "It seems I touched some spaces in code parts which are not relevant" was that my editor removed some trailing spaces or inserted some at places i never edited.

As I said i will sync the patch with the current svn revision this weekend and than you can test it and give me more feedback.

Ok here is the resynced patch, I got also rid of the whitespace changes.

Thanks for your help Rene, but I am having some problems applying the patch to my source, which is r17576 (I didnt think things will have changed much from r17565). No matter whether I place the patch in the source root (c:\rockbox\home\guest\rockbox_v17576) or the source apps folder, I keep getting the error "Cant find file to patch at input of line 5", and then a couple of lines later, the question "File to patch:". If I point to tagtree.c, I then get a hunk error. I've tried to alter the p0 switch up to 2, but that hasnt helped. I should warn you that this is my first attempt at applying a patch so I'm a relative novice, but any assistance would be greatly appreciated.
I will try to get source r17565 to try as well, once I find it.

There has been progress Rene, and I have worked out most of my problems (such as pointing to the wrong files for patching!!). I have applied most of the patch successfully to source ver 17564, except for hunk 2 of plugin.h failed at 121, as plugin.h.rej shows below:

***************
*** 120,126 ****
#define PLUGIN_MAGIC 0x526F634B /* RocK */

/* increase this every time the api struct changes */
- #define PLUGIN_API_VERSION 115

/* update this to latest version if a change to the api struct breaks
backwards compatibility (and please take the opportunity to sort in any
--- 121,127 ----
#define PLUGIN_MAGIC 0x526F634B /* RocK */

/* increase this every time the api struct changes */
+ #define PLUGIN_API_VERSION 116

/* update this to latest version if a change to the api struct breaks
backwards compatibility (and please take the opportunity to sort in any

Any advice you might have in fixing this would be appreciated Rene, such as where I can download ver 17565 of the source.
Thanks

Tony

nice that you solved most of the problems on your own.

I don't know why this junk failed, actually it shouldn't, but its easy to solve, just open the plugin.h file it's in apps/.
Search for the line with PLUGIN_API_VERSION and increment the number by 1, it should than read 116 for now. This could change a lot, because the plugin api version gets increment everytime the the plugin api is changed, or a new function was added.

After you have done that, you can delete the .rej and .orig file, just to keep your source directory clean.

If you are using svn and not the zipped source, you can easily check out a specific revision of the source with the -r option for checkout or update.
Here is a short overview for working with svn http://www.rockbox.org/twiki/bin/view/Main/UsingSVN .
If you have a lot of patches and have some time to learn new stuff, i would recommend you to try git with the rockbox source, it's a bit more demanding but works very good if you know how :)
http://www.rockbox.org/twiki/bin/view/Main/GitVersionControl

Thanks for the assistance Rene. As it turns out, if I modify the PLUGIN_API_VERSION number, the compile then fails, whereas if I leave it at the default for the 17564 version of the source (which is 14), the patched source compiles, and works well (even though there is the 'hunk failed' error while patching). So I now have both the extra context menu in the file browser for generating an md5 list for the files, as well as the extra field in the properties dialog, showing the md5 of the file...fantastic.

I'll continue testing the patch on my X5, with some larger files, and let you know if I discover any issues.

Thanks for making the patch, and then all the help you've given me in getting it working. Hopefully this patch will be incorporated into the svn at some point, to save you the hassle of re-syncing with the latest source, whenever someone like me comes along :-)

I think you changed some different numer, but not the PLUGIN_API_VERSION, because that number can't be 14 right now.
but anyway as long as it works for you its alright.

I think in future versions of the patch I will let the PLUGIN_API_VERSION untouched, because this will only lead to conflicting merges. And as long as the patch applier doesn't forget to copy all .rock files to his player everything should work.

have fun with it.

Having done some testing with large 15 minute PCM files, I will make one further comment, for anyone else wanting to play with this patch. Please note that this is not a criticism, as writing things like this is well beyond my tiny brain, just an observation that I made, that others may find informative.

The added Context menu in the Files menu, (for creating a text file with md5 checksums for each file in a directory), works beautifully. If you are creating large files, as I do, then it can take a few minutes for the processor in the player to do the calculations, but they are then stored in the text file, so its a 'run once' type operation.

However, when viewing the 'Properties' of any file, the md5 checksum is recalculated each time the command is invoked, and is displayed as the last line in the Properties dialog. Once again, this can take up to 1 minute on my X5, from the time I invoke the 'Properties' command, to the time the properties for the file are displayed, during which time, the screen only has the background showing.

Because of the large files I use, I found that I preferred to have just the md5sums text file option, so I edited the patch to remove the creation of the md5s from the Properties dialog, which thanks to Renes patch was fairly easy to work out. So I now have the md5 text file option, and a fast display of file properties.

Thanks again for everthing Rene, I've learnt a lot from you.

Tony

Yes thats a problem, that it can take really long to generate the checksum.
In a first version I had it done via an extra menu entry, to show checksums for a single file, but than i thought it would be nicer to have it in the properties plugin.
But when I'm reading your comment it might actually a better idea remove it from the properties plugin and redo the menu entry for a single file.
It would make it also easier for future patching because i wouldn't need to export the md5 functions to the plugins.

Here is a new patch, which removes the md5 generation from the properties plugin.
It adds a new menu entry for showing the md5 for a single file.