Official moOde 8 support thread

[UpsiUps]

I hate the Major version upgrades as I have to walk and find all my RPis in the house, plug th eSD card , burn a new one , plug the new one in and restart configuration ... Oh, last point has a significant improvement : backup and restore !

Excellent! and even a possibility to run my own restore script - more excellent !

I all mention that as there seems a small bug, that I have been faced during my upgrade procedure: I unwraped all backup-zips to grab the unique moodecfg.ini and throw them on the /boot partition. That worked very well and the players came up even with the NAS connected per NFS. I then restored using the zip file the rest.
... and then I had a duplication of my NAS Library as Library source. So it seems that restore adds the library regardless if this is already connected.

Workaround ist fast: just deleted the latest entry of the list. But maybe you want to proof, why the duplication is happening.

The Restore handles copying moodecfg.ini to /boot. You don't have to do it manually.

Not really: If you don't change the moodecfg.ini the system might get no IP and the hostname will be wrong. if you boot up multiple RPis you have the fun to find them on your local network.Only after that you could start the restore to fix things. So -IMHO- I think the sequence is better it is better to copy the moodecfg.ini before you boot up the first time. After that you start the restore to re-create your local radiostation etc.

The restore will also find the configuration moodecfg.ini and will restore it a second time. That should not be a problem. The only observation is, that the source entry was now duplicated. 

Maybe I missunderstood the restore process: is there a way to start the restore on a fresh image ? E.g. by store the backup...zip on the /boot partition ? I am currently only aware to start the restore after mood has started and you could use the browser UI to upload the backup.zip file.

In generic it is not a big issue. I would like to thank you that the major upgrade process is nowadays much easier than in the 5.x and less releases.

- Update - 
I reviewed the source and found the challenge :

Code:

.... line 188 of backupmanager.py ...      
if configPresent:
  print('config')
  content.append('config')

That's the reason, why the Source/Library entry is duplicated. Now, if I want to "restore" , why would i like to append it to the current moodecfg.ini ?  I would rather think I would like to overwrite the moodecfg.ini even if it is in place, nor ?

[Tim Curtis]

Right, the fresh image scenario needs moodecfg.ini in /boot.

Good points. I'll add to the TODO list to investigate.

-Tim

[Mr.R0b0t]

Any solution to my problem?

[Tim Curtis]

Any solution to my problem?

I wasn't able to repro it 
https://moodeaudio.org/forum/showthread....9#pid40189

But the log records below from your post #88 suggests that there is some sort of odd sample rate changes and buffer underruns happening.
https://moodeaudio.org/forum/showthread....8#pid40228

Code:

Mar 15 17:04:39.235 WARN sample rate change detected, last rate was 1087.3985895103685 Hz, module: camillalib::filedevice
Mar 15 17:04:39.244 WARN Prepare playback after buffer underrun, module: camillalib::alsadevice
Mar 15 17:04:40.301 WARN sample rate change detected, last rate was 61479.46345625691 Hz, module: camillalib::filedevice
Mar 15 17:04 : alsa_output: Decoder is too slow; playing silence to avoid xrun
CDSP Plugin ERROR: XRUN OCCURRED!

Mar 15 17:13 : alsa_output: Underrun on ALSA device "_audioout"
CDSP Plugin ERROR: XRUN OCCURRED!
Mar 15 17:13 : alsa_output: Underrun on ALSA device "_audioout"
CDSP Plugin ERROR: XRUN OCCURRED!
Mar 15 17:13 : alsa_output: Underrun on ALSA device "_audioout"
CDSP Plugin ERROR: XRUN OCCURRED!
Mar 15 17:13 : client: [6] process command "status"
Mar 15 17:13 : client: [6] command returned 0
Mar 15 17:13 : client: [6] process command "currentsong"
Mar 15 17:13 : client: [6] command returned 0
Mar 15 17:13 : client: [6] process command "playlistinfo "25""
Mar 15 17:13 : client: [6] command returned 0
Mar 15 17:13 : alsa_output: Underrun on ALSA device "_audioout"
CDSP Plugin ERROR: XRUN OCCURRED!

camilla error no sound after 3 sec

To troubleshoot try a fresh image on a bare Pi (No HAT board) with just Camilla turned on and set to whatever config  file you were using on the Pi thats producing the errors. Put some audio files on a USB drive or the SDCard and use these to test with. We don't want any NAS, UPnP or any other renderers turned on. No local display etc, etc. 

The test system needs to be as basic as possible so that in the event the issue occurs a repro might be possible.

[bitlab]

Code:

.... line 188 of backupmanager.py ...      
if configPresent:
  print('config')
  content.append('config')

That's the reason, why the Source/Library entry is duplicated. Now, if I want to "restore" , why would i like to append it to the current moodecfg.ini ?  I would rather think I would like to overwrite the moodecfg.ini even if it is in place, nor ?

