View Issue Details

IDProjectCategoryView StatusLast Update
0000973OpenMPT[All Projects] User Interfacepublic2017-06-14 04:54
ReporterjmkzAssigned Tomanx 
PrioritynormalSeverityminorReproducibilityalways
Status closedResolutionno change required 
Platformx64OSWindowsOS Version7
Product VersionOpenMPT 1.27.00.* (current testing) 
Target VersionFixed in Version 
Summary0000973: Save now button on Advance tab in settings does not save persistent
Description

Save now button on Advance tab in settings does not save inmediate changes to mptrack.ini. I would expect to overwrite or recreate the entire file every time that is used on demand.

Steps To Reproduce

Change any setting and apply the [Save now] button (or without changing a setting).

TagsNo tags attached.
Has the bug occurred in previous versions?
Tested code revision (in case you know it)8282

Activities

manx

manx

2017-06-09 05:21

administrator   ~0003065

Change any setting and apply the [Save now] button (or without changing a setting).

I cannot reproduce this. Changing a setting and clicking "Save now" updates mptrack.ini for me.
When no setting is changed, not rewriting mptrack.ini is expected behaviour.

Save now button on Advance tab in settings does not save inmediate changes to mptrack.ini.

For changes made in other tabs, you have to apply (click the "Apply" button at the bottom) them first, in order to get them changed internally and thus saved to disk. In theory, we could have "Save now" imply "Apply", but that would result in settings which have been changed and not even a tiny bit tested be saved to disk, which could, in the worst case, result in OpenMPT not working any more even when restarted.

I would expect to overwrite or recreate the entire file every time that is used on demand.

No, it will always only rewrite the settings that actually got changed compared to what is currently stored in the file. If nothing changed, it will write nothing. Not completely regenerating the file is important in order to keep settings for older and/or newer OpenMPT versions which the version currently running does not understand (and even in some corner cases for some settings that the current version does understand but has not yet actively loaded in the current run).

jmkz

jmkz

2017-06-11 17:16

reporter   ~0003072

Ok, I see your point. But what I am noticing is that if you want to use multiple instances of the same executable, apparently it updates mptrack.ini at exit, not when a change of setting is applied.

A brief example:
Open a song, then it is shown on recent songs list, but if you open another instance, it does not load the settings applied by the first one.

I am currently using portable mode throug UseAppDataDirectory=0.

Saga Musix

Saga Musix

2017-06-12 13:52

administrator   ~0003076

Last edited: 2017-06-12 13:53

View 2 revisions

apparently it updates mptrack.ini at exit, not when a change of setting is applied.

That is by design (see also what manx wrote regarding the Apply button).

Open a song, then it is shown on recent songs list, but if you open another instance, it does not load the settings applied by the first one.

I think it would be very wasteful (and not really required) to write the Most Recently Used list everytime a file is loaded. Just think of running OpenMPT on a very slow drive and having to wait until the settings are written just because you opened a file.
Running several instances of OpenMPT is supported in general but I don't see why these instances would have to know about each other's MRU list.

jmkz

jmkz

2017-06-14 03:20

reporter   ~0003081

MRU List is just an example (you can try with changing the sound device settings though). With this additional aspects provided, feel free to close this issue. I will try later on a more elaborated report.

manx

manx

2017-06-14 04:54

administrator   ~0003082

Even if we saved changed settings always immediately to mptrack.ini, this would not solve the issue at all. Settings are read from mptrack.ini basically on startup of OpenMPT (there are exceptions) and then cached internally (as loading settings on every access in the program code would be extremely slow). Thus "saving immediately" and "loading on startup" would result in very asymmetric behaviour which would be even more confusing.

Reparsing the whole mptrack.ini file on every change to it would be infeasible performance-wise.

Another theoretical possibility would be to implement explicit inter-process notification and synchronisation for settings changes (which would be a huge infrastructure effort for very little gain).

Additionally, both of these last points would require the settings infrastructure to support changing settings from the outside even at all (even in the current state, a lot of settings that you can change in the Advanced tab will not be honoured immediately and instead require a restart of OpenMPT or will be lost all together because they are cached internally elsewhere for performance reasons).

Another point to consider: Synchronizing settings immediately does not even make sense for some settings like window positions or ASIO sound device channel allocation (there are probably other examples). There are also settings which fundamentally can only be applied on program startup. Thus, such settings would need to be split from other settings in order to give a somewhat consistent impression both to the user and internally in the code.

And, even if theoretical possible, I think it would not be desirable for the reasons already explained.

With this additional aspects provided, feel free to close this issue. I will try later on a more elaborated report.

I'm closing this issue now. Closing as "no change required" instead of "won't fix" because that reason is more fitting for the originally reported issue. However, the part regarding settings synchronization of running instances should be considered won't fix for the reasons explained.

Issue History

Date Modified Username Field Change
2017-06-09 03:44 jmkz New Issue
2017-06-09 04:49 manx Assigned To => manx
2017-06-09 04:49 manx Status new => assigned
2017-06-09 04:49 manx Status assigned => new
2017-06-09 05:21 manx Status new => feedback
2017-06-09 05:21 manx Note Added: 0003065
2017-06-11 17:16 jmkz Note Added: 0003072
2017-06-11 17:16 jmkz Status feedback => assigned
2017-06-12 13:52 Saga Musix Note Added: 0003076
2017-06-12 13:53 Saga Musix Note Edited: 0003076 View Revisions
2017-06-12 13:55 Saga Musix Status assigned => feedback
2017-06-14 03:20 jmkz Note Added: 0003081
2017-06-14 03:20 jmkz Status feedback => assigned
2017-06-14 04:54 manx Status assigned => closed
2017-06-14 04:54 manx Resolution open => no change required
2017-06-14 04:54 manx Note Added: 0003082