#12289 closed bug (fixed)
Sounds preferences aren't loaded/used
| Reported by: | humdinger | Owned by: | anevilyak |
|---|---|---|---|
| Priority: | blocker | Milestone: | R1/beta1 |
| Component: | Servers/launch_daemon | Version: | R1/Development |
| Keywords: | Cc: | ||
| Blocked By: | Blocking: | ||
| Platform: | All |
Description
This is hrev49491.
After rebooting, my "Vision nick notfication" in the Sounds preferences isn't there anymore, even though it's still visible with a "message /boot/home/config/settings/Media/MediaFiles".
I suspect it might be the same error that messes up QupZillas preferences/profile/etc., which config info shows "/boot/apps/QupZilla/"/boot/home"/config/settings/Qt/.config/qupzilla/profiles/default Settings".
Not sure it's launch_daemon related, but it only appeared after updating from pre-launch_daemon.
Attachments (1)
Change History (15)
comment:1 by , 9 years ago
comment:2 by , 9 years ago
| Milestone: | Unscheduled → R1/beta1 |
|---|---|
| Priority: | normal → blocker |
I can confirm this, and @bbjimmy can as well. Most likely a launch_daemon issue indeed.
comment:3 by , 9 years ago
Interestingly, if one drags Qupzilla out of its package into /boot/apps, it finds and can save bookmarls again. it creates a folder: /boot/apps/QupZilla/"/boot/home"/config/settings/Qt/.config/qupzilla/profiles/default/ and stores the bookmarks there and can be launched from Tracker.
comment:4 by , 9 years ago
FWIW, Qupzilla's problem appears to be unrelated, that one looks to be concatenating onto the CWD to generate its settings file path rather than using find_directory/find_paths to locate B_USER_SETTINGS_DIRECTORY (which may be a problem down in the Qt port itself rather than Qupzilla per se).
In the case of the sound prefs, the settings file is saved/loaded in the correct location by media_server, but something appears to go wrong when reconstructing the event -> entry_ref map, as the sound preflet still gets the list of events properly (they're retrieved via sending a message to media_server, not parsing the settings file directly), but the actual file entries corresponding to each event somehow aren't rebuilt properly.
comment:5 by , 9 years ago
FWIW, Qupzilla's problem appears to be unrelated, that one looks to be concatenating onto the CWD to generate its settings file path rather than using find_directory/find_paths to locate B_USER_SETTINGS_DIRECTORY (which may be a problem down in the Qt port itself rather than Qupzilla per se).
No, it looks like it's the result of a bad merge of Qt 4.8.7 into our Qt4 branch. I'll disable the recipe for now.
comment:6 by , 9 years ago
Oh, never mind, scratch that -- it appears that bbjimmy is still on 4.8.6, I misunderstood. I don't know why there's a problem, then, because the code that determines where to save the settings just fetches the contents of the "HOME" environment variable and then appends "config/settings" onto that.
comment:7 by , 9 years ago
That's exactly how not to do it, as stated the preferred/correct approach is to use find_directory/find_paths to locate settings, so the code is resilient to settings being relocated elsewhere in the future, i.e. if/when multiuser happens, rather than hardcoding the assumption that home/config/settings is always the correct place.
follow-up: 11 comment:10 by , 9 years ago
It does work now, but only if the sound file is on the boot volume. Mine is on another partition however.
In fact, I cannot now say if it would have worked before the fix if I had tried using the boot partition...
Re-open or new ticket?
comment:11 by , 9 years ago
Replying to humdinger:
It does work now, but only if the sound file is on the boot volume. Mine is on another partition however.
In fact, I cannot now say if it would have worked before the fix if I had tried using the boot partition...
Re-open or new ticket?
That was exactly what I ran into prior to adjusting the launch dependencies, boot volume sounds would work, but other volumes would not. To be sure, can you attach a copy of /system/data/launch/system from your installation? You do have the other partition in question set to auto mount, correct?
Interestingly, Qupzilla does find its settings if ran from Terminal, the bug occurs only when run from Tracker, so I use that as a work-around for now.. (same for dosbox).. So I take it it's not fixed by hrev49487 then, hmm. I planned to update get that fix but will wait a bit more.