That piece of code is just fine. That few lines just detect what is present in a backup file.
The only thing that is missing is that on restore first the already present source should be removed to allow multiple time restore of the ini.

But there is a much simpler workflow available: instead of the moodecfg.ini place the backup file renamed to moodebackup.zip in the boot partition.

[Tim Curtis]

Code:

.... line 188 of backupmanager.py ...      
if configPresent:
  print('config')
  content.append('config')

That's the reason, why the Source/Library entry is duplicated. Now, if I want to "restore" , why would i like to append it to the current moodecfg.ini ?  I would rather think I would like to overwrite the moodecfg.ini even if it is in place, nor ?

That piece of code is just fine. That few lines just detect what is present in a backup file.
The only thing that is missing is that on restore first the already present source should be removed to allow multiple time restore of the ini.

But there is a much simpler workflow available: instead of the moodecfg.ini place the backup file renamed to moodebackup.zip in the boot partition.

I forgot about that nice feature :-) 

The r801 sources are frozen but I'll plan to add documentation and improved help text for Backup/Restore in a post r801 release.

[UpsiUps]

Code:

.... line 188 of backupmanager.py ...      
if configPresent:
  print('config')
  content.append('config')

That's the reason, why the Source/Library entry is duplicated. Now, if I want to "restore" , why would i like to append it to the current moodecfg.ini ?  I would rather think I would like to overwrite the moodecfg.ini even if it is in place, nor ?

That piece of code is just fine. That few lines just detect what is present in a backup file.
The only thing that is missing is that on restore first the already present source should be removed to allow multiple time restore of the ini.

But there is a much simpler workflow available: instead of the moodecfg.ini place the backup file renamed to moodebackup.zip in the boot partition.

I think the "content.append()"is the "problem", as it will not overwrite if a config is present. Anyhow, I was not aware about that moodebackup.zip feature. That is exactly what I thought to prevent and do the restore. Will it also execute the optional script you put into the backup ?

[UpsiUps]

Code:

.... line 188 of backupmanager.py ...      
if configPresent:
  print('config')
  content.append('config')

That's the reason, why the Source/Library entry is duplicated. Now, if I want to "restore" , why would i like to append it to the current moodecfg.ini ?  I would rather think I would like to overwrite the moodecfg.ini even if it is in place, nor ?

That piece of code is just fine. That few lines just detect what is present in a backup file.
The only thing that is missing is that on restore first the already present source should be removed to allow multiple time restore of the ini.

But there is a much simpler workflow available: instead of the moodecfg.ini place the backup file renamed to moodebackup.zip in the boot partition.

I forgot about that nice feature :-) 

The r801 sources are frozen but I'll plan to add documentation and improved help text for Backup/Restore in a post r801 release.

 Yes, I think the hint to the moodebackup.zip in /boot will solve the challenge . Hopefully only needed for Version r9.0  
ok, also for a damaged SD under r8.x....

[bitlab]

Code:

.... line 188 of backupmanager.py ...      
if configPresent:
  print('config')
  content.append('config')

That's the reason, why the Source/Library entry is duplicated. Now, if I want to "restore" , why would i like to append it to the current moodecfg.ini ?  I would rather think I would like to overwrite the moodecfg.ini even if it is in place, nor ?

That piece of code is just fine. That few lines just detect what is present in a backup file.
The only thing that is missing is that on restore first the already present source should be removed to allow multiple time restore of the ini.

But there is a much simpler workflow available: instead of the moodecfg.ini place the backup file renamed to moodebackup.zip in the boot partition.

I think the "content.append()"is the "problem", as it will not overwrite if a config is present. Anyhow, I was not aware about that moodebackup.zip feature. That is exactly what I thought to prevent and do the restore. Will it also execute the optional script you put into the backup ?

Again that isn't the actual problem. The part of the code you mention, is part of a function that checks what is inside a backup and returns an array like ['config', 'r_moode']. 
The way you suggest fixing is just 'fixing' the backup content detector by 'saying' the backup never contains a moodecfg.ini, this will break:

• You will be never be able again to do a config restore from the web interface. 
  
• Not possiblle to inspect backup with the tooling.
  
• Directly restore on boot from a backup zip will also no work anymore.
  

The real problem is that restore itselfs has a problem with erasing the existing sources before restoring the sources backup. Which results in double sources when a restore is performed twice.

After quick checking it looks the optional script is not restored and executed from a backup, which is a bug. Will put it on the todo list.
For now the workarround is to place the script from backup also in the /boot part. When the backup is restored it will pickup the script and execute it.

[Malefoda]

8.0.1 with 7.6.1 backed up settings applied is now working flawlessly. Screen rotation glitch on my Nexus 10 is now gone. Seems my RPi 2B is fine, maybe (as an expected bias than one day the RPi 2B will struggle with heavier software...) I find than some covers show up not as fast as in 7.6.1.
And I wonder If the "m" and "Settings" menus transparency can be removed for good old solid menu... I guess it wasn't there on 7.6.1, was it?