In #9440 the video streaming failed for some cameras and the
bunny example RTSP streaming movie. This worked in 4.0.6 and it
did not work anymore in 4.1.0. The same unstable behaviour is
observed in #10396.
The gstreamer rtsp source will
switch to tcp when no data is received via udp after 5 seconds.
The default timeout for the gstreamer video receiver is 2 seconds
resulting in a permanent teardown and restart until
eventually some data is received. As far as I understood the code
4.0.6 did not have a timeout which is in 4.1.0. I change the
timeout for RTSP to 8 seconds and leave it at 2 seconds for the
other streams. With 8 seconds timeout I can receive the bunny
example without problems.
Closes: #9440
`apt` complains loudly:
WARNING: apt does not have a stable CLI interface. Use with caution in scripts.
We can use `apt-get` instead to avoid this warning.
When building on the master branch, the android keystore password
is available. Building on a pullrequest or in a forked repository,
the android keystore password is not available.
With the current build structure the "package" directory is
created twice when the android keystore password is available
resulting in a clash and build failure.
I changed the build structure such that correct builds are
created for the two cases with and without the android keystore
password.
* install and use NDK r21e
* update QT install action from v2 to v3
Starting with NDK Version r24 llvm will not accept one-dash
long options anymore. This is bug QTBUG-104580
https://bugreports.qt.io/browse/QTBUG-104580
The r23c NDK version did not work due to issues with
stripping symbols. So I install and use r21e. QT 5.15.2 uses
gradle version 5.6.4 with the default android gradle plugin 3.6.0.
With gradle 6.9.2 and android gradle plugin 4.2.2 the 32bits
build worked. NDK r22b is not compatible with gstreamer 1.18 and
results in a failing 64bit build. Therefore r21e is required for
gstreamer support.
Closes: #10360
The Android build on CI failed with the following error
message:
../../qgroundcontrol/qgroundcontrol/src/QtLocationPlugin/QGCTileCacheWorker.cpp:510:21: error: variable 'tileCount' set but not used [-Werror,-Wunused-but-set-variable]
221
quint64 tileCount = 0;
The tileCount variable is not used. I removed the variable.
The compilation on MacOS stops with the following compile error:
/Users/fritz/searchwing/qgroundcontrol/src/Vehicle/Actuators/Actuators.cc:431:26: error: loop variable 'parameterJson' is always a copy because the range of type 'QJsonArray' does not return a reference [-Werror,-Wrange-loop-analysis]
for (const auto& parameterJson : parameters) {
"QNmeaPositionInfoSource supports reporting the accuracy of the
horizontal and vertical position. To enable position accuracy reporting
an estimate of the User Equivalent Range Error associated with the NMEA
source must be set with setUserEquivalentRangeError."
Source: https://doc.qt.io/qt-6/qnmeapositioninfosource.html#details
Commit 2a9ecabad8 introduced new behaviour
that broke use of external GPS. This change fixes the problem reported
in https://github.com/mavlink/qgroundcontrol/issues/10271.
Currently when adding a hostname in string form for tcp connection,
resolving to IP is done immediately, and in case of an error
the host is not stored and used default one instead.
Also the ip might be not known when adding the config, but hostname is known,
which also might be not resolvable at time when the config is being created.
Since hostName in QAbstractSocket::connectToHost
may be an IP address in string form (e.g., "43.195.83.32"),
or it may be a host name (e.g., "example.com").
QAbstractSocket will do a lookup only if required.
So suggesting to totally remove resolving of ip from TCPLink.
Resolving will be performed in QTcpSocket::connectToHost() when actual connection is requested.
Friedrich Beckmann
David Lechner
Beat Küng
Mathieu Mirmont
PX4BuildBot
JaeyoungLim
T. Herzog
lss
lss
Philipp Borgers
Akash Patel
David Jablonski
Val Doroshchuk
aib
Tzuriel Lampner
Tzuriel Lampner
Holden
bnsgeyer
Vasily Evseenko