My last successful Backup was made on July 5th. Since then all backups (both scheduled and manual) are failing. The backups are set to be made to a USB SSD attached to my ROCK/NUC system. This drive is 120GB with 62GB used (so plenty of free space for additional backups). The drive is accessible by Roon OS and via Windows File Explorer over the network. Is there a problem with the Roon Database itself that is causing backups to fail?
Hi @Geoff_Coupe,
I think we’ve found the error trace for your backups in RoonServer_log.02
07/17 00:05:51 Warn: [broker/backups] unexpected error doing backup on FileBrowser.Entry: New Volume, ASMT 2115 : /RoonBackups: Sooloos.SynchronizationContextThreadException: In Broker:Media
---> Sooloos.SynchronizationContextThreadException: In Broker:Transport
---> Sooloos.SynchronizationContextThreadException: In Broker:Misc
---> System.OutOfMemoryException: Array dimensions exceeded supported range.
at System.IO.MemoryStream.set_Capacity(Int32 value)
at System.IO.MemoryStream.EnsureCapacity(Int32 value)
at System.IO.MemoryStream.WriteByte(Byte value)
at Sooloos.Broker.BackupCompute.<>c__DisplayClass12_1.<ComputeBackupFiles>b__1(String file, Boolean needs_copy)
at Sooloos.Broker.BackupCompute.<>c__DisplayClass12_1.<ComputeBackupFiles>b__4()
at Sooloos.SynchronizationContextThread.<>c__DisplayClass48_0.<SendSafe>b__0()
--- End of inner exception stack trace ---
at Sooloos.SynchronizationContextThread.SendSafe(Action handler)
at Sooloos.Broker.BackupCompute.<>c__DisplayClass12_1.<ComputeBackupFiles>b__3()
at Sooloos.SynchronizationContextThread.<>c__DisplayClass48_0.<SendSafe>b__0()
--- End of inner exception stack trace ---
at Sooloos.SynchronizationContextThread.SendSafe(Action handler)
at Sooloos.Broker.BackupCompute.<>c__DisplayClass12_1.<ComputeBackupFiles>b__2()
at Sooloos.SynchronizationContextThread.<>c__DisplayClass48_0.<SendSafe>b__0()
--- End of inner exception stack trace ---
at Sooloos.SynchronizationContextThread.SendSafe(Action handler)
at Sooloos.Broker.BackupCompute.<>c__DisplayClass12_0.<ComputeBackupFiles>b__0()
at System.Threading.ExecutionContext.RunFromThreadPoolDispatchLoop(Thread threadPoolThread, ExecutionContext executionContext, ContextCallback callback, Object state)
--- End of stack trace from previous location ---
at System.Threading.Tasks.Task.ExecuteWithThreadLocal(Task& currentTaskSlot, Thread threadPoolThread)
--- End of stack trace from previous location ---
at Sooloos.Broker.BackupCompute.ComputeBackupFiles(List`1 filesinmanifest, List`1 filestoupload, HashSet`1 latesthashes, Canceler canceler)
at Sooloos.Broker.BackupDestination`1.StartBackup(Entry location, Nullable`1 numberofbackupskept, Boolean auto)
I’ll consult with the rest of the team about this error.
Based on previous cases with this error message we think it’s saying that we are trying to create a single array that is just too big, regardless of how much RAM the machine has. In this case it’s probably a single file in the backup structure that is >2gb.
The two solutions suggested by the developers are:
Backup the directory the Roon database is on using some other mechanism outside of Roon
Confirm that you have run clean your library recently.
I will be raising another ticket about this to see if there’s any change we can make on our end.
I’ll make a copy of the database directory (presumably while Roon Server has been stopped?) and store it outside of the ROCK/NUC system.
I think I last cleaned my library about a month ago when I was cleaning up some Qobuz entries that were no longer available. At any rate, the three options are currently showing zero files to be cleaned up.
I had similar problems recently on Linux server when I had the update to add Airplay2. It just would not back it up at all and it was a manifest issue according to support. I ended up switching Roon server to windows restored my last backup. I found three albums that Roon didn’t identify which I found odd as in the current database on Linux they were fine. I removed these albums from Roon. Did a clean up added them back in. Then attempted back up on windows. It worked. Then switched back to my Linux core and restored it. Then backed up again to check. It worked. Been ok since. Support couldn’t tell me exactly what caused it. As these albums in question where not new and been in my library for years.
Just a follow-up here; I got fed up of making manual backups and I think I’ve now got back to a working system.
I reset the database and reimported everything. Once that was complete, I restored the last good backup (from July 5th). That seems to have fixed whatever it was, because Backups are now working again.
Obviously there was a small amount of work to be redone for edits made since July on newly imported albums, but I can live with that.
