I've used it with the half dozen older images of piCorePlayer that were on my machine (burned old .img to SD card, rebooted, loaded insitu.sh over and let it run with target of piCorePlayer1.14.img). So far the only irritation is that squeezelite won't come down with the init.d script. At this point the third partition is overkill at 256M. If this is the way to go, then it may be better to scale it back.
Thanks, I will give it a try. It will be a major advantage to be able to update piCorePlayer in situ.
Will it be easier if I make a special directory on sourceforge called update, where only the newest piCorePlayer version is?
Can there be some kind of check, so that it only tries to update if there is a newer version than what is currently running?
So here is where I think this stands. Steen has a successful and appealing approach for the burn&boot masses (no knowledge required, just burn SD card, boot your RPi and load URL). If anybody grabs an IMG from sourceforge, their machine should boot standalone. Keeps it simple and provides a worst case scenario disaster recovery.
There are those (like myself) that can't lay hands on their RPi to pull the SD and burn&boot. The desire is to provide a means to upgrade a currently running version of piCorePlayer to a new version without touching the physical RPi. Seems to me the approaches break down in to the following:
1) Provide failsafe upgrade - (start known_good handler, backup old image, install new image, if new image fails to load then fallback known_good handler and revert old image)
Where it stands now - ugly berryboot proof of concept works, would be hairy for the masses. Need a better idea (chain boot??)
2) Provide upgrade with revert - (backup old image, install new image, reboot and cross fingers)
Where it stands now - working prototype of insitu.sh here now. Needs revert logic
3) Provide upgrade bare - (install new image, reboot and cross fingers)
Where it stands now - repurpose parts of insitu.sh
4) Rearchitect piCorePlayer - (develop a new image of piCorePlayer with new functionality/design/approach to allow for in place upgrades)
Where it stands now - need to develop and understand requirements
I'm ready to help in whatever direction you want to pursue.
Thanks. I think we should continue (we I said - you have done all the work).
Option 2 would be OK. I was thinking that if we are able to boot after a update and can see squeezelite is running, then everything should be OK - and we could delete the old files. This kind of logic should be rather simple to make.
However, in the worst case scenario we are unable to boot, and then nothing can be done - we will then need to burn the SD-card with a new image? I don't know if this can be handled in any other way, but I doubt it.
Also piCorePlayer would need an overhaul in order to make this happen - but first we need to decide on the mechanism.
PS - on a completely unrelated side note. What in the !@#$@!# do I do to get scp working with putty/dropbear? The old cut/paste a vi session is Neanderthal.
I use putty and WinSCP all the time without any problems?
It complains about saving is not permitted - but it saves the files anyway.
Steen