After my initial post on checking out the migration scripts, I've done some more extensive running, and here is a summary of the things I've found. This work involved quite a lot of shuffling between different versions of the offering on my small supply of SD cards, so if I've made errors along the way, apologies in advance!
Thomas has put a major effort into this, and what's there is good. There are a few hiccups - see summary at the end - but they are easily bypassed.
Many thanks Thomas.
I'm using LMS running on a QNAP NAS, with a headless 512MB Pi (access via Putty). I'm using 8GB Class 10 SD cards for the file system. I'm also using the analog output for sound, although I realise that the quality isn't as good as from digital outputs. For testing, I'm driving the sound through a couple of PC speakers. Not optimal, but it's a reasonable comparative environment for what I've been doing, at least.
First, I ran the Squeezeplug 6 Hard Float (HF) and Soft Float (SF) versions as a baseline. Here's what I found.
1) HF version installs fine, runs Squeezeslave OK. SF version also installs OK, but attempts to install Squeezeslave when requested and reports success. Code and scripts are installed, but when attempting to run at boot, there are errors reported, and Squeezeslave will not run. Squeezelite does run on the SF version, of course.
Now for the migration testing
1) The migration script will install Squeezeplug (SP) additions on top of a base of Raspbian HF or Debian SF Wheezy. The migration script also invokes an update of the base code, if required.
2) I installed HF first. I downloaded and used the vanilla Raspbian. The download of the script and Squeezeplug (SP) code base worked fine and started up OK. After choosing hard or soft float option (I wonder whether this could be automated - Thomas?) the script started to download loads of updates to the base and after installing them booted itself into SP. At this point there is a small difference to the V6 initial boot, as the splash screen (on Putty) tells you that you have 20 seconds to enlarge it rather than giving no time interval (good stuff). After this initial script you are into SP as you expect it. I installed Squeezeslave (SS) and rebooted. On rebooting, I noticed that the player picked up an old name I had used for SP V6 SF vanilla testing. No big deal. This can all be changed from the browser into LMS.
3) Next I tried out the SF code base (Debian Wheezy). Again, the script went fine, but there were loads of updates and some of them failed to download correctly from the Pi site. The base code update also reported running out of space on device at some stage. I hadn't expanded the file system at this point. The script still reported successful completion and booted into SP, at which time I could install SS and Squeezelite (SL). Each reported successful installation, though SS didn't work (as I thought it might not). SL did.
4) Some of the panels in the SP menus do not display the information for sound cards coming the panel before the choice. Also, the script seemed to have problems locating my LMS (not the case on the HF system, I recall). Selecting auto find failed, so I had to redo the config and type in the address.
5) After the problems downloading all the updates (and the script apparently completing successfully) I manually updated (apt-get...) to see what difference that would make. This time (perhaps due to networking or load issues on the update servers?) the updates downloaded and installed fine. I had expanded the file system by this time.
I did go back and try out the SPV5 version of the code, as all the SPV6 offerings (vanilla and migration releases) seemed, through the analog ports at least, to generate a fair amount of background noise. Certainly SPV5 was quieter. When running SPV6, doing things on the LMS browser, through which I was managing the player, made odd sounds through the speakers. This certainly suggests use of digital outputs for production use.
a) The migration scripts work well, especially if the user takes care to ensure that his system is up-to-date before he starts the migration process. The positive message from the script when the update hasn't worked should be corrected, or a simple change made so that the script prompts users to manually make an update before migrating. The "out of space" issue may not occur if the system update is separated from the SP migration. And, if updates are done after, the SP panels/scripts can be used to expand the file system.
b) Squeezeslave doesn't work on the SF version of the code (vanilla or migration offerings) and could be removed from the choices, unless there is a SF version of the code. I don't know about this.
c) There are some issues on the SF scripts detecting LMS running, it seems. Perhaps just need to tell users to type the address in. Some small changes to the English prompts might help. The V6 scripts don't have stand-alone and integrated with LMS (as was the case in V5) paths for Squeezeslave installation. This is fine but perhaps needs to be more clearly supported in the prompt.
d) Overall, the system runs well, and after a couple of minor adjustments will be another major addition to the SQ offerings.
Many thanks Thomas.