b671: Default Cart Set is 'double loaded' at startup

Archive mAirList 3.x (English)
1

When I start mAirList with a Default Cart Set specified, each cart player contains two copies of the same audio file; so they all show [1/2] as if each contains a stack. (Re-)Loading the same Cart Set from the dropdown or the Load Set button loads the same MLC file correctly (one file per player).

I’ve checked the contents of my MLCs and they all contain only ONE file per cart slot, so that’s not the problem. :wink:

BFN
CAD

2

Will be investigated.

3

Yep, I didn’t notice that but I get this in b669

4

Are there any carts defined in the standard.mlt file? Or a standard.mlc file?

I’m not able to reproduce it here. I’m not quite sure, but I think this can happen when you try to load a cart set while the players are still in LOADING state (that is, opening the items in the background).

5

Yes, there is a full set of carts in standard.mlt (good deduction, my friend!). There is also a default cart set defined in the [Cartwall] section of mairlist.ini, which happens to define the same set of carts.

I wonder if this is a logical conflict? If you have (in effect) defined two default cart sets—one in mairlist.ini and one (which might or might not be the same) in standard.mlt—which cart set should mAirList load at startup?

This doesn’t seem to cause a problem in most builds, so it would be very useful for me to know which set would ‘normally’ take precedence at startup.

BFN
CAD

6

First, the default set is loaded. If there is a standard.mlt file, and there is cartwall information in it, its contents will overwrite what’s currently in the cartwall (that is, what was loaded from the default set).

I believe the overwriting doesn’t work when the players are in “loading” state, and for some reason the items are appended to the stack instead.

7

This bug is still present in b677 of v3.0. :frowning:

BFN
CAD

8

It cannot be resolved so easily, because I will have to change the way open requests are processed by the players, which might break other things.

For v3.0, I advise you to use either a default cart set or a standard.mlt with a cart set in it, but not both at the same time.

9

I’ll do that: it’s not a big deal for me, I just thought you would like to know!

But … maybe a quick fix for this would be to set some kind of boolean when you load the default cart set (or the standard.mlt one, whichever is done first), then if that flag is set when it is time to execute the ‘second’ load, don’t execute the cartwall load and instead write a warning message like this to the system log:

The cart set in standard.mlt has not been loaded because you have also defined a default cart set.
(or vice versa :))

Then the user will know what has happened (and why), and can decide which one they want to use. Good idea?

BFN
CAD

10

Much too complicated in my opinion. I’d rather try to sort this out for good in v3.1.

For v3.0, let’s consider this a known bug for which a relatively simple workaround exists.

11

Agreed (and my warning message suggestion was intended for V3.1, where the potential for conflict will still exist).

BFN
CAD