Rockbox General > Rockbox General Discussion
Windows Batch Script for Updating to Latest Rockbox Build
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:
--- Quote from: Llorean on April 30, 2010, 03:30:53 AM ---I'm curious, why all this effort? What lacking functionality of RBUtil is this to address?
--- End quote ---
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:
--- Quote from: Llorean on April 30, 2010, 04:20:34 AM ---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).
--- End quote ---
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:
--- Quote from: Shiftlock on April 30, 2010, 04:36:22 AM ---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.
--- End quote ---
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! :-)
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version