MiSTer updater script

[NML32]

Can the script be made to update USB storage?

[Locutus73]

Can the script be made to update USB storage?

Which is the structure of the directories/files on the USB?
I think that editing BASE_PATH="/media/fat" variable could be the solution, even if this would break the Linux system update, but it's disabled by default. I think that I'll release a secondary, easy to edit script, but, in the meantime, please tell me if BASE_PATH variable solves the issue.

Thank you.
Best regards.

Locutus73

[NML32]

Can the script be made to update USB storage?

Which is the structure of the directories/files on the USB?
I think that editing BASE_PATH="/media/fat" variable could be the solution, even if this would break the Linux system update, but it's disabled by default. I think that I'll release a secondary, easy to edit script, but, in the meantime, please tell me if BASE_PATH variable solves the issue.

Thank you.
Best regards.

Locutus73

Thanks, I’ll give that a try when I get home.

Update: I updated path to BASE_PATH="/media/usb0" and it didn't work. I wonder if it has to do with MiSTer booting from SD card and switching to USB?

[uigiflip]

could the output of this script be made shorter to fit in the scripts menu output screen better?

[Locutus73]

could the output of this script be made shorter to fit in the scripts menu output screen better?

It must be shortened along with other implementations... next release.

Regards.

Locutus73

[Locutus73]

Update: I updated path to BASE_PATH="/media/usb0" and it didn't work. I wonder if it has to do with MiSTer booting from SD card and switching to USB?

Thank you for the debug session!
I think the culprit is script_pipe=popen(getFullPath(SelectedPath), "r"); in menu.cpp with getFullPath(SelectedPath) returning the full script path only when using the SD... I'll take a look at that.
Good catch, thank you again.

Regards.
Locutus73

[Locutus73]

Hi @Sorgelig , I don't mean to bother you, but what do you think about the idea of a short update.sh script I expressed here?
http://www.atari-forum.com/viewtopic.ph ... 25#p361331

I think it has the benefits of your ini file idea, plus it is a single file which can be duplicated many times with different settings and it always runs the last version of the actual updater code.
If you like this idea, I would proceed with it.

Thank you in advance.
Best regards.

Locutus73

[Sorgelig]

Hi @Sorgelig , I don't mean to bother you, but what do you think about the idea of a short update.sh script I expressed here?
viewtopic.php?f=117&t=34898&start=25#p361331

So you want to make a virus like script?
I think at some point there won't be updates to the script long time when all bugs will be fixed and features implemented. Download it with every run - not sure if it's really needed.
But it's up to you.

[Simongordon]

would be really nice to have some options...
- just update whats there
- update and download new cores
- ask core by core if you want new core

[Locutus73]

would be really nice to have some options...
- just update whats there

This option is coming.

- update and download new cores

Obviously this is the same option above with a false value

- ask core by core if you want new core

this would work just with SSH, not in the Script menu, unless implementing some input processing function which isn’t impossible, but I don’t know if it’s worth the hassle.

Regards.
Locutus73

[Lodovic]

Locutus73,

Thank you for your script. This is a real timesaver and keeping Mister up to date is now much easier. The Mister updates are numerous (thanks to Sorgelig and all the devs) and this is now so simple to grab the latest cores.

[SmokeMonster]

This is pretty incredible. Nice work on the script Locutus, and thanks for the scripts menu, Sorge

[Sorgelig]

I don't think it worth to have question on each core. As amount of cores close to 100, you won't like to have so many questions.

May be if Locutus73 will like then script may check for variable having either word "All" or list (delimited by space for example) of cores.

What i would like to see is option to remove datecode from the name upon update.

[Sorgelig]

What may be worth to think is download new(or absent) cores into separate folder like "New".
In this case most users won't need to create their own lists of cores to update and new cores won't appear by themselves in the main folder.
New cores usually require some additional operations like creating new folder and add some games or bios roms. So, user will copy the core from New folder by himself if he would like. Otherwise can keep it there, so it won't clutter the main list.

[Locutus73]

New version released:
Version 1.3.5 - 2018.12.22 - Solved Atari 800XL/5200 and SharpMZ issues; replaced "reboot" with "reboot now"; shortened some of the script outputs.
Version 1.3.4 - 2018.12.22 - Shortened most of the script outputs in order to make them more friendly to the new MiSTer Script menu OSD; simplified missing directories creation (thanks frederic-mahe).
https://github.com/MiSTer-devel/Updater_script_MiSTer

