Hi all,
I’m evaluating mAirList Personal edition and I have manged to totally mess up the layout. I thought I could uninstall and re-install it to get everything back to it’s default state but that does not seem to be the case. It seems to retain all the old settings…layout, audio devices, etc. Where does mAirlist store settings and how can I delete them and/or restore to a default state?
Thanks!
Dave
It is usually stored in “C:\Program Files\mAirList 3.0\config”. You have to delete that folder after uninstall to get rid of all settings. If you just want to reset the layout, just delete the file named “layout.ini” from that folder and restart mAirList. No reinstall necessary.
I did delete that folder. OK, I see this time it didn’t keep the audio device settings, but it did keep the messed up layout. I don’t get it. I’m running mAirList on Vista if that makes any difference.
Have you tried deleting the “layout.ini” file only? No reinstall, not deleting anything else.
I don’t see layout.ini anywhere. It’s not in C:\Program Files\mAirList 3.0\config\ anyway. In fact that folder is empty.
Interestingly, if I right-click on the mAirList shortcut and run as Administrator I get the default layout. Hmmm…
Some people have reported that on Vista or Win7, depending on your account settings, Windows will magically move all config files to some hidden folder separate from the Program Files directory. I’m currently investigating this problem.
I would suggest that you download the Zip Archive distribution from mAirList and unzip it to any folder (other than Program Files). You can download/activate the Personal Edition demo license using the License Mananger (LicenseManager.bat) after installation. Check out the batch files (mAirListConfig.bat, LayoutDesigner.bat etc.) which serve as a replacement for the entries in the Start Menu.
Bingo! The config files were in C:\Users\Dave\AppData\Local\VirtualStore\Program Files\mAirList 3.0\config
OSs should always run mAirList as Administrator to avoid this problem? I think you can work out why I’m asking, Torben? 
)BFN
CAD
Generally, the “modern” way of storing all configuration outside the Program Files folder is reasonable because it improves the security of the system. Linux and Mac OS have always worked this way (e.g. on Linux, all system-wide config files are in /etc).
So I think I should rather make mAirList store the config in the modern way, that is:
The same applies to the various “standard” files like e.g. the standard.mlt desktop template. An ordinary user will not be able to create these files in Program Files. However, as the “modern” folders are sometimes hard to locate (or even hidden by Windows), I think we should have some sort of “Save as default” menu items, so that the user won’t have to deal with the actual name of the file anymore. What do you think?
The final questions is, what about the “unzip anywhere” installations of mAirList? It should still be possible to have multiple copies of mAirList installed in different folders (not in Program FIles) with the configuration files store in the same directory. Here’s an idea:
Comments?
Why not use both? The OS I mostly work with is Sun Solaris and although they don’t enforce it to the last consequence, their de facto standard of installing software is:
Binary packages go to /opt, config files to /etc and and variable files end up in /var - let’s take a fictional package called SUNWabc as an example. If installed you may find a directory structure like this:
/opt/SUNWabc/bin/abc
/opt/SUNWabc/man/abc.1
/etc/opt/SUNWabc/abc.conf
/var/opt/SUNWabc/abc.log
Plus lots of other files scattered across this structure. Additionally, there are packages that allow a personal configuration by placing an .abc.conf file in the user’s homedirectory. When started, the software will use the global config file in /etc and then check for the user’s config file in the home directory. If one is present it will override the settings from the global file.
Whether you want to make all options options overridable by the users or if you specify options that must be set globally (e.g. security-related) and ony a subset may be overridden locally is merely a matter of design.
The consequence would be that the software has to be installed by the administrator, but it can be run from any user and each user can configure the software to his liking without interfering with users.
Kind regards,
McCavity
As reply to Torben’s posting.
There are even some programs that store their data in:
C:\Documents and Settings"UserName"\Local Settings\Application Data\mAirList\3.0\config
In order to make the difference between the different releases the build is appended to the release. So for mAirList this would be (example):
C:\Documents and Settings"UserName"\Local Settings\Application Data\mAirList_3.0_643
This should be sufficient, as there will be only config data stored here.
The use of “Username” or “All Users” might be contested. It depends on who will be allowed to make changes to the config.
Edit: Ah yes, if I remember well, Vista makes use of a …\Roaming… folder to store this data.
I do not have Vista available now, but may check it tonight.
regards:
-Serge-
Windows is not Solaris, but actually, the idea is pretty much the same:
The /etc and /bin directories on Unix are often prefixed with some other directory (/usr, or /usr/local, or /opt) depending on the type of software and how you installed it. But in most cases, these prefixes are hard-coded, that is, set as a define during compile time. That does not work with a binary distribution like mAirList. It needs to determine its config folder dynamically.
Reading configuration data from several folders would of course work. But how should mAirListConfig decide in which folder to save it? Under Unix, you usually edit the configuration files manually, so you know which file you edit and where you are going to save it (global or user-specific configuration).
[quote=“radiorom, post:12, topic:6402”]There are even some programs that store their data in:
C:\Documents and Settings"UserName"\Local Settings\Application Data\mAirList\3.0\config[/quote]
That is the per-user configuration folder. Storing the configuration in that folder would mean that when you log in as a different user, there will neither be a configuration nor a license file, so mAirList will not work. That would be a problem for many users. For example, at eldoradio*, everybody logs in with their own account in the studio, and the configuration should be the same for everyone. This is why I think we should use the “All Users” configuration part.
On a side note, as you already mentioned, per-user configuration can either be “local” or “roaming” (this is not new in Vista but has always been this way ever since Windows NT). Inside the user’s configuration folder, there are two folders named “local” and “roaming”. When you have a Windows network with a domain and logon server, and roaming profiles enabled, the “roaming” part of the configuration will be stored on the server, and each time you log in on some workstation, it will be copied to that PC (and back to the server when you log out again). A software should use the “roaming” part of the profile to store information that should be available on all workstations in the network. Computer-specific configuration should be stored in the “local” part. For example, Firefox stores your bookmarks and history in “roaming”, while the temporary cache files are in “local”.
But roaming configuration is only available on a per-user level, and mAirList will use global/“All Users” configuration, so this doesn’t really matter here 
[quote=“radiorom, post:12, topic:6402”]In order to make the difference between the different releases the build is appended to the release. So for mAirList this would be (example):
C:\Documents and Settings"UserName"\Local Settings\Application Data\mAirList_3.0_643
This should be sufficient, as there will be only config data stored here.[/quote]
The exact version and build number should not be appended to the folder name; otherwise, when you update to a new build, your configuration will be lost. Or we would need an installer that looks for old configuration data and copies it into the new place. But many people only download and replace the mAirList.exe from the snapshot. That doesn’t work then.
Instead, we’ll only append the release number (3.0, 3.1, … - perhaps this is what you had in mind):
C:\Documents and Settings\All Users\mAirList\3.0 (on 2000/XP)
C:\ProgramData\mAirList\3.0 (on Vista/7)
So all binaries of mAirList 3.0 share the same configuration folder, and you can just update the exe file as needed.
When you install mAirList 3.1 one day, it will start with an empty configuration (but you can easily copy the “3.0” folder to “3.1” to apply your old configuration). It’s also possible to use two releases at the same time (e.g. the current production release and a fresh beta), because they will both have their own configuration.
I agree with you Torben.
“All User” folder would be best choice. I’m aware about roaming profile that can be used on domains. What I wanted to point out is that a lot of programs do store the data there, even if the user is not member of a domain.
However, I’m curious now on how this user login/logoff can be handled on a Radiostation without interupting mAirList playout…
Or we would need an installer that looks for old configuration data and copies it into the new place. But many people only download and replace the mAirList.exe from the snapshot. That doesn't work then.Exactly. The installer copies the old config to the new location. I agree that snapshot handling would have to be wrapped into a "mini"-installer that takes care of this. But I think that's too much of overhead.
All these problems seem to have no easy/straight solution…
regards:
-Serge-
That mAirList PC is only used for live shows. There’s a separate PC with does the automation in between. This way, the studio is available for practicing and pre-production during automated hours.
If there’s two live shows in a row, the previous user will usually just stay logged on (unless the new user will need write access to his home folder).
I admit I’ve only skimmed this thread, but I don’t like the idea of moving the config files ANYwhere. Of course, I’m on XP (support for which has been extended to 2014, incidentally). The chances of me migrating to Win7 during that time are about zero. 
I often have two (or more) different snapshots of the same release of mAirList installed on the same (testing) PC. So even the idea of ‘separating’ sets of config files by release number would screw that up.
The only solution I can think of which might work would be (on 2000/XP) to store configs in:
C:\Documents and Settings\All Users[b]x[/b]\config
where x is ‘the path beyond Program Files where THIS install of mAirList is stored.’
I have on my PC here:
C:\Program Files\mAirList (old stable 2.x version)
C:\Program Files\mAirList\Dev (latest 2.x snapshot—which I admit, is now stable!)
C:\Program Files\mAirList\3 (latest 3.0.10-setup version)
C:\Program Files\mAirList\3\Snapshot (latest 3.x snapshot for testing)
So, for those four installs, under my suggested system, the config files would go to:
C:\Documents and Settings\All Users\mAirList\config
C:\Documents and Settings\All Users\mAirList\Dev\config
C:\Documents and Settings\All Users\mAirList\3\config
C:\Documents and Settings\All Users\mAirList\3\Snapshot\config
And somewhat of a pain to go to the ‘right’ place to edit the appropriate set of config files. :-\BFN
CAD
Dear Cad,
I don’t like the idea either, but current Windows versions leave no choice. If you (the developer) don’t care to store the config files in a proper location, then Windows will do it for you, an most likely in a place you wouldn’t have expected or even heard of before.
Imost also say that it is after all a good idea to have Program Files write protected to ordinary users, because it prevents certain security risks.
With the proposed solution, you will still be able to have multiple copies of te same release installed at the same time, as long as they have their own config directory in the program folder. Only the main installation in Program Files will use the new config location.
I strongly suggest to keep these manually installed versions in a different folder than Program Files anyway.
What does a ‘proper location’ mean?!!
Right … so I could do a ‘dummy’ install to ProgFiles, then do manual installs to somewhere else, which would leave the config files where I would expect them to be?
BFN
CAD
A location where the user is supposed to have write access at any time. This is not the case for C:\Program Files. Only an administrator should be allowed to write there. (Or an ordinary user who is temporarily granted admin privileges while he installs a new software - Vista and Win7 will do that for you, possibly displaying a warning message beforehand.)
I repeat, this is all very reasonable. Mac OS and Linux have followed this concept ever since. And it’s no surprise that there’s hardly any viruses and malware for those operating systems. When you’re working as an ordinary user with no admin privileges most of the time, an accidentally downloaded and executed virus will not be able to save itself too far into the system.
Right … so I could do a 'dummy' install to ProgFiles, then do manual installs to somewhere else, which would leave the config files where I would expect them to be?
For a power user like you, I recommend that you use the zip version straight away, and unzip as many copies you like to any folder you wish. In C:\Program Files, C:\mAirList or wherever. Just make sure that each copy has a “config” folder inside the program folder. mAirList won’t look for configuration files anywhere else. That’s the simple rule now: config folder present => config expected to be in program folder; no config folder present => config expected to be in Windows’ common application data folder.
Oh, and if you decide to store all copies in C:\Program Files, be aware that you will have problems if you ever decide to switch to Vista (better not) or Windows 7.
If it wasn't a testing PC, then yes. But it [b]is[/b] a testing PC. ;)
You don’t use the setup.exe to install all those copies all the time, do you? Personally, I only keep software installed with an installer in C:\Program Files. In other words, only software that also has a Start Menu group and so on. For any software (e.g. a copy of Skype Portable I use for support once in a while, you know what I’m talking about) I’m using a different parent folder, C:\apps in my case. If I had to keep a farm of mAirList installations, I would probably store them in C:\mAirList\firstversion, C:\mAirList\secondversion and so on.
Not something I’m likely to do in the next year or three. 
It does make a bit of a mockery of Program Files IMHO. The whole point of Microsoft creating Program Files (I know, Torben, you’re too young to remember that! :D) was to end the ‘mess’ of 101 different top-level directories, one per app. >sigh<
That’s progress, I suppose? :-\
Hmm … C:\Apps? … that takes me back to the mid-1990s! Like I said, I guess that’s progress … (?)
BFN
CAD