Forward compatibility on HQPe config files

Audio Gear Talk HQ Player
#1

tagging @jussi_laako

Jussi, What’s your policy on forward compatibility of the files in /etc/hqplayer for embedded?

Reason I ask… I boot embedded from a USB stick. I’ve created a script to copy files and users from the “active” system to a secondary USB stick for the purpose of upgrading HQP embedded. I would like to share this script but not if its going to eventually break someone’s install because a change was made to the format of these files.

Other questions for you if you could please answer:

  1. Is there a file or other way on the filesystem to determine version? I’ve only found the version is part of the /about web server which requires a running system to find the version.

  2. For the files in /etc/hqplayer… if you published the schema for the various files I could, possibly, validate the old config against the new schema and bomb out of my script before putting incompatible config in place.

Thank you sir and have an excellent day.

1 Like
#2

How much different are these from the already existing backup/restore scripts? (4.34.1 have still some migration issues to be fixed in next release)

The format itself is supposed to be forward compatible. Also backward compatible, but if you go backwards, and the new configuration for example refers to a filter that doesn’t exist in the old version, then HQPlayer will pick default filter until the config is updated.

For some version changes, HQPlayer has built-in conversion code from old config to a new one. For example when HQPlayer v3 was upgraded to HQPlayer v4, the configuration files changed and there’s a conversion for this case.

I don’t have any schema written for the XML’s.

#3

Do note I boot from USB stick and my HPQe machine has no drives.

My process is basically:

  1. Etch new embedded image on USB stick
  2. Plug USB stick into active HQPe machine
  3. Login (ssh) and run script
  4. Reboot machine
  5. Pull old USB stick out of machine while reboot occurs
  6. Machine boots new HQPe, at correct address, with all config in place including my ssh user(s).

My script at step 3 (written in bash) handles copying over users and their directories (needed for ssh), groups, the HQPe config files including license and hqplayer web password, and network config (I use a static address).

I’m happy to share privately but my hacky “code” I don’t feel comfortable publishing here.

Anyway, this is faster than the current backup / restore unless you’ve got some backup / restore which handles users and network and can be exploded onto a USB stick so first boot is “ready to go”.

#4

You can also replace the existing backup/restore scripts if you like to access it from HQPlayer web interface. Since HQPlayer Embedded is designed with hardware manufacturers in mind, there’s some extra flexibility.

Now in latest version, for example SMB mounts move over with the backups. But I need to fix the file ownership issues, especially when restoring from previous versions where the files were owned by different user id.

#5

oh, that maybe a good idea. Although, I prefer the command line.

ok, I’ll share my ugly “code” for moving users with you.

Edit:
Code removed so you don't use it and break things.
#6

ohhh… and this question…

Is there a file or other way on the filesystem to determine version? I’ve only found the version is part of the /about web server which requires a running system to find the version.

#7

This part breaks the OS for example between 4.34.0 and 4.34.1. So it would be better to do it with sed or similar to selectively move over only the created user id’s. For example on the 4.34.1 restore script I only pick the smb mount entry to move over to target fstab.

Not at the moment. I can think about how to add some file somewhere to state this. I would prefer it to be automatic from the build system, so I need to do some testing to figure this out.

#8

That’s pretty straightforward and a good suggestion. I wasn’t happy with blatantly overwriting these files anyway. Thanks

I have only tested this with 4.33 → 4.34

Have not had time to upgrade to 34.1 yet. But… its now on my list and I’ll make updating the script part of that work.

I don’t use SMB mounts as I’m Roon → HQP always. However, you bring up a good point that I should copy over SMB mounts so others can use this script. I need to set that up to test. I also don’t grab things like convolution filters because I don’t use that either. <sigh> Now this just became a bigger project :slight_smile: oh well, it’s forcing me to dust off my worthless bash skills.

1 Like