@esmith13 sorry man, at first I misunderstood your Atari 800XL/5200 reporting, you were right and I was wrong; now the issue is fixed.

Regards.
Locutus73

[Locutus73]

Regarding all the interesting ideas: for sure I will implement next a simple option like UPDATE_ONLY_INSTALLED_CORES=true/false that, if set to true, will update only cores on the SD, while if false will update/download all core like now.
Then there is much room of improvement to this simple implementation, let's see the different ideas.
- Variable set with "ALL" or a list of cores: I don't know, it can work, but I don't know if users would like editing the list for adding a new core... maybe.
- Directory called "NEW" for new cores when users don't want to automatically see new cores... why not? It's not a bad idea... should I treat the NEW directory like a secondary target directory with the scan for files and update routine? Consider that I will implement a log file too, so users could use that as a reference for knowing if there are new cores.
- Removing timecode option: it can be done but it needs some code refactoring because I use the local file timecode as a reference for determining if the core must be updated or not; i.e. for menu.rbf I keep both the timecoded file and the menu.rbf file. It's an option we should consider, but do users dislike the timecode? I mean, let's consider together if it's worth the hassle.

Please consider all this considerations just like me thinking out loud, I mean, they are not definitive, please debate them and share ideas.

Many thanks in advance.
Best regards.

Locutus73

[Locutus73]

The more I think about it, the more the "NEW_CORES" directory idea grows on me...

Locutus73

[Sorgelig]

I can add an option to not display datecode.

[Locutus73]

I can add an option to not display datecode.

Yeah, that too, but that should be an option; I mean, datecode is very useful for letting users reporting bugs/issues knowing what core build they are actually using.

Speaking of not displaying stuff... why don't you hide "System Volume Information" with the SCANO_DIR option?

And while we are at it, can you suggest something better than getFullPath(SelectedPath) for getting the full path of the selected script? I have to better investigate that, but I suspect that it's causing problems when users use an USB drive and choose a script from there.

Thank you in advance.
Regards.

Locutus73

[Sorgelig]

can you suggest something better than getFullPath(SelectedPath) for getting the full path of the selected script? I have to better investigate that, but I suspect that it's causing problems when users use an USB drive and choose a script from there.

this is correct way to get the full path.
USB is mounted to other folder than SD card. So your script should distinguish where it ran from.
I think the best way is to query the full path from inside the script using standard shell commands. If it run from USB, then update the USB only.

[Locutus73]

can you suggest something better than getFullPath(SelectedPath) for getting the full path of the selected script? I have to better investigate that, but I suspect that it's causing problems when users use an USB drive and choose a script from there.

this is correct way to get the full path.
USB is mounted to other folder than SD card. So your script should distinguish where it ran from.
I think the best way is to query the full path from inside the script using standard shell commands. If it run from USB, then update the USB only.

Probably I didn't express myself correctly, the problem isn't inside scripts, the problem is that the instruction script_pipe=popen(getFullPath(SelectedPath), "r"); seems to not finding the script when using USB so nothing is executed. I say "seems" because I didn't make some serious debug yet.

Regards.
Locutus73

[Sorgelig]

Well, it's possible there is a bug. But it's not FPGA related, so you can debug it yourself. I'm busy by other things.

[Locutus73]

Well, it's possible there is a bug. But it's not FPGA related, so you can debug it yourself. I'm busy by other things.

Sure, I’ll take a look.

Thanks
Locutus73

[Locutus73]

New updater release:
Version 1.3.6 - 2018.12.24 - Improved local file name parsing so that the script deletes and updates NES_20181113.rbf, but not NES_20181113_NN.rbf.
It doesn't delete nearest neighbour or whatever version with some string after the timestamp.

https://github.com/MiSTer-devel/Updater_script_MiSTer

Regards.
Locutus73

[Lodovic]

Hi Locutus73!

Now that we can use the script menu in the OSD, I think I will use your one-line command update trick to create a script file that will always download and use your latest updater. Since I use the default options, is this a safe way to launch the updater? Can the OSD menu launch a script that launch another script without problems?

Thanks.