Q Light Controller+

Wireshark is for sure developed on linux mainly. Depending on your distribution, do sudo apt install wireshark or equivalent and there you go.

https://packages.ubuntu.com/kinetic/wireshark
https://packages.debian.org/bullseye/wireshark
https://packages.fedoraproject.org/pkgs ... wireshark/

Jano

It's still interesting a reference project sending packets to nowhere, just to compare the wireshark trace myself on 4.12.4 and 4.12.6. Thanks

giacomo wrote: ↑Thu Sep 08, 2022 8:58 pm Hi Jano, I'm on linux and it seems that wireshark not.
I've tried a very simple transition from scratch with 4.12.6 and it was working, tried again the original show and it's correct only with 4.12.4, maybe this past year something has changed internally in the cue list.
For your info the software is a media-server and is controlled with dmx, each channel controls a parameter.
Anyway I propose that we don't lose more time on this issue, I'm tired to downgrade and test qlc+, upgrade and test it again.
Better to focus on v.5

Giacomo, what media-server do you use? An example project will help us investigate what is happening.

good morning community and thanks for your replies,
I was giving up but finally a clue:
when I play the show with v.4.12.6 the parameter no. 23 of each layer (123 + 173 + 223 ....) goes to 0 during the transition, this doesn't happen
with 4.12.4. (file corrupted or a change internally in the cue list?)
The parameter no. 23 is the file index in the media library, so during the transition there is no media.

I upload the file I'm using for test, I've cleaned up the VC to be sure that the widgets were not causing any problems (many sliders were in monitor mode), the "Layer fixtures" are patched on universe 3 with output E1.131 at 127.0.0.1.
I upload the fixture definition too.

_On the 3rd cue [31 smoke 1] the Layer 2 is going at full >> with v.4.12.6 the layer parameter 23 goes at 0 during the transition;
_The next cue is a preparation for Layer 3 >> again with v.4.12.6 the parameter 23 goes at 0 during the transition;
_etc etc >> during every transition the relative ch 23 of each layer goes at 0
[plus the first time the parameter is loaded - eg. Layer 2 when you play the cue list, during the fade to the 2nd cue - the value get scrolling from 0 to 255 during the fade time - you can see it also for Layer 1 from cue 3 to 4]

almost solved! have a good weekend
(someone would upload a v.5 appimage updated? I'm in rehearsals and I'd like to try the last fixes from Massimo)

Thenks for the project.
First thing I saw is that you're using the "partial" transmission mode. Have you tried the "full" one to see if anything changes?
Now I'm gonna use another instance of QLC+ receiving sACN to see on simple desk if values are received correctly or if I can reproduce the issue

(someone would upload a v.5 appimage updated? I'm in rehearsals and I'd like to try the last fixes from Massimo)

Hm, isn't that quite offtopic in this thread? I really feel uncomfortable discussing this here, hijacking the thread.

Anyways, I have just successfully built a current v5 AppImage locally via create_appimage.sh, and can share that, if that's ok with Massimo.
Not sure if it's a good move either, that's why I hold that back until hearing from him.
I guess Massimo has a plan about releasing betas and test versions, and I'm unsure whether it makes sense to test an arbitrary git commit.

In theory it should be possible to build an appimage in OBS, and I have done that in the past with v4, but for some strange reason I don't yet understand, I cannot make it work currently - the build system seems to look at the rpm spec file and creates rpms in the AppImage download repo.

I have already loaded an appimage in the test folders a few days ago.
As soon as I have some time I'll build a new one and upload it there.

Back to this thread: the behavior can be seen also with the DMX monitor. E1.31 has nothing to do with the issue.
The whole deal is basically a LTP channel that doesn't crossfade correctly.
Removing the "can fade" flag from channel 23 of the Layer-x fixtures already solves the problem.
I'm gonna investigate the expected behavior though.

This summer I'm a bug hunter - with chance!
Yes I've noticed only this this morning in the dmx monitor, in the beginnig I was thinking it was related to updates in the other software.
I also thought that I should change the topic title, please do it if you've an idea of the issue, right now I prefer to not add confusion.

Another finding: the File channel is LSB so probably some 16bit fading logic is kicking in.

[EDIT] confirmed. 16bit fade is the one making the difference. Basically (what a chance!) you have two channels at value 11 and this is the "hack rule" for a MSB+LSB channel to be considered 16bit together. So basically channel 23 is being faded as LSB but being start = target value then the calculation is always 0 during the transition.
Attached the sample project I expected.

Massimo,
I've changed values of the relative Ch.23 in your project:
.1st cue the ch.23 is @12
.2nd cue the ch.23 is @13

The output it's still wrong: now ch.23 is going through all the 256 dmx values during the fade and also the relative ch.26 is affected by the "previous issue" described above.
qlc+4.12.6

You need to set the file channel to coarse

Finally I understood the issue, shall we mark it solved and change the title to "attention to MSB/LSB"?

Done

and thanks for the appimage update, I was waiting for some of your last commits to be able to try v.5 on the stage.