I have been testing the Soundtrack addon on WoW Forever and wanted to document the results in detail because the addon itself now appears to function correctly on Forever, but SavedVariables do not appear to be restored properly when the client starts.
This has been tested through multiple addon builds and several controlled startup/logout tests.
Addon being tested
Soundtrack 7.0.1 (This is the build)
The addon allows custom music to be assigned to zones, combat events, abilities, mounts, status events, etc.
The original package already contained both Classic and Mainline support, so I began testing from the modern/Mainline codebase rather than attempting to port the older Classic branch.
The Forever build was modified so that Forever is treated as its own client flavor:
IsRetail = false
IsForever = true
UsesModernAPI = true
The intention was to preserve Forever/Classic-style game content while still allowing the addon to use the modern APIs and restrictions that Forever appears to inherit from the modern client.
Initial compatibility issues
The original addon initially produced several Lua errors.
The first major error was:
AceDB-3.0.lua:264:
attempt to concatenate local ‘regionKey’ (a nil value)
This happened during AceDB initialization.
Because the database failed to initialize, several additional errors followed:
attempt to index field ‘db’ (a nil value)
These appeared in:
Core/Zones/ZoneEvents.lua
Core/Utils/Chat.lua
Core/MiscEvents/MiscEvents.lua
These turned out to be cascade errors caused by the database initialization failure.
The bundled AceDB implementation assumed the result from:
GetCurrentRegion()
would map to the normal production region IDs.
The Forever beta was returning a region value the bundled AceDB did not recognize, resulting in a nil regionKey.
We patched AceDB so unexpected/beta region IDs would not cause initialization to fail.
After that change, the database initialized normally.
TOC/client detection
Another issue was that Forever was falling through to the Mainline TOC.
A dedicated Forever/Camelot TOC was added, and the Forever branch was separated from the old Retail-versus-Classic boolean logic.
This was important because the original addon sometimes used:
IsRetail
to mean:
Use the modern API.
But in other places it meant:
Enable Retail-only content.
Those are not the same thing on Forever.
For example, modern aura restrictions may apply on Forever, while Retail-only classes/features obviously should not automatically be enabled.
So the Forever branch now distinguishes those concepts.
Missing custom music library
After the database issue was fixed, the next error was:
Cannot load MyTracks.lua.
You probably forgot to run GenerateMyLibrary.
Soundtrack expects a separate folder:
Interface/AddOns/SoundtrackMusic/
containing the generated:
MyTracks.lua
The original TOC attempted to load this file directly, which caused startup problems when the library did not yet exist.
The Forever version was adjusted so a missing custom library would not prevent the addon from initializing.
After generating the library, custom music successfully loaded.
Mac music-library generator
The original Bash generator worked on macOS but was quite slow with a large music collection.
A faster Mac generator was created.
During the first attempt, it generated the library quickly but music would not actually play.
That turned out to be a path-escaping bug in the replacement generator.
The generator was producing too many escaped backslashes in paths.
After correcting that, the fast generator successfully produced valid entries such as:
“Sky Elves\Zephras Isle Delux”
and the music played correctly.
The faster generator was substantially quicker than the original script and processed large batches of songs very rapidly.
Functional testing that currently works
At this point, the Forever version of Soundtrack successfully does all of the following:
- addon loads without Lua errors
- AceDB initializes
- custom music library loads
- manually selected tracks play
- zone detection works
- zone transitions work
- combat triggers work
- ability-triggered music/sounds work
- event handling works
- custom MP3 paths work
- Soundtrack UI opens and functions
- custom zone assignments work during the current session
So the addon itself appears fundamentally compatible with Forever.
SavedVariables problem
The remaining problem is persistence between sessions.
For example, I assigned:
Sky Elves\Zephras Isle Delux
to:
Unknown/Zephras Isle
The assignment worked correctly during the session.
The in-memory database contained the expected tables.
For example:
/dump SoundtrackDB
returned a large valid table.
Additional checks confirmed:
SoundtrackDB = table
SoundtrackDB.profiles = table
SoundtrackDB.profiles.Default = table
and AceDB’s active profile was also a table.
Data is successfully written to disk
After logging out normally, WoW created:
WTF/Account//SavedVariables/Soundtrack.lua
and:
Soundtrack.lua.bak
The SavedVariables file was inspected directly.
The zone assignment was present on disk:
[“Zone”] = {
[“Unknown/Zephras Isle”] = {
[“tracks”] = {
“Sky Elves\Zephras Isle Delux”,
},
[“priority”] = 2,
[“lastTrackIndex”] = 1,
[“random”] = true,
[“continuous”] = true,
},
},
So Soundtrack is definitely saving the assignment correctly.
The file also contained the correct AceDB profile and profile key.
But the assignment is missing after launching Forever again
Immediately after starting the next game session, this command:
/run z=SoundtrackDB.profiles.Default.events.Zone[“Unknown/Zephras Isle”]; print(z and z.tracks and z.tracks[1] or “NIL”)
returned:
NIL
However, other saved values from the same database appeared to exist.
For example, the stored music-library timestamp was correct.
We also checked:
SoundtrackDB.global.LastSeenVersion
and it returned the expected saved Soundtrack version.
This initially made it look like Soundtrack might be replacing only its event table during initialization.
Legacy migration was tested and ruled out
Soundtrack has older compatibility variables:
Soundtrack_Settings
Soundtrack_Events
There was a possibility that an old migration routine was overwriting the newer AceDB profile during startup.
A test build removed those legacy variables and disabled the migration path entirely on Forever.
The result did not change.
The zone assignment was still missing on startup.
So the legacy migration code was ruled out.
Startup tracing
We then instrumented the addon to trace the saved zone value at multiple stages:
FILES_LOADED
ONINITIALIZE_START
AFTER_ACEDB_NEW
PLAYER_LOGIN
PLAYER_ENTERING_WORLD
AFTER_LOADTRACKS
AFTER_ZONE_INIT
AFTER_CLEANUP
NOW
The trace checked both:
raw
meaning the direct global SoundtrackDB value,
and:
active
meaning AceDB’s active profile value.
The surprising result was that the saved zone assignment was already:
NIL
at the earliest point Soundtrack code could inspect it.
This meant Soundtrack’s own initialization code was not deleting the value.
Deferred AceDB initialization test
We then tested whether Forever might be restoring SavedVariables later than normal.
AceDB initialization was delayed until:
PLAYER_ENTERING_WORLD
That still did not solve it.
The tracing indicated that SoundtrackDB was unavailable at the time Soundtrack’s PLAYER_ENTERING_WORLD handler executed.
Another test delayed initialization until subsequent frames after PLAYER_ENTERING_WORLD.
The addon polled repeatedly for the restored SoundtrackDB.
It checked approximately 50 times.
The previously saved zone assignment never appeared.
The test eventually timed out.
So simply delaying AceDB initialization did not restore the data.
Most important observation
While the new game session was running and the live Soundtrack database showed:
NIL
for the zone assignment, the existing Soundtrack.lua file on disk was inspected again.
The file still contained:
“Sky Elves\Zephras Isle Delux”
assigned to:
Unknown/Zephras Isle
In other words:
Disk:
zone assignment exists
Running Lua environment:
zone assignment = NIL
The addon is therefore capable of creating and saving the data correctly.
The missing data occurs when the next game session starts.
What we have ruled out
Through these tests we have ruled out several likely addon-side causes:
AceDB failing to initialize
Fixed and verified working.
Malformed SavedVariables TOC entry
Corrected and tested.
Soundtrack not writing its database
Ruled out. The database is written correctly to Soundtrack.lua.
Zone assignment not being stored in AceDB
Ruled out. The assignment is visible both in memory during the session and in the SavedVariables file afterward.
Soundtrack legacy migration overwriting AceDB
Disabled completely; problem remained.
Zone initialization deleting the value
Tracing showed the value was already absent before zone initialization.
Event cleanup deleting the value
Tracing showed the value was absent before cleanup.
AceDB initializing too early
AceDB was delayed through PLAYER_ENTERING_WORLD and multiple subsequent frames. The saved zone assignment still never became available.
Current status
The Forever port of Soundtrack itself is currently functional.
Music playback works.
Custom libraries work.
Zone detection works.
Combat and ability events work.
The primary blocker is saved addon state surviving a client restart.
The evidence from this testing suggests the client is writing the SavedVariables file correctly but is not restoring all of that SavedVariables data into the Lua environment during the next game startup.
At minimum, there appears to be a discrepancy between the contents of:
WTF/Account/…/SavedVariables/Soundtrack.lua
and the SoundtrackDB table available to the addon after login.
Reproduction steps
A fairly simple reproduction using Soundtrack is:
- Install Soundtrack.
- Log into a character.
- Assign a custom track to a zone.
- Verify the assignment works.
- Verify the track appears in:
SoundtrackDB.profiles.Default.events.Zone - Log out normally.
- Close the WoW client.
- Inspect:
WTF/Account/…/SavedVariables/Soundtrack.lua - Confirm the assignment exists in the file.
- Start Forever again.
- Log into the same character.
- Immediately inspect:
SoundtrackDB.profiles.Default.events.Zone - The previously saved assignment is missing.
In my test, the disk file still contained the assignment even though the running Lua table did not.
Why I am posting this
I originally assumed this was simply an addon-porting problem and spent quite a bit of time adapting Soundtrack to Forever.
The API compatibility work was successful enough that the addon now performs its core functions correctly.
The persistence issue is different.
At this point the behavior appears to occur outside Soundtrack’s normal initialization logic, and the saved data can be demonstrated to exist on disk while being unavailable to the addon after startup.
If Blizzard is already tracking a SavedVariables issue in Forever, hopefully this test provides another reproducible case and some useful diagnostic information.
If not, I would be happy to provide the modified Soundtrack build, trace build, SavedVariables examples, screenshots, or additional testing.
Short technical summary
- SoundtrackDB exists and functions normally during gameplay.
- Zone/music assignments work during the session.
- WoW writes the assignments correctly to Soundtrack.lua on logout.
- The saved assignment remains visibly present in Soundtrack.lua on disk.
- On next launch, the assignment is NIL in SoundtrackDB.
- This occurs before Soundtrack zone/event initialization.
- Disabling legacy migration does not change the result.
- Delaying AceDB creation until PLAYER_ENTERING_WORLD does not change it.
- Polling for the restored SavedVariables table for ~50 frames does not restore it.
- Core addon functionality otherwise works on Forever.