Opened 4 years ago

Closed 4 years ago

Last modified 4 years ago

#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:
Has a Patch: no 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)

system (1.5 KB) - added by humdinger 4 years ago.
data/launch system with hrev49518

Download all attachments as: .zip

Change History (15)

comment:1 Changed 4 years ago by ttcoder

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.

comment:2 Changed 4 years ago by waddlesplash

Milestone: UnscheduledR1/beta1
Priority: normalblocker

I can confirm this, and @bbjimmy can as well. Most likely a launch_daemon issue indeed.

comment:3 Changed 4 years ago by bbjimmy

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 Changed 4 years ago by anevilyak

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 Changed 4 years ago by waddlesplash

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 Changed 4 years ago by waddlesplash

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 Changed 4 years ago by anevilyak

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.

comment:8 Changed 4 years ago by anevilyak

Owner: changed from axeld to anevilyak
Status: newin-progress
Last edited 4 years ago by anevilyak (previous) (diff)

comment:9 Changed 4 years ago by anevilyak

Resolution: fixed
Status: in-progressclosed

Fixed in hrev49517.

comment:10 Changed 4 years ago by 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?

comment:11 in reply to:  10 Changed 4 years ago by anevilyak

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?

Changed 4 years ago by humdinger

Attachment: system added

data/launch system with hrev49518

comment:12 Changed 4 years ago by humdinger

yep, disk is auto-mounted. "system" attached.

comment:13 Changed 4 years ago by anevilyak

Please try again with hrev49522 or newer.

comment:14 Changed 4 years ago by humdinger

That was it. Confirmed working. Thanks!

Note: See TracTickets for help on using tickets.