[Discussion] TOS 7 Firmware Update Redirects Emby to a New Empty Data Directory

[digi999]

Device: TerraMaster F6-424
TOS: TOS 7
Emby: 4.9.5.0.02
Architecture: x86_64
Issue: TOS firmware update causes an existing Emby installation to start with a completely new/empty database.

Summary

After updating my TerraMaster NAS firmware, my previously working Emby Server suddenly presented the "New Emby Server" / initial setup wizard.

Emby itself had been working perfectly immediately before the TOS firmware update. I had also previously installed the TerraMaster-provided Emby update to version 4.9.5.0.02, which resolved the earlier Emby-related issue and left the server working normally.

After the subsequent TOS firmware update, Emby started as though it had never been configured.

No Emby reinstall was performed. No library database was intentionally deleted.

Investigation showed that TOS had caused Emby to use a different programdata directory.

What I found

The TerraMaster Emby startup script contains:

APP_DATA_DIR=$(ter_share_add -name "Emby")

and subsequently launches Emby using:

-programdata $APP_DATA_DIR

Before the firmware update, the existing Emby instance was using:

/Volume2/@apps/emby/emby-server/-ffdetect/

The existing database there was:

library.db
64,331,776 bytes

and contained my established Emby user:

Name: digi999
IdString: aeb035f5326146429185e407308c8cf3

The old Emby logs also explicitly showed:

Data path: -ffdetect

and:

Logs path: -ffdetect/logs
Cache path: -ffdetect/cache

This was the working Emby server immediately before the TOS firmware update.

After the TOS firmware update

The same TerraMaster Emby package was now being started with:

-programdata /Volume2/Emby

The result was a completely new Emby environment.

The new database was only:

/Volume2/Emby/data/library.db
303,104 bytes

and the new users.db contained:

Name: emby
IdString: bb8ac4245e65461d956fca25993e0f50

rather than my existing digi999 account.

The new configuration also contained:

<IsStartupWizardCompleted>false</IsStartupWizardCompleted>

whereas the original working configuration contained:

<IsStartupWizardCompleted>true</IsStartupWizardCompleted>

The new configuration also had several migration flags reset to false, consistent with a completely fresh Emby installation.

Why I believe this is a TOS application/share regression

The critical discovery was:

ter_share_add -name "Emby"

After the firmware update this returned:

/Volume2/Emby

The TerraMaster Emby launcher then uses that result directly as:

-programdata /Volume2/Emby

Therefore, the Emby application itself was not losing or corrupting its database.

TOS was causing the Emby package to resolve its persistent application data to a new location.

This resulted in Emby behaving exactly as it should when presented with a completely empty programdata directory: it created a new database and displayed the initial setup wizard.

Recovery

I stopped Emby and preserved the newly-created /Volume2/Emby directory.

I then moved the existing working Emby data from:

/Volume2/@apps/emby/emby-server/-ffdetect

to:

/Volume2/Emby

so that it matched the location currently returned by:

ter_share_add -name "Emby"

After starting Emby again, the server immediately recognised the existing database.

The logs then showed it validating my existing libraries, including:

ValidatePhysicalRoots completed validating 29965 Plex-4K /Volume1/Plex-4K
ValidatePhysicalRoots completed validating 28495 Plex-Documentaries /Volume1/Plex-Documentaries
ValidatePhysicalRoots completed validating 4 Plex-Movies /Volume1/Plex-Movies
ValidatePhysicalRoots completed validating 26819 Plex-TV /Volume1/Plex-TV

and:

ValidateTopLibraryFolders validating 3 Movies
ValidateTopLibraryFolders validating 26818 TV
ValidateTopLibraryFolders validating 28494 Documentaries
ValidateTopLibraryFolders validating 29964 4K Movies

This confirms that the original Emby database was intact and that the problem was the data-directory mapping, not database corruption.

Expected behaviour

A TOS firmware update should not change the persistent data location of an existing application without migrating the application's existing data.

For Emby, an existing installation should continue to use its existing configuration, database, users, libraries and plugins after a TOS update.

Actual behaviour

After the TOS firmware update:

Existing Emby installation
↓
TOS update
↓
Emby data/share resolution changes
↓
/Volume2/Emby
↓
Empty database created
↓
Existing server appears to have been lost
↓
"New Emby Server" setup wizard

This is particularly dangerous because an ordinary user could reasonably believe that their Emby database has been deleted or corrupted and could then reinstall Emby, potentially making recovery considerably more difficult.

Requested fix

Please investigate the interaction between:

ter_share_add

and the TerraMaster Emby package, specifically:

APP_DATA_DIR=$(ter_share_add -name "Emby")

and:

-programdata $APP_DATA_DIR

during/after TOS firmware upgrades.

The firmware/package update process should preserve the existing Emby application-data mapping, or automatically migrate the existing Emby data to the newly selected application share.

Please do not simply create a new empty /Volume2/Emby directory and leave the existing Emby database behind in the old application directory.

Ideally, the firmware update should detect the existing Emby installation and preserve its:

library.db
users.db
authentication.db
system.xml
plugins
metadata
library configuration
user accounts
Additional information

The TerraMaster Emby package installed on the system was:

Emby 4.9.5.0.02

The executable itself remained present and functional after the TOS update.

The original database was not corrupted.

The original server was successfully recovered simply by placing its existing program-data directory at the location currently returned by TerraMaster's ter_share_add -name "Emby".

This strongly suggests a TOS/application packaging or application-share migration problem rather than an Emby software/database problem.

TL;DR

TOS firmware update changed where the TerraMaster Emby package looked for its programdata.

Old:

/Volume2/@apps/emby/emby-server/-ffdetect

New:

/Volume2/Emby

Emby therefore started with an empty database and appeared to have lost the entire server.

The original 64 MB database was still present and completely intact.

Please fix the TOS Emby application/share migration so firmware updates don't repeatedly make existing Emby installations appear to be brand-new servers.
This is the second time a TerraMaster firmware update has caused my perfectly functioning Emby installation to appear to have been wiped. I have now spent considerably more time investigating TerraMaster's application-data mapping than I have spent watching television. Please make this the last time I have to do this lol

[CursaYang]

To help troubleshoot the problem more quickly, please confirm if you remember which version of TOS 7 you upgraded from and which version the problem occurred in.