Windows Batch Script for Updating to Latest Rockbox Build

[Shiftlock]

Question: The only DAP I've installed Rockbox on is the Sansa Fuze V1 and V2.  Is the process of installing a new compiled build the same on other players (i.e. copy the .rockbox folder)?

yes.

Great, then this script should work with any player.  I would like to make it auto-detect the type of player.  In the .rockbox\rockbox-info.txt file, my V1 Fuze says:

Target: sansafuze
Target id: 53
Target define: -DSANSA_FUZE

And my V2 Fuze says:

Target: sansafuzev2
Target id: 68
Target define: -DSANSA_FUZEV2

Does anybody know where I can get a list of "Target" information for all DAP models that have Rockbox builds?

[bluebrother]

Does anybody know where I can get a list of "Target" information for all DAP models that have Rockbox builds?

As (indirectly) said earlier, check out how Rockbox Utility handles things: http://svn.rockbox.org/viewvc.cgi/trunk/rbutil/rbutilqt/rbutil.ini?view=markup
Basically, the "Target" line holds the unique target name that is also used for download file names. Note this line in the file I've linked above:

Code: [Select]

http://build.rockbox.org/data/rockbox-%MODEL%.zip

[Shiftlock]

Well, I think I've finished this script.  Nothing needs to be manually changed or modified, just run the batch file and it will update any player that already has Rockbox installed to the current build (not the stable release build, but the current build with the latest changes that is updated daily).

The script will now determine the model of player, and download/install the correct build.  It will also determine the drive letter of your player.  It will check your system for the needed supporting programs (unzip and BITSAdmin download utility) and if they're not on your system, it will help you download/install them.  It will display download progress, as well as the old version on your player and the new version it's installing.

I edited the original post in this thread to reflect the changes, new code, as well as the URL to download the script if you prefer to get it that way.  If anybody tries it, I would be interested to hear how it works for you.

[Llorean]

I'm curious, why all this effort? What lacking functionality of RBUtil is this to address?

[fml2]

I don't like the fact that the script (IIUC) creates some folders on the computer.

But the main question, as Llorean said, is: why would you need it? RBUtility already does it, and has some advantages:

• it's "official" and well supported and maintained
• you can choose what player to update (the script updates the first player it finds IIUC)

The good feature of the script is that it can run unattended. I think we could/should add some command line switches to RBUtility so that it can do that too.

[Llorean]

There's been some effort toward a console interface for RBUtil as it is, since it can also be easier for some blind users to use.

[Shiftlock]

I'm curious, why all this effort? What lacking functionality of RBUtil is this to address?

The main reason was because I wanted something I could run as a scheduled task, so I needed a program that would update the player with no user input.  Also, I have more than one player, so I wanted something that would detect which one is currently plugged into the computer.  Actually, I'm using a slightly different version of the script that scans for multiple drive letters/models, and updates all the players plugged into the computer with the proper build.  It does this with a single click (or a single execution from the Task Manager).  With RBUtil, I had to manually go through and change the settings to update each player, which was rather time consuming with six different players to update, and there was no way to schedule an update for even a single player from the Task Manager.  Now I can just plug them all in at night, and I know they'll always have the current build.

Someone mentioned the visually impaired, which is another potential use.

Regarding the script creating a directory, well, where was it supposed to download the file to without creating a directory?  I could have made it use the default Windows temp directory, but I figured it was better if it worked under its own directory where all the activity could be monitored.  The directory it creates is under the default %programfiles% directory, where most software packages install themselves and work.

I guess what it comes down to is that, once setup, it's just easier to use than RBUtil.  If RBUtil had command-line switches so that I could set it to automatically run the way I wanted, then close, that would be ideal.

[Llorean]

Just as a note - the current build is updated multiple times a day (any time the source code changes) and blindly updating to a development build can also leave you with an unusable player throughout the day.

But fml2 is basically right - most of this could've been accomplished by improving RBUtil (and a lot of this is in areas we'd like to see it improved in, I think).

[Shiftlock]

But fml2 is basically right - most of this could've been accomplished by improving RBUtil (and a lot of this is in areas we'd like to see it improved in, I think).

Agreed.  But I'm no programmer, and Windows Batch already stretches the limit of my knowledge and ability.

There's one more thing about this script that I find useful, which is kind of hard to explain, but I'll try.  The script will unzip the .rockbox directory to the same location on my harddrive as the old .rockbox directory, without deleting any files that it doesn't overwrite.  That way, when I copy the .rockbox directory to the player, it will install the new version along with any config files that were saved under the .rockbox directory on the hard drive.  One of my players is a Fuze V2, which does not yet have write support, so this way I can install the new build along with all of my settings.

Similarly, I can update all four of my Fuze V1 players with exactly the same settings by copying the .rockbox directory tree with the config files in it to all of my players.  This was the other reason for the script creating a directory, where the .rockbox directory tree(s) could live on the hard drive with the config files in them.

This may be an obscure benefit that only I would find useful, but I do.  Granted, the code I posted doesn't do this, because I didn't think anyone else would want to use it that way, but simply removing the line that deletes the .rockbox directory on the hard drive would do it. 

I hope that was comprehensible.  Sorry if it wasn't.

Regarding the current build leaving the player unusable, well, that's always a possibility when you install a development build.  It a risk I'm willing to take in order to test the firmware with the latest features and fixes on my players.  If the function of my players was critical to me, I would definitely run the stable release build.  That said, I haven't found a current build yet that has prevented my players from working exactly the way I want them to.


Edit:  I forgot one more benefit over RBUtil, which is one of the main reasons that prompted me to make this script in the first place.  RBUtil won't work with my Fuze V2, because it's categorized as "unusable" and not yet supported.  This script will work with any model that has a current build, no matter what its status.

[fml2]

Edit:  I forgot one more benefit over RBUtil, which is one of the main reasons that prompted me to make this script in the first place.  RBUtil won't work with my Fuze V2, because it's categorized as "unusable" and not yet supported.  This script will work with any model that has a current build, no matter what its status.

Ok, that's a killer argument!

But apart from all other things: I think a batch mode would be a very nice feature for RBUtil. I'd do it like this: create small "profiles" and specify them on the command line. Each profile specifies what player to update, with what version (current/release) etc., and is "interpreted" by the RBUtil. There could also be other parameters which are not contained in a profile, e.g. "continue with further profiles even if one profile fails" etc. Then updating Rockbox would be a matter of one mouse click. Now it's a matter of three or four! :-)

[bluebrother]

I forgot one more benefit over RBUtil, which is one of the main reasons that prompted me to make this script in the first place.  RBUtil won't work with my Fuze V2, because it's categorized as "unusable" and not yet supported.

Just for the record, adding a new player to Rockbox Utility is pretty simple as long as either no new method for installing the bootloader is required or bootloader installation isn't of interest. For example, the Gigabeat S is supported by Rockbox Utility (though as "disabled" target), but bootloader installation hasn't been implemented (hence the "disabled" classification). For adding a new target that way you basically only need to edit rbutil.ini and recompile.