Jamulus: sliders move by themselves in 3.5.11

[mawess]

We hade a rehearsel today with 17+ musicians.
server was running brand new 5.3.11.
the connected clients hade varying versions.

a client with version 5.3.11 has strange problems: the slides (and levels) suddenly change without him touching it. 4 sliders went to max and 1 went to 0.

another client with version 5.3.10 reports the (exact) same thing.

another user (running 5.3.10) reports that she was muted without touching anything.

(all had "small packets")

[corrados]

Do you have a MIDI instrument connected to the PC where you run Jamulus? Because with MIDI you could control the faders.

Is the fader changing if a new user enters the server? Or is it changing during a session when no clients enter or leave the server?

Do you use the New Client Level? This value changes the fader on a new client connecting to the server.

[mawess]

some clarifiing this: these are there different users, none of them is me.

I believe they uses new client level but the levels was not the same: as a single event 4 sliders went to100 % and one went to 0%.

Its not clear wether someone leaved or entered at this time.

I will forward the reset questions to the players.

[mawess]

from one of the players:
"No midi connected on my end. The problem occurred at random times and suddenly changed 5 faders all at once mid song - unrelated to anyone entering or leaving. I have the new client level set to about 75%, but when this issue occurred 4 of the affected faders went to max and one went to zero."

[corrados]

This is a very strange effect. I have never seen this. I need to be able to reproduce this issue on my PC to fix it. How are the exact steps to reproduce it?

[corrados]

Has anybody else encountered that problem?

[mawess]

"This is a very strange effect. I have never seen this. I need to be able to reproduce this issue on my PC to fix it. How are the exact steps to reproduce it?"

Sorry Im not sure what triggered this. But the baryton player was disconnected and reconnected about 10 times when this happened. since the barityon channel was the one that went to 0 (and the other four saxes went to max) for the two clients mentioned above there could be a connection.

but since we dont know what disconnected the barytin player its not much help...

(maybe its just another symptom of the recordong not being thread-safe?)

[corrados]

But the baryton player was disconnected and reconnected about 10 times when this happened

So, he had network issues then which caused the disconnections?

(maybe its just another symptom of the recordong not being thread-safe?)

No, I don't think that these things are related.

[corrados]

You gave two contradict statements:

1) "_The problem occurred at random times and suddenly changed 5 faders all at once mid song - unrelated to anyone entering or leaving._"

2) "_But the baryton player was disconnected and reconnected about 10 times when this happened._"

This should be clarified.

I assume that this issue is very annoying if it happens during a rehearsal with so many people. If it is a bug in the Jamulus software, I would really want to fix it. But since I have never seen this and no other user has reported here that he has seen this problem, it is very hard to find out where to search for the issue in the code.

[mawess]

sorry if its confusing but I just retold what my bandmembers told me. What i think they mean is that no new person arrived and no one left. The bariton was seemingly with the rehearsal the all time, the disconnects/reconnects he talks about was not obvious to others.

we havent seen this again despite numerous rehearsals and concerts .

/m

14 nov. 2020 kl. 07:45 skrev Volker Fischer [e-mail]:


You gave two contradict statements:

"The problem occurred at random times and suddenly changed 5 faders all at once mid song - unrelated to anyone entering or leaving."

"But the baryton player was disconnected and reconnected about 10 times when this happened."

This should be clarified.

I assume that this issue is very annoying if it happens during a rehearsal with so many people. If it is a bug in the Jamulus software, I would really want to fix it. But since I have never seen this and no other user has reported here that he has seen this problem, it is very hard to find out where to search for the issue in the code.

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or unsubscribe.

[corrados]

Thanks for your feedback.

we havent seen this again despite numerous rehearsals and concerts .

At least this is good news :-).

The bariton was seemingly with the rehearsal the all time, the disconnects/reconnects he talks about was not obvious to others.

Ok, so then it is very probable that the disconnects/reconnects were causing the issues. I could try to imitate this situation by sending disconnect messages at random multiple times and see if I can then see the issue.

[corrados]

For a test I have put the following code in the ProcessAudioDataIntern function:

static int iTEST = 0;
iTEST++;
if ( iTEST > 100 )
{
    iTEST = 0;
    ConnLessProtocol.CreateCLDisconnection ( Channel.GetAddress() );
}

This is the result I get on a second Jamulus instance:

As you can see, the second fader appears and disappears very quickly but the fader positions stay as they are. So, unfortunately, I still cannot reproduce your issue.

[corrados]

I now can reproduce the issue. The issue is related to the grouping. If a fader which was grouped disconnects and re-connects to the server, the other faders of that group move which is incorrect.

[mawess]

oh! nice!

26 nov. 2020 kl. 16:52 skrev Volker Fischer [e-mail]:


I now can reproduce the issue. The issue is related to the grouping. If a fader which was grouped disconnects and re-connects to the server, the other faders of that group move which is incorrect.

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or unsubscribe.

[corrados]

The problem should be fixed now. So, I'll close this issue. The fix will go into the next version 3.6.2. If you still observe the issue in 3.6.2, please re-open this Issue or create a new one.