hdfs auditlog add remote port info

Description of PR
In order to locate the problem more conveniently， hdfs auditlog should add remote port info.
How was this patch tested?
test the hdfsaduitlog,  it will log remote port info

:broken_heart: -1 overall

Vote
Subsystem
Runtime
Logfile
Comment

+0 :ok:
reexec
0m 37s

Docker mode activated.

_ Prechecks _

+1 :green_heart:
dupname
0m  0s

No case conflicting files found.

+0 :ok:
codespell
0m  1s

codespell was not available.

+0 :ok:
detsecrets
0m  1s

detect-secrets was not available.

+1 :green_heart:
@author
0m  0s

The patch does not contain any @author tags.

+1 :green_heart:
test4tests
0m  0s

The patch appears to include 3 new or modified test files.

_ trunk Compile Tests _

+1 :green_heart:
mvninstall
39m 17s

trunk passed

+1 :green_heart:
compile
1m 27s

trunk passed with JDK Ubuntu-11.0.18+10-post-Ubuntu-0ubuntu120.04.1

+1 :green_heart:
compile
1m 20s

trunk passed with JDK Private Build-1.8.0_362-8u362-ga-0ubuntu1~20.04.1-b09

+1 :green_heart:
checkstyle
1m  8s

trunk passed

+1 :green_heart:
mvnsite
1m 32s

trunk passed

+1 :green_heart:
javadoc
1m  8s

trunk passed with JDK Ubuntu-11.0.18+10-post-Ubuntu-0ubuntu120.04.1

+1 :green_heart:
javadoc
1m 33s

trunk passed with JDK Private Build-1.8.0_362-8u362-ga-0ubuntu1~20.04.1-b09

+1 :green_heart:
spotbugs
3m 30s

trunk passed

+1 :green_heart:
shadedclient
22m 48s

branch has no errors when building and testing our client artifacts.

_ Patch Compile Tests _

+1 :green_heart:
mvninstall
1m 16s

the patch passed

+1 :green_heart:
compile
1m 17s

the patch passed with JDK Ubuntu-11.0.18+10-post-Ubuntu-0ubuntu120.04.1

+1 :green_heart:
javac
1m 17s

the patch passed

+1 :green_heart:
compile
1m 14s

the patch passed with JDK Private Build-1.8.0_362-8u362-ga-0ubuntu1~20.04.1-b09

+1 :green_heart:
javac
1m 14s

the patch passed

+1 :green_heart:
blanks
0m  0s

The patch has no blanks issues.

-0 :warning:
checkstyle
0m 52s
/results-checkstyle-hadoop-hdfs-project_hadoop-hdfs.txt
hadoop-hdfs-project/hadoop-hdfs: The patch generated 7 new + 143 unchanged - 0 fixed = 150 total (was 143)

+1 :green_heart:
mvnsite
1m 21s

the patch passed

+1 :green_heart:
javadoc
0m 51s

the patch passed with JDK Ubuntu-11.0.18+10-post-Ubuntu-0ubuntu120.04.1

+1 :green_heart:
javadoc
1m 30s

the patch passed with JDK Private Build-1.8.0_362-8u362-ga-0ubuntu1~20.04.1-b09

+1 :green_heart:
spotbugs
3m 14s

the patch passed

+1 :green_heart:
shadedclient
22m 19s

patch has no errors when building and testing our client artifacts.

_ Other Tests _

-1 :x:
unit
206m 49s
/patch-unit-hadoop-hdfs-project_hadoop-hdfs.txt
hadoop-hdfs in the patch passed.

+1 :green_heart:
asflicense
0m 51s

The patch does not generate ASF License warnings.

314m 17s

Reason
Tests

Failed junit tests
hadoop.hdfs.server.namenode.TestFsck

hadoop.hdfs.server.datanode.TestDirectoryScanner

hadoop.hdfs.server.namenode.TestAuditLogger

hadoop.hdfs.server.namenode.TestAuditLogs

Subsystem
Report/Notes

Docker
ClientAPI=1.42 ServerAPI=1.42 base: https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-5544/1/artifact/out/Dockerfile

GITHUB PR
https://github.com/apache/hadoop/pull/5544

Optional Tests
dupname asflicense compile javac javadoc mvninstall mvnsite unit shadedclient spotbugs checkstyle codespell detsecrets

uname
Linux c9a7af6faf4e 4.15.0-206-generic #217-Ubuntu SMP Fri Feb 3 19:10:13 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/bin/hadoop.sh

git revision
trunk / 1c6403afe93d99f4935375fe5fb32f8767fb9541

Default Java
Private Build-1.8.0_362-8u362-ga-0ubuntu1~20.04.1-b09

Multi-JDK versions
/usr/lib/jvm/java-11-openjdk-amd64:Ubuntu-11.0.18+10-post-Ubuntu-0ubuntu120.04.1 /usr/lib/jvm/java-8-openjdk-amd64:Private Build-1.8.0_362-8u362-ga-0ubuntu1~20.04.1-b09

Test Results
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-5544/1/testReport/

Max. process+thread count
3735 (vs. ulimit of 5500)

modules
C: hadoop-hdfs-project/hadoop-hdfs U: hadoop-hdfs-project/hadoop-hdfs

Console output
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-5544/1/console

versions
git=2.25.1 maven=3.6.3 spotbugs=4.2.2

Powered by
Apache Yetus 0.14.0 https://yetus.apache.org

This message was automatically generated.

:broken_heart: -1 overall

Vote
Subsystem
Runtime
Logfile
Comment

+0 :ok:
reexec
0m 55s

Docker mode activated.

_ Prechecks _

+1 :green_heart:
dupname
0m  0s

No case conflicting files found.

+0 :ok:
codespell
0m  1s

codespell was not available.

+0 :ok:
detsecrets
0m  1s

detect-secrets was not available.

+1 :green_heart:
@author
0m  0s

The patch does not contain any @author tags.

+1 :green_heart:
test4tests
0m  0s

The patch appears to include 3 new or modified test files.

_ trunk Compile Tests _

+1 :green_heart:
mvninstall
38m  3s

trunk passed

+1 :green_heart:
compile
1m 25s

trunk passed with JDK Ubuntu-11.0.18+10-post-Ubuntu-0ubuntu120.04.1

+1 :green_heart:
compile
1m 22s

trunk passed with JDK Private Build-1.8.0_362-8u362-ga-0ubuntu1~20.04.1-b09

+1 :green_heart:
checkstyle
1m  6s

trunk passed

+1 :green_heart:
mvnsite
1m 30s

trunk passed

+1 :green_heart:
javadoc
1m  7s

trunk passed with JDK Ubuntu-11.0.18+10-post-Ubuntu-0ubuntu120.04.1

+1 :green_heart:
javadoc
1m 36s

trunk passed with JDK Private Build-1.8.0_362-8u362-ga-0ubuntu1~20.04.1-b09

+1 :green_heart:
spotbugs
3m 25s

trunk passed

+1 :green_heart:
shadedclient
22m 39s

branch has no errors when building and testing our client artifacts.

_ Patch Compile Tests _

+1 :green_heart:
mvninstall
1m 18s

the patch passed

+1 :green_heart:
compile
1m 19s

the patch passed with JDK Ubuntu-11.0.18+10-post-Ubuntu-0ubuntu120.04.1

+1 :green_heart:
javac
1m 19s

the patch passed

+1 :green_heart:
compile
1m 11s

the patch passed with JDK Private Build-1.8.0_362-8u362-ga-0ubuntu1~20.04.1-b09

+1 :green_heart:
javac
1m 11s

the patch passed

+1 :green_heart:
blanks
0m  0s

The patch has no blanks issues.

-0 :warning:
checkstyle
0m 52s
/results-checkstyle-hadoop-hdfs-project_hadoop-hdfs.txt
hadoop-hdfs-project/hadoop-hdfs: The patch generated 7 new + 143 unchanged - 0 fixed = 150 total (was 143)

+1 :green_heart:
mvnsite
1m 20s

the patch passed

+1 :green_heart:
javadoc
0m 50s

the patch passed with JDK Ubuntu-11.0.18+10-post-Ubuntu-0ubuntu120.04.1

+1 :green_heart:
javadoc
1m 24s

the patch passed with JDK Private Build-1.8.0_362-8u362-ga-0ubuntu1~20.04.1-b09

+1 :green_heart:
spotbugs
3m 18s

the patch passed

+1 :green_heart:
shadedclient
22m 32s

patch has no errors when building and testing our client artifacts.

_ Other Tests _

-1 :x:
unit
246m 56s
/patch-unit-hadoop-hdfs-project_hadoop-hdfs.txt
hadoop-hdfs in the patch passed.

+1 :green_heart:
asflicense
0m 49s

The patch does not generate ASF License warnings.

353m  4s

Reason
Tests

Failed junit tests
hadoop.hdfs.server.namenode.TestFsck

hadoop.hdfs.server.namenode.TestAuditLogger

hadoop.hdfs.TestRollingUpgrade

hadoop.hdfs.server.datanode.TestDirectoryScanner

hadoop.hdfs.server.namenode.TestAuditLogs

hadoop.hdfs.server.namenode.ha.TestObserverNode

Subsystem
Report/Notes

Docker
ClientAPI=1.42 ServerAPI=1.42 base: https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-5544/3/artifact/out/Dockerfile

GITHUB PR
https://github.com/apache/hadoop/pull/5544

Optional Tests
dupname asflicense compile javac javadoc mvninstall mvnsite unit shadedclient spotbugs checkstyle codespell detsecrets

uname
Linux f27bf9a14596 4.15.0-206-generic #217-Ubuntu SMP Fri Feb 3 19:10:13 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/bin/hadoop.sh

git revision
trunk / 1c6403afe93d99f4935375fe5fb32f8767fb9541

Default Java
Private Build-1.8.0_362-8u362-ga-0ubuntu1~20.04.1-b09

Multi-JDK versions
/usr/lib/jvm/java-11-openjdk-amd64:Ubuntu-11.0.18+10-post-Ubuntu-0ubuntu120.04.1 /usr/lib/jvm/java-8-openjdk-amd64:Private Build-1.8.0_362-8u362-ga-0ubuntu1~20.04.1-b09

Test Results
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-5544/3/testReport/

Max. process+thread count
2705 (vs. ulimit of 5500)

modules
C: hadoop-hdfs-project/hadoop-hdfs U: hadoop-hdfs-project/hadoop-hdfs

Console output
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-5544/3/console

versions
git=2.25.1 maven=3.6.3 spotbugs=4.2.2

Powered by
Apache Yetus 0.14.0 https://yetus.apache.org

This message was automatically generated.

:broken_heart: -1 overall

Vote
Subsystem
Runtime
Logfile
Comment

+0 :ok:
reexec
0m 49s

Docker mode activated.

_ Prechecks _

+1 :green_heart:
dupname
0m  0s

No case conflicting files found.

+0 :ok:
codespell
0m  1s

codespell was not available.

+0 :ok:
detsecrets
0m  1s

detect-secrets was not available.

+1 :green_heart:
@author
0m  0s

The patch does not contain any @author tags.

+1 :green_heart:
test4tests
0m  0s

The patch appears to include 4 new or modified test files.

_ trunk Compile Tests _

+1 :green_heart:
mvninstall
40m 48s

trunk passed

+1 :green_heart:
compile
1m 29s

trunk passed with JDK Ubuntu-11.0.18+10-post-Ubuntu-0ubuntu120.04.1

+1 :green_heart:
compile
1m 22s

trunk passed with JDK Private Build-1.8.0_362-8u362-ga-0ubuntu1~20.04.1-b09

+1 :green_heart:
checkstyle
1m  5s

trunk passed

+1 :green_heart:
mvnsite
1m 30s

trunk passed

+1 :green_heart:
javadoc
1m  8s

trunk passed with JDK Ubuntu-11.0.18+10-post-Ubuntu-0ubuntu120.04.1

+1 :green_heart:
javadoc
1m 31s

trunk passed with JDK Private Build-1.8.0_362-8u362-ga-0ubuntu1~20.04.1-b09

+1 :green_heart:
spotbugs
3m 37s

trunk passed

+1 :green_heart:
shadedclient
25m 35s

branch has no errors when building and testing our client artifacts.

_ Patch Compile Tests _

+1 :green_heart:
mvninstall
1m 19s

the patch passed

+1 :green_heart:
compile
1m 22s

the patch passed with JDK Ubuntu-11.0.18+10-post-Ubuntu-0ubuntu120.04.1

+1 :green_heart:
javac
1m 22s

the patch passed

+1 :green_heart:
compile
1m 14s

the patch passed with JDK Private Build-1.8.0_362-8u362-ga-0ubuntu1~20.04.1-b09

+1 :green_heart:
javac
1m 14s

the patch passed

+1 :green_heart:
blanks
0m  0s

The patch has no blanks issues.

-0 :warning:
checkstyle
0m 54s
/results-checkstyle-hadoop-hdfs-project_hadoop-hdfs.txt
hadoop-hdfs-project/hadoop-hdfs: The patch generated 7 new + 168 unchanged - 0 fixed = 175 total (was 168)

+1 :green_heart:
mvnsite
1m 22s

the patch passed

+1 :green_heart:
javadoc
0m 52s

the patch passed with JDK Ubuntu-11.0.18+10-post-Ubuntu-0ubuntu120.04.1

+1 :green_heart:
javadoc
1m 27s

the patch passed with JDK Private Build-1.8.0_362-8u362-ga-0ubuntu1~20.04.1-b09

+1 :green_heart:
spotbugs
3m 31s

the patch passed

+1 :green_heart:
shadedclient
25m 47s

patch has no errors when building and testing our client artifacts.

_ Other Tests _

-1 :x:
unit
221m 58s
/patch-unit-hadoop-hdfs-project_hadoop-hdfs.txt
hadoop-hdfs in the patch passed.

+1 :green_heart:
asflicense
0m 41s

The patch does not generate ASF License warnings.

336m 50s

Reason
Tests

Failed junit tests
hadoop.hdfs.server.namenode.TestAuditLogger

hadoop.hdfs.server.namenode.TestFsck

hadoop.hdfs.server.datanode.TestDirectoryScanner

Subsystem
Report/Notes

Docker
ClientAPI=1.42 ServerAPI=1.42 base: https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-5544/4/artifact/out/Dockerfile

GITHUB PR
https://github.com/apache/hadoop/pull/5544

Optional Tests
dupname asflicense compile javac javadoc mvninstall mvnsite unit shadedclient spotbugs checkstyle codespell detsecrets

uname
Linux 10e62e4415f5 4.15.0-206-generic #217-Ubuntu SMP Fri Feb 3 19:10:13 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/bin/hadoop.sh

git revision
trunk / 3d404024085b41edcfb830f193d132220ba49937

Default Java
Private Build-1.8.0_362-8u362-ga-0ubuntu1~20.04.1-b09

Multi-JDK versions
/usr/lib/jvm/java-11-openjdk-amd64:Ubuntu-11.0.18+10-post-Ubuntu-0ubuntu120.04.1 /usr/lib/jvm/java-8-openjdk-amd64:Private Build-1.8.0_362-8u362-ga-0ubuntu1~20.04.1-b09

Test Results
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-5544/4/testReport/

Max. process+thread count
2420 (vs. ulimit of 5500)

modules
C: hadoop-hdfs-project/hadoop-hdfs U: hadoop-hdfs-project/hadoop-hdfs

Console output
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-5544/4/console

versions
git=2.25.1 maven=3.6.3 spotbugs=4.2.2

Powered by
Apache Yetus 0.14.0 https://yetus.apache.org

This message was automatically generated.

:broken_heart: -1 overall

Vote
Subsystem
Runtime
Logfile
Comment

+0 :ok:
reexec
0m 34s

Docker mode activated.

_ Prechecks _

+1 :green_heart:
dupname
0m  0s

No case conflicting files found.

+0 :ok:
codespell
0m  1s

codespell was not available.

+0 :ok:
detsecrets
0m  1s

detect-secrets was not available.

+1 :green_heart:
@author
0m  0s

The patch does not contain any @author tags.

+1 :green_heart:
test4tests
0m  0s

The patch appears to include 3 new or modified test files.

_ trunk Compile Tests _

+0 :ok:
mvndep
15m 27s

Maven dependency ordering for branch

+1 :green_heart:
mvninstall
25m 35s

trunk passed

+1 :green_heart:
compile
23m 12s

trunk passed with JDK Ubuntu-11.0.18+10-post-Ubuntu-0ubuntu120.04.1

+1 :green_heart:
compile
20m 40s

trunk passed with JDK Private Build-1.8.0_362-8u362-ga-0ubuntu1~20.04.1-b09

+1 :green_heart:
checkstyle
3m 47s

trunk passed

+1 :green_heart:
mvnsite
3m 25s

trunk passed

+1 :green_heart:
javadoc
2m 27s

trunk passed with JDK Ubuntu-11.0.18+10-post-Ubuntu-0ubuntu120.04.1

+1 :green_heart:
javadoc
2m 40s

trunk passed with JDK Private Build-1.8.0_362-8u362-ga-0ubuntu1~20.04.1-b09

+1 :green_heart:
spotbugs
6m 10s

trunk passed

+1 :green_heart:
shadedclient
22m 58s

branch has no errors when building and testing our client artifacts.

_ Patch Compile Tests _

+0 :ok:
mvndep
0m 28s

Maven dependency ordering for patch

+1 :green_heart:
mvninstall
2m 20s

the patch passed

+1 :green_heart:
compile
22m 38s

the patch passed with JDK Ubuntu-11.0.18+10-post-Ubuntu-0ubuntu120.04.1

+1 :green_heart:
javac
22m 38s

the patch passed

+1 :green_heart:
compile
20m 39s

the patch passed with JDK Private Build-1.8.0_362-8u362-ga-0ubuntu1~20.04.1-b09

+1 :green_heart:
javac
20m 39s

the patch passed

+1 :green_heart:
blanks
0m  0s

The patch has no blanks issues.

-0 :warning:
checkstyle
3m 40s
/results-checkstyle-root.txt
root: The patch generated 9 new + 335 unchanged - 0 fixed = 344 total (was 335)

+1 :green_heart:
mvnsite
3m 23s

the patch passed

+1 :green_heart:
javadoc
2m 18s

the patch passed with JDK Ubuntu-11.0.18+10-post-Ubuntu-0ubuntu120.04.1

+1 :green_heart:
javadoc
2m 42s

the patch passed with JDK Private Build-1.8.0_362-8u362-ga-0ubuntu1~20.04.1-b09

+1 :green_heart:
spotbugs
6m 15s

the patch passed

+1 :green_heart:
shadedclient
23m 19s

patch has no errors when building and testing our client artifacts.

_ Other Tests _

+1 :green_heart:
unit
18m 19s

hadoop-common in the patch passed.

-1 :x:
unit
204m 24s
/patch-unit-hadoop-hdfs-project_hadoop-hdfs.txt
hadoop-hdfs in the patch passed.

+1 :green_heart:
asflicense
1m 13s

The patch does not generate ASF License warnings.

438m 35s

Reason
Tests

Failed junit tests
hadoop.hdfs.server.namenode.TestFsck

hadoop.hdfs.server.namenode.TestAuditLogger

hadoop.hdfs.server.namenode.TestAuditLogs

Subsystem
Report/Notes

Docker
ClientAPI=1.42 ServerAPI=1.42 base: https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-5544/2/artifact/out/Dockerfile

GITHUB PR
https://github.com/apache/hadoop/pull/5544

Optional Tests
dupname asflicense compile javac javadoc mvninstall mvnsite unit shadedclient spotbugs checkstyle codespell detsecrets

uname
Linux 070c94a22087 4.15.0-206-generic #217-Ubuntu SMP Fri Feb 3 19:10:13 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/bin/hadoop.sh

git revision
trunk / 0e475b9d7e3c14b7c0ea16d8b96328ec7a92fbae

Default Java
Private Build-1.8.0_362-8u362-ga-0ubuntu1~20.04.1-b09

Multi-JDK versions
/usr/lib/jvm/java-11-openjdk-amd64:Ubuntu-11.0.18+10-post-Ubuntu-0ubuntu120.04.1 /usr/lib/jvm/java-8-openjdk-amd64:Private Build-1.8.0_362-8u362-ga-0ubuntu1~20.04.1-b09

Test Results
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-5544/2/testReport/

Max. process+thread count
3951 (vs. ulimit of 5500)

modules
C: hadoop-common-project/hadoop-common hadoop-hdfs-project/hadoop-hdfs U: .

Console output
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-5544/2/console

versions
git=2.25.1 maven=3.6.3 spotbugs=4.2.2

Powered by
Apache Yetus 0.14.0 https://yetus.apache.org

This message was automatically generated.


Add fault documentation

Moved the FMECA spreadsheet from freeflyer_docs to the doc folder. Also added documentation on how to add faults and modified the generate faults config script to account for the FMECA being moved.

It looks like it is generated from the csv file... can we not just save the csv file in the repo? Having code generated from Excel spreadsheets terrifies me

We have decided that the FMECA should be converted to a json file much like our command schema. The tools that process the FMECA spreadsheet will also need to be converted.

Katie would still like to do this, and may have time early in 2024. If not we should close this.


Minimap: 2x1 font has too many irregularities

Take the following code (ITextModel in editorCommon):

Today it looks like this in the minimap with the 2x1 font:

2x1 minimap zoomed in 400%:

Editor screenshot scaled down to 200px width and zoomed in 400%:

Notice, for example, the gray comments: in the scaled down version they have a lot less irregularities in terms of brightness.
The minimap font should have "a more consistent brightness".

Will be fixed by https://github.com/microsoft/vscode/pull/82265


Please pass in a languageVersion to DartFormatter()

This package uses dart_style's library API in discoveryapis_generator/lib/src/utils.dart. In dart_style 2.7.3, we added an optional parameter to let you pass in a language version. In the upcoming 3.0.0 version of dart_style, that parameter will become mandatory.
When possible, please update this package to pass in a language version. If you always just want to format using the latest version, you can pass in languageVersion: DartFormatter.latestLanguageVersion.
Thanks!

Fixed (by @munificent ) in e7ae6b27ad412d9a858935a88b28297ff548cdc4


New version: Jackett.Jackett version 0.20.363.0

Installation timed out.
Auto-updated by vedantmgoyal2009/winget-pkgs-automation in workflow run 1865
Microsoft Reviewers: Open in CodeFlow

@wingetbot waivers Add Policy-Test-2.7


Ignore current_run directories

Ignore the current_run directories, which contain runtime files that should never be committed.

/LGTM
/Approved


Add asset_type field to the assets structures

This PR adds the asset_type field to the assets to make it possible to identify what the assets contain.

Approving to unblock: tests failing though


App launches but says "Loading..." indefinitely

Running on Mac OS X version 10.11.6
Keybase GUI Version: 1.0.17-20160829110024+c4e8dc8

Rebooting fixed the problem


The page is not found while loading cdn url. https://maxcdn.bootstrapcdn.com/font-awesome/4.7.0/css/font-awesome.min.css.

20 / 100 times, on doing cache refresh. The page is not being able to be fetched. Also, after hitting url, I need to refresh the page twice to get the content back again.
Not font awesome issue <---- https://github.com/FortAwesome/Font-Awesome/issues/13262

@solution7 Can you please fill out this form so we can debug the issue? https://goo.gl/forms/u2SFZS44ZGIM7yP82


switch to kernel 6.1.63

Base was taken from cloud-hypervisor 6.1.6, with the following changes made via make menuconfig:

General setup:

Kernel compression mode = ZSTD
Default hostname = 'neonvm'
CPU/Task time and stats accounting

Pressure stall information tracking (Y)

Compile standard kernel features (expert users) * Include all symbols in kallsyms (Y)

Power management and ACPI options:

Hibernation (aka 'suspend to disk') (N)

Virtualization:

KVM for AMD processors support (Y)

File systems:

CD-ROM/DVD Filesystems: * ISO 9660 CDROM file system support (Y)

Device drivers:

Character devices: * Enable TTY * Support for variants of the 16550A serial port (Y)

Used 6.1.2 for now, even though CH has 6.2 because 6.1.x has long-term support whereas the others don't.
Currently not working:

Hotplug
logging in via screen /dev/pts/0

Haven't tested migration.
Tested via scripts/ssh-into-vm.sh and various other pieces appear to be working.

@sharnoff
I changed the kernel version to the latest in the stable long-term branch - 6.1.63. The config was created from the current version 5.15.80. The kernel build Dockerfile has been updated to use Ubuntu:23.10 as the build environment.
e2e tests passed (autoscaling and migration), screen /dev/ps/0 works well.
Details about creating a 6.1.63 kernel configuration:
# use 5.15.80 config as base
cp ../linux-config-5.15.80 .config

# create config for 6.1.63
make menuconfig # just save and exit
make menuconfig
    # set VIRTIO_IOMMU
    -> Device Drivers
      -> IOMMU Hardware Support (IOMMU_SUPPORT [=y])
        -> Virtio IOMMU driver (VIRTIO_IOMMU [=y])

    # set KALLSYMS_ALL
    -> General setup
      -> Configure standard kernel features (expert users) (EXPERT [=y])
        -> Load all symbols for debugging/ksymoops (KALLSYMS [=y])
          -> Include all symbols in kallsyms (KALLSYMS_ALL [=y])

make mod2noconfig

Ok, tested on staging (ref), this seems to fix neondatabase/neon#5678. Going to merge and cut a new release.


Is there anything like 'rt-else'?

Using rt-if we can render elements based on a condition.
Is there anything like rt-else to render something else if the condition is not met?

no, there isn't, I guess because the resulting syntax would be not so intuitive. An hypothetical rt-else would have to refer to its upper sibiling node, which is unusual in HTML.
When I have to write "else branches", I just use an if-not:
<dif rt-if="cond()">then branch

<dif rt-if="!cond()">else branch

if you are concerned about the condition being evaluated twice (in case it's slow etc):
<virtual rt-scope="cond() as c">
   <dif rt-if="c">then branch

   <dif rt-if="!c">else branch

</virtual>

Thanks for the answer @nippur72

When I have to write "else branches", I just use an if-not

Yes, that what I ended up doing. It's not so bad for simple stuff.


fix: remove lorem ipsum from collection page

Description
Removes what looks to be placeholder lorem ipsum on the /collection page. Not 100% sure what that page is intended to be, so leaving rest as is.
Came into help channel as hero request by someone who noticed it.
Screenshot(s)
Before

After

build succeeded but didn't communicate back to github for whatever reason.
https://www.gatsbyjs.com/dashboard/34e708d2-68a1-48ca-b66f-d2604890b061/sites/570cbeb2-6e69-41e8-9358-25ec20d4bbe3/builds/27280247-86a2-4101-8807-5f4ca38c00cc/details


feat:proper badge theme use for server list

Summary
While fixing issue with https://github.com/mattermost/mattermost-mobile/pull/8312, there has been a few changes to the badge in the server list requested by @asaadmahmood.
Ticket Link

Checklist

[ ] Added or updated unit tests (required for all new features)
[X] Has UI changes
[ ] Includes text changes and localization file updates
[ ] Have tested against the 5 core themes to ensure consistency between them.
[ ] Have run E2E tests by adding label E2E iOS tests for PR.

Device Information
This PR was tested on: iPhone 15 Simulator, 17.4.1
Screenshots

Release Note

For comparison, this is Quartz before fix:

@rahimrahman the Denim and Sapphire themes look good in the screenshots. However, Quartz, Onyx, and Indigo aren't quite right. They should not have blue borders surrounding the badge and the badge background and number should follow the button colors.
It looks like you're using the right theme color variables in the code, but the screenshots aren't showing right. They should look like this:

@rahimrahman the Denim and Sapphire themes look good in the screenshots. However, Quartz, Onyx, and Indigo aren't quite right. They should not have blue borders surrounding the badge and the badge background and number should follow the button colors.
It looks like you're using the right theme color variables in the code, but the screenshots aren't showing right. They should look like this:

@matthewbirtch I have a question.
Why if the code is exactly the same for all themes, some look ok but others don't?
Cause as far as I can see there is no specific code based on the theme.

@matthewbirtch I have a question.
Why if the code is exactly the same for all themes, some look ok but others don't?
Cause as far as I can see there is no specific code based on the theme.

@enahum @rahimrahman is it possible the screenshots are just old? They don't match with what is applied in code.
My comment was just based on the screenshots, but I can spin up a build and test that to confirm

@matthewbirtch sorry, I think I screwed up my screenshot with a different branch.  This is the correct one:

The 1px borderWidth change requested might need/should get reverted.  It's too skinny IMO.

Back to 2px borderWidth

Monokai & Organization:

@matthewbirtch @asaadmahmood I don't think there's much to test here other than what's already been displayed in a few screenshots.
Should we skip QA Review?

should be good to merge. It'll be tested during code freeze.


Add inline comments to clarify code

This should make it easier to understand for other people reading the code.

This code is generated from the jison parser generator -- https://github.com/SlexAxton/Jed/blob/master/plurals.jison


Update index.js

fixed bug

@yyhaxx what bug exactly are you fixing with this PR?

when we navigate 'ConfirmMnemonics' page, we can't find the 'mnemonic'.I think we use componentDidMount in 'ConfirmMnemonics' cause such result. I replace it with componentWillMount;
Another problem is that when we  press 'Confirm & open wallet' button it can't find the 'walletName' and the 'walletDescription' states. I think we should get them from the 'props.navigation.state.params' first. so  I did it.

  componentWillMount() {
        const { mnemonics, walletName, walletDescription } = this.props.navigation.state.params;
        this.setState({ mnemonics, walletName, walletDescription });
    }

    @autobind
    async onPressConfirm() {
        if (!this.refs.confirm.isValidSequence()) return;
        try {
            const wallet = WalletUtils.loadWalletFromMnemonics(this.state.mnemonics);
            const walletName = this.state.walletName;
            const walletDescription = this.state.walletDescription;
            await WalletsActions.addWallet(walletName, wallet, walletDescription);
            this.props.navigation.navigate('WalletsOverview', { replaceRoute: true });
            await WalletsActions.saveWallets();
        } catch (e) {
            console.warn(e);
        }
    }


<?xml version="1.0" encoding="utf-8"?>
<profile>
    <!-- profile name - Default -->
    <name lang="mogz">Kris</name>

<!-- Common MKV flags -->
    <mkvSettings
        ignoreForcedSubtitlesFlag="false"
        useISO639Type2T="false"
        setFirstAudioTrackAsDefault="true"
        setFirstSubtitleTrackAsDefault="false"
        setFirstForcedSubtitleTrackAsDefault="false"
        insertFirstChapter00IfMissing="true"
    />

    <!-- Settings overridable in preferences -->
    <profileSettings
        app_DefaultSelectionString="-sel:all,+sel:(favlang|nolang|single),-sel:(havemulti|havecore),-sel:mvcvideo,=100:all,-10:favlang"
    />

    <!-- Output formats currently supported by MakeMKV -->
    <outputSettings name="copy" outputFormat="directCopy">
        <description lang="eng">Copy track as is</description>
        <description lang="ger">Track 1:1 kopieren</description>
    </outputSettings>

    <outputSettings name="lpcm" outputFormat="LPCM-raw">
        <description lang="eng">Save as raw LPCM</description>
        <description lang="ger">Als RAW LPCM speichern</description>
    </outputSettings>

    <outputSettings name="wavex" outputFormat="LPCM-wavex">
        <description lang="eng">Save as LPCM in WAV container</description>
        <description lang="ger">Als LPCM im WAV-Container speichern</description>
    </outputSettings>

    <outputSettings name="flac-best" outputFormat="FLAC">
        <description lang="eng">Save as FLAC (best compression)</description>
        <description lang="ger">Als FLAC speichern (höchste Komprimierungsstufe)</description>
        <extraArgs>-compression_level 12</extraArgs>
    </outputSettings>

    <outputSettings name="flac-fast" outputFormat="FLAC">
        <description lang="eng">Save as FLAC (fast compression)</description>
        <extraArgs>-compression_level 5</extraArgs>
    </outputSettings>

    <!-- Default rule - copy as is -->
    <trackSettings input="default">
        <output outputSettingsName="copy"
                defaultSelection="$app_DefaultSelectionString">
        </output>
    </trackSettings>

    <!-- Save LPCM mono or stereo as raw LPCM -->
    <trackSettings input="LPCM-stereo">
        <output outputSettingsName="lpcm"
                defaultSelection="$app_DefaultSelectionString">
        </output>
    </trackSettings>

    <!-- Put multi-channel LPCM into WAVEX container-->
    <trackSettings input="LPCM-multi">
        <output outputSettingsName="wavex"
                defaultSelection="$app_DefaultSelectionString">
        </output>
    </trackSettings>

</profile>

@khaosx You're thinking about this even harder that I do. :)
The main benefit to letting MakeMKV covert lossless audio (i.e. DTS-HD, TrueHD, etc.) to FLAC format when your rip is that every tool out there can decode it. It's only been since version 1.2.0 that HandBrake could actually decode DTS-HD instead just using the lossy DTS core behind your back and not telling you.
So your audio is not portable for transcoding because it's in FLAC format, it's portable because it's lossless. It's just that FLAC format is currently required to guarantee that it's lossless.
In a perfect world we could just leave all the lossless tracks in our rips in their original formats. But we ain't in that perfect world yet.
As long as you have lossless audio then you've future-proofed your transcoding process. And it doesn't really matter how many channels it has or how many channels you transcode it to. You have flexibility.
And if you don't have lossless audio then if it's in AC-3 format you have the option to just copy that sucker! If it's DTS, then it's probably at such a high bitrate that it might as well be lossless. So don't lose any sleep when you transcode that.
What I would avoid is copying your lossless audio into your transcoded output because, guess what, your audio track will probably then be as big or even bigger than your video track. And that's just.. crazy.

@vr8hub ...

don't think you people are paying attention. The Rubicon has been crossed! The ship has sailed! The bridge has been burned! We are all members of a club that requires "crazy" to join. I am still a pledgling, true, but that particular requirement required no effort on my part.

 :)
And bonus points for the Billy Joel serenade. :)

@khaosx @vr8hub I'm pretty sure you can just untar that profile, right?

@donmelton Yes, it's now the only way to grab the profiles now. Took me forever to figure out where it lived last time I reinstalled. I had a setup script that modified the default profile for me on a system rebuild, and it suddenly starting barfing garbage because it didn't know where the profile was to modify.

It's only been since version 1.2.0 that HandBrake could actually decode DTS-HD instead just using the lossy DTS core behind your back and not telling you.

Oh good.  Glad to hear I can flush that cache.

What I would avoid is copying your lossless audio into your transcoded output because, guess what, your audio track will probably then be as big or even bigger than your video track. And that's just.. crazy.

LOL - You know, yesterday I would have cheerfully ignored this (like the last time we had this conversation). Today, I'm on board!

@donmelton Yes, absolutely, that's what I did so I could see what the built-in profiles looked like. It just took me a lot of searching to find out the profiles were in that file. I searched the entire application directory, and I looked in ~/Library/MakeMKV (which is where I expected them to be), and … nothing. I never expected to find them in a .tar file. (I'd love to hear the logic on that one. No I wouldn't.)

@khaosx BTW, even though HandBrake and FFmpeg can decode DTS-HD properly now, that doesn't mean all the other tools out there can, e.g. Plex and god knows what else.  :) Trust me, I've had hundreds work for me over the years. And, to be honest, I'm engaged in the same dumbassery on occasion. Occupational hazard. :)

@khaosx LOL - You know, yesterday I would have cheerfully ignored this (like the last time we had this conversation). Today, I'm on board!

Hmmmm again. The profile you just posted only has entries for LPCM. I thought that meant everything else was used the default rule, i.e. copy as is. Doesn't that mean that TrueHD and DTS-HD get copied using that profile instead of converted to FLAC? The built-in FLAC profile has entries for TrueHD and DTS-HD to do the conversion to FLAC. Am I misunderstanding how the profile entries work?

Dammit. Apparently Plex stutters dynamically transcoding even 5.1 AAC audio, at least on my underpowered Synology DS214play. It never has a problem transcoding 5.1 AC-3 or E-AC-3. Go figure.
Does anyone else have this issue?
BTW, this is yet another reason I prefer transcoding to stereo AAC in DPL2 format. It never has to be dynamically transcoded by Plex!

@donmelton

@khaosx BTW, even though HandBrake and FFmpeg can decode DTS-HD properly now, that doesn't mean all the other tools out there can, e.g. Plex and god knows what else. So I plan on continuing to rip my lossless audio to FLAC for awhile longer.

Oh, FYI - Plex is going to update FFmpeg to latest in the next release of PMS (1.15, IIRC). I'm waiting on that right now to turn on HW support on Linux. Right now, Plex can encode but not decode using the GPU with h.264 and h.265. Looks like VC-1 will also get HW decoding when they release. It's in beta right now, but some folks on the Plex forums have written a wrapper (similar to the one that nVidia released to allow HW passthrough in docker containers) that forces Plex to use the updated FFmpeg binary.
for HW

@vr8hub

Hmmmm again. The profile you just posted only has entries for LPCM. I thought that meant everything else was used the default rule, i.e. copy as is. Doesn't that mean that TrueHD and DTS-HD get copied using that profile instead of converted to FLAC? The built-in FLAC profile has entries for TrueHD and DTS-HD to do the conversion to FLAC. Am I misunderstanding how the profile entries work?

Nope, you're exactly correct. TrueHD and DTS-HD get copied as-is.

@khaosx Hardware decoding for VC-1? I really wish that was available on macOS for HandBrake and FFMpeg. How can I tell? Try a hardware-based video encoder on a H.264 file and then a VC-1 file. BIG DIFFERENCE! It's almost twice as slow.

@khaosx Hmmm a third time. And here I thought from my reading that the consensus was that ripping to FLAC was the way to go.  What are the plusses/minuses for copying those as-is vs converting them to FLAC in the initial "backup" (i.e. not the transcoded) .mkv? ( know, it's not a true backup, but that's the way I think of it.)

@donmelton

@khaosx Hardware decoding for VC-1? I really wish that was available on macOS for HandBrake and FFMpeg. How can I tell? Try a hardware-based video encoder on a H.264 file and then a VC-1 file. BIG DIFFERENCE! It's almost twice as slow.

As I tell everyone that asks me if they should switch: "If everything you do can be done the way Apple says is best, then yes. You will have an unparalleled experience. If you deviate one angstrom from the flight-plan, bring lube."

@khaosx To their credit, they're trying to make the way VideoToolbox works transparent whether it's on macOS or iOS. But, yeah, lube. :)

@vr8hub
It's a busy thread today. Everyone wanted to play, and my wife is still out of town, so I'm sitting on a pile of waste-able time!
Here's the relevant comment from an hour ago, or so:

@khaosx You're thinking about this even harder that I do. :)
The main benefit to letting MakeMKV covert lossless audio (i.e. DTS-HD, TrueHD, etc.) to FLAC format when your rip is that every tool out there can decode it. It's only been since version 1.2.0 that HandBrake could actually decode DTS-HD instead just using the lossy DTS core behind your back and not telling you.
So your audio is not portable for transcoding because it's in FLAC format, it's portable because it's lossless. It's just that FLAC format is currently required to guarantee that it's lossless.
In a perfect world we could just leave all the lossless tracks in our rips in their original formats. But we ain't in that perfect world yet.
As long as you have lossless audio then you've future-proofed your transcoding process. And it doesn't really matter how many channels it has or how many channels you transcode it to. You have flexibility.
And if you don't have lossless audio then if it's in AC-3 format you have the option to just copy that sucker! If it's DTS, then it's probably at such a high bitrate that it might as well be lossless. So don't lose any sleep when you transcode that.
What I would avoid is copying your lossless audio into your transcoded output because, guess what, your audio track will probably then be as big or even bigger than your video track. And that's just.. crazy.

So, in the end, Don is going to keep doing FLAC, I'm not re-ripping, and you're weapons-free for either format :)

@khaosx Well, I read that. Along with everything else, including your comment that I quoted. That's what confused me; I thought you had been "converted" to FLAC, too. But I now see that that was on the transcode, not the rip. I'll work on my reading comprehension.

Holy, I step away for 90 minutes so I can continue to be gainfully employed...
@vr8hub @khaosx
Don and I are using the word "portable" differently, which doesn't help. I'll modify my use. As I understand it, Don likes FLAC because it is lossless and preserves the quality. My motivation is that FLAC is commonly supported (and lossless), so as my circumstances evolve over time, I can safely assume that whatever I am working with will be able to read and, if necessary, transcode the FLAC lossless source.

Kodi plays my uncompressed source files with FLAC wonderfully.
transcode-video / HB converts it as needed without issue.

I did not notice that handbrake 1.2.0 brought support for DTS-HD, that reduces some of my motivation, but also makes the point that an open and widely adopted standard will remove challenges in the future.
@donmelton
That is surprising about the dynamic audio transcoding on the 214Play, maybe AAC math is really hard...
As a bonus kick in teeth about VideoToolbox, here is the second line in the tech specs section of the data sheet:

Hardware Transcoding Engine: Yes (Hardware Transcoding Video Codec: H.264 (AVC), MPEG-4 Part 2, MPEG-2, VC-1)

So the DiskStation has some VC-1 hardware encode/decode support. Yikes.

@klogg416 That's teach you to have a job. :)

Kodi plays my uncompressed source files with FLAC wonderfully.

Yes, it does. Including subtitles that are tagged as forced.

Apparently that takes a LOT of compute cycles because my other Plex server is an iMac (busy doing nothing but running Plex) and it still stutters on occasion. #firstworldproblems

That is surprising about the dynamic audio transcoding on the 214Play, maybe AAC math is really hard...

I guess, huh! I mean, AAC has been around almost as long as AC-3. You would think the equations have been solved by now.

So the DiskStation has some VC-1 hardware encode/decode support. Yikes.

You mean my DiskStation? That would be nice, of course, but I never try to dynamically transcode video with it. With audio this dodgy, why lean into a punch? :)

Yes, it does. Including subtitles that are tagged as forced.

What'choo talkin bout, Willis? Is this a client specific thing on your Roku boxes, or are you saying this is systemic across your whole client base? I've had every conceivable problem someone can have with subs (they are, in fact, the reason why I started re-ripping back in August), and this isn't something I've seen.

BTW, did anyone notice this in NEWS file for HandBrake 1.2.1 which was released this week:

Fixed channel mapping for AAC 5.1 encoding (signal 5.1 Back instead of 5.1 Side which is less compatible)

Does anyone know any background on this? Which, BTW, I understand was, more or less, picking up a change from FFmpeg.

@khaosx It's a systemic problem with Plex, unfortunately. Have you ever looked at your choices within "Settings?" You only get:

Manually selected
Shown with foreign audio
Always enabled

...but nothing to automatically select forced tracks. Really inconvenient.

@donmelton

So the DiskStation has some VC-1 hardware encode/decode support. Yikes.
You mean my DiskStation? That would be nice, of course, but I never try to dynamically transcode video with it. With audio this dodgy, why lean into a punch? :)

I do indeed. It took 2 seconds of Googling to learn that the 214Play lacked the grunt to even transcode 720p videos reliably, but the timing was too good not to mention.

Fixed channel mapping for AAC 5.1 encoding (signal 5.1 Back instead of 5.1 Side which is less compatible)

I don't have info on that, but 10 years ago I had an NVIDIA ION based HTPC (Atom + tiny NVIDIA GPU) that had a hardware AAC mapping mix up which meant all the channels came out of the wrong speakers. There was a hidden Kodi system config where you could remap and reverse the problem, but nothing says joy like having C routed to SB. Sounds like FFmpeg introduced their own take on it...

@donmelton and as I proof read after hitting comment, I see that they even added the detail that they were using L C R, S[ide]L, S[ide]R, instead of what they should be using, L C R S[urround]L and S[urround]R. Basically rears out of speakers 6 and 7, not 4 and 5.
Does that make sense? Am I answering the wrong question?

@klogg416 ...

I don't have info on that, but 10 years ago I had an NVIDIA ION based HTPC (Atom + tiny NVIDIA GPU) that had a hardware AAC mapping mix up which meant all the channels came out of the wrong speakers. There was a hidden Kodi system config where you could remap and reverse the problem, but nothing says joy like having C routed to SB. Sounds like FFmpeg introduced their own take on it...
and as I proof read after hitting comment, I see that they even added the detail that they were using L C R, S[ide]L, S[ide]R, instead of what they should be using, L C R S[urround]L and S[urround]R. Basically rears out of speakers 6 and 7, not 4 and 5.
Does that make sense? Am I answering the wrong question?

That actually makes perfect sense! And you're totally answering the question!
I do remember that whacky-ass setting in Kodi and just thanked the Lords of Kobol (nerd alert!) that I never had to enable it!
 Ugh.

@donmelton
OK, good deal. I think it has a history of popping up and getting solved rather than a persistent existence. I blame the people who settled on the acronyms SR and SR to distinguish between Side Right and Surround Right. That is begging for problems. Complicated by when 6.1 came out it was a rear center, but 7.1 adds two sides instead of two "farther backs."
I love me some surround, but GD is it a mess to keep tabs on. Everything behind the front plane is surprisingly unintuative.

@klogg416 ...

I love me some surround, but GD is it a mess to keep tabs on.

Don't get me started on Dolby Atmos and "objects." :)

@donmelton

@khaosx It's a systemic problem with Plex, unfortunately. Have you ever looked at your choices within "Settings?" You only get:

Manually selected
Shown with foreign audio
Always enabled

...but nothing to automatically select forced tracks. Really inconvenient.

So, mine is set to "shown with foreign audio". I just went through the first 10 movies I found with forced subs, and all of them are set for the forced subs track and display as expected...weird!

@donmelton

Don't get me started on Dolby Atmos and "objects." :)

I read quickly about how Atmos worked, likened it to the very clever Aureal 3D in the '90s with their object driven real time surround calculations (before Creative Labs was tired of losing market share, crushed the stock price and bought them for patents and we all got the very meh Live 5.1! cards. Fun fact, video games were the original transcoding.), and then closed the tab assuming I knew everything that was necessary.

@khaosx Yeah, that works when the audio is not tagged as English, i.e. my preferred language. For example, "Crouching Tiger, Hidden Dragon (2000)" works fine that way. But it doesn't work when the audio is English, like in "Star Wars (1977)" or "Iron Man (2008)" or half a hundred other titles I have.
But Kodi handles this fine. Because they're not trying to be clever and mix and match between language designations. They're just looking at the "forced" tag.

@klogg416 Yep, you know everything you need to know about Atmos now. :)

@donmelton
I'm seeing the opposite, I think. Maybe a comparison will help?
From "Air Force One", encoded with t-v from retail Blu-Ray direct rip:
Audio #1
ID                                       : 2
Format                                   : MLP FBA
Format/Info                              : Meridian Lossless Packing FBA
Commercial name                          : Dolby TrueHD
Codec ID                                 : A_TRUEHD
Duration                                 : 2h 4mn
Bit rate mode                            : Variable
Maximum bit rate                         : 3 762 Kbps
Channel(s)                               : 6 channels
Channel layout                           : L R C LFE Ls Rs
Sampling rate                            : 48.0 KHz
Frame rate                               : 1 200.000 fps (40 SPF)
Compression mode                         : Lossless
Title                                    : Surround
Language                                 : English
Default                                  : Yes
Forced                                   : No

Audio #2
ID                                       : 3
Format                                   : AAC LC
Format/Info                              : Advanced Audio Codec Low Complexity
Codec ID                                 : A_AAC-2
Duration                                 : 2h 4mn
Channel(s)                               : 2 channels
Channel layout                           : L R
Sampling rate                            : 48.0 KHz
Frame rate                               : 46.875 fps (1024 SPF)
Compression mode                         : Lossy
Delay relative to video                  : -44ms
Title                                    : Stereo
Language                                 : English
Default                                  : No
Forced                                   : No

Text #1
ID                                       : 4
Format                                   : PGS
Codec ID                                 : S_HDMV/PGS
Codec ID/Info                            : Picture based subtitle format used on BDs/HD-DVDs
Duration                                 : 1h 41mn
Language                                 : English
Default                                  : Yes
Forced                                   : Yes

Text #2
ID                                       : 5
Format                                   : PGS
Codec ID                                 : S_HDMV/PGS
Codec ID/Info                            : Picture based subtitle format used on BDs/HD-DVDs
Duration                                 : 1h 57mn
Language                                 : English
Default                                  : No
Forced                                   : No

@khaosx OK, I'll try it again. Maybe Plex changed the behavior recently.  :)
I've been playing with the new API , specifically --keep-ac3-stereo (which is freakin' awesome!), and it occurred to me that it might be useful to add an argument to that option which retains AC-3 stereo only in a certain track width or format.
Here's an example of why...
Let's say I make my main track surround width and leave my other tracks stereo width. And that I'm using those other tracks for commentary (you know, just talking) so I want them to be as small as possible, preferring them to always be transcoded to 160 Kbps or less. But I still want my main track to copy all AC-3 audio, which it won't do without the --keep-ac3-stereo option. But that will be applied globally so my stereo commentary tracks will also retain AC-3.
This wouldn't be a problem if those stereo AC-3 tracks were always 192 or even 224 Kbps.
But I started looking through my video library and realized I have some stereo AC-3 commentary tracks that are as big as 640 freakin' Kbps! ("Twelve Monkeys (1995)" is one example.) Which really seems like a waste of space, right? :)
So, what if we added a "scope" argument to --keep-ac3-stereo like all|surround|stereo to facilitate this?
And the reason I ask now is that I can't add an argument later without breaking the API for users then.
What do you think?

@donmelton I''m not sure I understand, --keep-ac3-stereo surround reads a little funny to me and it's not immediately clear to me what that would do

@samhutchins Yeah, it does sound funny and not in the amusing way. But basically that would only keep AC-3 stereo format tracks in surround widths and not affect stereo widths. Maybe I should have included double as a choice in there too? Not sure if that would have helped.
Obviously the nomenclature I suggested sucks mightily so I'm open to ideas for how to explain that better. :)
BTW, this scoping behavior I'm suggesting is not hard at all to implement. Just really damn hard to describe.

@donmelton Well, it seems that the scoping thing is a bitrate thing? Could the argument be a maximum bitrate to pass?

@samhutchins That could work but in my example scenario I really only want the behavior in the main track, no matter what the input bitrate is.

@samhutchins OK, I've decided that it's not worth worrying about modifying the --keep-ac3-stereo option now and there's probably a way to solve the scenario I described yesterday without such a radical change in the future. Besides, I can't think of a decent syntax for it now. :) So let's table that.
But, before I pull the trigger on this very audio-focused release, do we want to also consider changing the default mixdown for stereo tracks from dpl2 to stereo now, as @dkoenig01 suggested? Because I'm a lot more open to that than I've sounded in comments here. :)
In fact, I think it's inevitable that we phase out DPL2 with the adoption of smaller and better (at least smaller and better than AC-3) discrete surround formats like E-AC-3 and multichannel AAC.
Hell, I'm even open to making the default surround format E-AC-3 eventually. :) Obviously I still love DPL2 for its size and portability, but 384 Kbps E-AC-3 is only twice the size, sounds much better and portability keeps improving every day.
So, do we pull the bandaid off and switch the mixdown default now? I mean, Sam, the way you designed the code it's a freakin' one-line change so it's pretty easy. :)

@samhutchins @dkoenig01 Or, do we wait on changing the mixdown default before we get more feedback? Again, I think it is inevitable but maybe we shouldn't be hasty until a lot more of us get a say about it.

@donmelton Depends on what you want the default audio width to be. If it's double, I'd change the stereo mixdown to stereo, otherwise I'd leave it as dpl2 personally. If someone does --audio-width main=stereo for a bunch of rips, then get's a surround capable system later they can still have surround audio without re-doing the rip. It's not as good, but it's better than nothing. Plus I've not come across any situations in the wild where the stereo image sounds wrong.
On the other hand, I guess the more conservative thing is make the default mixdown for stereo stereo, which is I guess more honest and isn't ever going to have the panning problem DPL2 has.

@samhutchins So, you are of two minds about it as well. :)
Yes, setting the stereo track in a double width to a true stereo mixdown instead of dpl2 seems safe since you also have the same audio there in a true discrete multichannel format. But I think it's complicated explaining to the user that other stereo conversions in surround and stereo widths default to a dpl2 mixdown. Even though that is sensible to you and I. :)
Then there's the problem of changing the mixdown if we defaulted it to some hybrid configuration like that. Do we introduce a new split or mixed argument for the --mixdown option to describe that default?
So it's complicated. :)
Then there's the other problem that now, after prodding by @dkoenig01, I'm beginning to hear some of the imaging and panning problems that folks have been complaining about with DPL2 as I rigorously review my own transcodings. And, sadly, these are noticeable when listening with surround or stereo systems.
Certainly these issues and artifacts don't happen all the time but it's now impossible to un-hear them. I blame @dkoenig01 for this. :)
Anyway, I agree that the conservative and safe thing to do is change the default mixdown to stereo. The question is, do we do it right now?

@samhutchins OK, I decided not to change the --mixdown default now. :)
Just gem update to get version 0.24.0.
Thanks again for the new features, Sam!
And thanks to @khaosx, @rhapsodians, @damorrison, @vr8hub, @dkoenig01, @klogg416 and everyone else I forgot to mention for all your feedback on this one! Y'all rock!

I'm closing this issue since the feature has been released but feel free to keep commenting here until we open some new audio issues to cover all the other cans of worms we opened. :)

Well, having just said that I'd not come across anything that sounded funny with dpl2 in the wild, I've just come across something that sounds funny. Opening sequence to Baby Driver is really far right in my dpl2 stereo track when using headphones

@samhutchins Ouch! Sorry if ruined DPL2 for you.
I don't have "Baby Driver (2017)" but I've notice that shift of rear channel audio (I think) to the right when listening with stereo headphones on too damn many other titles now. It's really obvious (and annoying AF!) on "Annihilation (2018)" at the beginning.
Worse is when audio effects sometimes shift back and forth in rapid succession between right and left. Because I can notice that listening both on stereo headphones and with my 5.1 surround system.
Again, you can't un-hear any of this.
So I'm in the process of re-transcoding all of my titles again. You could do the same and give yourself an even better excuse for switching to --avbr. :)
Seriously, I think we really do need to switch the default for --mixdown now. I'll open an issue soon proposing that, probably today.
I'll also open separate issues proposing an expanded syntax for --mixdown and another proposing we change the the default encoder and bitrate for surround tracks to eac3, i.e. Dolby Digital Plus or E-AC-3, at 384 Kbps.
I really am re-transcoding all my main title audio to E-AC-3 at 384 Kbps because:

It solves the DPL2 problems we're hearing.
Using Plex on the Roku attached to my big 5.1 surround system passes it through unchanged.
Plex dynamically mixing it down and transcoding it to stereo on my other systems still sounds great.
Plex dynamically transcoding it to 5.1 AC-3 still sounds really damn good (essentially transparent) because it's doing that at 640 Kbps.
Roku and Apple both consider that even E-AC-3 at 192 Kbps sufficient for multichannel 5.1 audio so 384 Kbps is probably overkill and just good insurance.
384 Kbps is still only a little over twice the size of two-channel AAC so it takes just 5-6% the size of your output instead of 10% or more like 640 Kbps.
Roku and Apple both consider E-AC-3 just as good as AC-3 at half the bitrate and after a lot of testing this weekend, I would have to agree.
E-AC-3 is getting hardware adoption a LOT faster than multichannel AAC.

So, if you do decide to redo your library (again) then I would recommend it.

While I genuinely love my
Sonos it does make me shake my fist at its support for new audio formats.
It’s a 5.1 ac3 only for me as nothing else will work (well dpl2 is
supported but I want a discreet 5.1). With all the recent changes to audio,
I’ve been following along to see if I need to change anything and so far
not. But the proposed change to eac3 would as sonos will say nooo.
We’ve discussed how dlp2 sounds on a 5.1, but are there views on if you
only have 5.1 and listen to it in just stero? Use case is listening to a
movie with a Dolby digital 5.1 on an iPad.
On Mon, 25 Feb 2019 at 19:51, Don Melton<EMAIL_ADDRESS>wrote:

@samhutchins https://github.com/samhutchins Ouch! Sorry if ruined DPL2
for you.
I don't have "Baby Driver (2017)" but I've notice that shift of rear
channel audio (I think) to the right when listening with stereo headphones
on too damn many other titles now. It's really obvious (and annoying AF!)
on "Annihilation (2018)" at the beginning.
Worse is when audio effects sometimes shift back and forth in rapid
succession between right and left. Because I can notice that listening both
on stereo headphones and with my 5.1 surround system.
Again, you can't un-hear any of this.
So I'm in the process of re-transcoding all of my titles again. You could
do the same and give yourself an even better excuse for switching to
--avbr. :)
Seriously, I think we really do need to switch the default for --mixdown
now. I'll open an issue soon proposing that, probably today.
I'll also open separate issues proposing an expanded syntax for --mixdown
and another proposing we change the the default encoder and bitrate for
surround tracks to eac3, i.e. Dolby Digital Plus or E-AC-3, at 384 Kbps.
I really am re-transcoding all my main title audio to E-AC-3 at 384 Kbps
because:

It solves the DPL2 problems we're hearing.
Using Plex on the Roku attached to my big 5.1 surround system passes
it through unchanged.
Plex dynamically mixing it down and transcoding it to stereo on my
other systems still sounds great.
Plex dynamically transcoding it to 5.1 AC-3 still sounds really damn
good (essentially transparent) because it's doing that at 640 Kbps.
Roku and Apple both consider that even E-AC-3 at 192 Kbps sufficient
for multichannel 5.1 audio so 384 Kbps is probably overkill and just good
insurance.
384 Kbps is still only a little over twice the size of two-channel
AAC so it takes just 5-6% the size of your output instead of 10% or more
like 640 Kbps.
Roku and Apple both consider E-AC-3 just as good as AC-3 at half the
bitrate and after a lot of testing this weekend, I would have to agree.
E-AC-3 is getting hardware adoption a LOT faster than multichannel
AAC.

So, if you do decide to redo your library (again) then I would
recommend it.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/donmelton/video_transcoding/issues/254#issuecomment-467157527,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAYJDdF-sc1B8BvrQ1wzzQDiNJo9BeDUks5vRD7FgaJpZM4a6UAF
.

--
Kind regards,
Dave

I distinctly remember someone recently telling me "take the defaults, they're all you need". If only I could remember who that was…

What does the above command-line look like? (I see both --ac3-bitrate and --pass-ac3-bitrate options, but can find no info on the difference, so I'm not sure which would be used.)
How is Plex "doing that at 640Kbps" if only 384Kbps is available in the source? (I searched around for info on Plex's transcoding and didn't find something that looked like the answer to this.)
If (2nd bullet) Plex passes the multi-channel unchanged, why (4th bullet) would Plex need to transcode it to a different multi-channel format? Oh, wait, is that because system #1 can handle EAC3 and system #2 can only handle AC3? Yes, probably so. Never mind, move along, nothing to see here…

@damorrison Great feedback and thanks!
While I'll open a proposal about moving to E-AC-3 as the default for surround, I doubt we actually do that right away. I just want to get feedback, like yours, on this early so we can weigh the risks.

We’ve discussed how dlp2 sounds on a 5.1, but are there views on if you only have 5.1 and listen to it in just stero? Use case is listening to a movie with a Dolby digital 5.1 on an iPad.

Good question! If you use a versatile player like Infuse.app or VLC.app which can decode many multichannel audio formats, you'll just get a nice, smart stereo mixdown of that audio without transcoding it. If you use TV.app, or whatever the native Apple-supplied player is, then you'll get the same behavior, like the other players, but limited to AC-3 and E-AC-3 formats.
But keep in mind that if you use wireless earphones, such as AirPods like I do, then it's possible that audio, any audio really, might be transcoded behind your back (or, technically, your ear. :) ).

@vr8hub ...

I distinctly remember someone recently telling me "take the defaults, they're all you need". If only I could remember who that was…

Well played, sir. Well played. :)
OK, on to your great questions:

The command line I'm using includes --ac3-encoder eac3 --ac3-bitrate 384 in it. I don't include --pass-ac3-bitrate because I want to continue allowing audio up to 640 Kbps AC-3 and E-AC-3 to be copied without transcoding unchanged.

When Plex has to transcode any non-AC-3 5.1 audio, it seems to always use 640 Kbps (or thereabouts) for that even if the original is at a lower bitrate. That's because 640 Kbps is about as transparent as AC-3 is ever going to get.

Yes. Plex knows what the target system can handle so it only transcodes when necessary. And the Roku does a good job (most of the time) of telling Plex what the system it's connected to is capable of.

Anything else?

@donmelton
Well, I think I am going to re-do the library. Which sucks, because I don't have the hard drive space anywhere to keep the originals (well, I could fill the NAS but I'd rather not). Plus a lot of my library came from DVDs at my parents house, and re-ripping all those would suck...
In any case, I can't trust my AAC track any more, so a do-over is inevitable.
See you on the other side

@donmelton

And here I thought I couldn't possibly be more confused. I thought the option was setting the output rate. Are you saying the --ac3-bitrate 384 option ignores bitrates above 384 and just passes them through? What if the source is FLAC? Isn't the option telling it to encode that FLAC input as EAC3 output? (I know, I know, I should wait for the Wiki.)
Well, right, but encoding at 640Kbps is wasted if the input is 384. IOW, if the input is 384, it doesn't really matter what Plex is doing as long as it's doing it at 384+. (And how do you know what Plex is doing? Does it show that info in its log somwhere?)

I just read one of Plex's support documents on audio. They spent a lot of time saying, "Don't use passthrough". Which, even after reading it, doesn't make much sense to me. I don't want Plex determining what my audio is, I want to determine what my audio is. I'm going to a lot of trouble to get the audio right in the file. Why on earth wouldn't I want Plex to leave it alone? (Rhetorical question; this is not a Plex forum. Just an example of why poking myself in the eye with a stick might be less painful than trying to figure out all of this transcoding audio stuff.)

@donmelton
One more thing!
My set-up at home can't handle E-AC3 or (AFAIK) 5.1 AAC, so it's 640kbps AC3 for me for the forseeable future

@samhutchins ...

See you on the other side

The other side of madness, right? :)

My set-up at home can't handle E-AC3 or (AFAIK) 5.1 AAC, so it's 640kbps AC3 for me for the forseeable future

Yeah, a lot of users have similar setups so I doubt very seriously that we'll change the surround default soon. I just want to start getting feedback now.
@vr8hub ...

Go back and re-read what I wrote there. I think you're confusing --ac3-bitrate and pass-ac3-bitrate in that paragraph. To be clear, the --ac3-bitrate option sets the audio output bitrate. But it's the --pass-ac3-bitrate that sets the passthrough bitrate. And you'll probably never want to change the passthrough bitrate.

No, it's not wasted. If the input format has more efficient compression that the AC-3 format, and E-AC-3 is about twice as efficient as AC-3, then it makes sense to use 640 Kbps, that maximum bitrate for AC-3, when re-transcoding. And keep in mind that almost every audio format out there is more efficient than AC-3. It's even older and skankier than MP3.

I just read one of Plex's support documents on audio. They spent a lot of time saying, "Don't use passthrough". Which, even after reading it, doesn't make much sense to me. I don't want Plex determining what my audio is, I want to determine what my audio is. I'm going to a lot of trouble to get the audio right in the file. Why on earth wouldn't I want Plex to leave it alone? (Rhetorical question; this is not a Plex forum. Just an example of why poking myself in the eye with a stick might be less painful than trying to figure out all of this transcoding audio stuff.)

Which document? Because I'm pretty sure that's not the correct interpretation. :)
Plex usually refers to the equivalent of "passthrough" with terms like "direct play" and such. And they've always been helpful about how to avoid dynamic transcoding.

@donmelton I'm certainly confused, but I'm confused because I read what you wrote, not because I didn't read it. :) I know the options are different. My (perhaps mis-stated) question was to clarify how they interract with each other and with the input. Let me ask differently — what is the difference between the two? How are the two choosing what they're processing? To what kind of input do the two options apply? (Hence my "what if input is FLAC" question.)
I either convert the input audio to an output format, or I passthrough the input audio to an output format. I don't understand how (or why) I do both, which is what your statement sounded like what was happening. (But I'm confused, so that might not be what was meant at all.)

@vr8hub Oh! My bad. I misunderstood your question. Sorry about that.
The --ac3-bitrate option simply controls the output bitrate when transcoding surround sound audio, e.g. multichannel FLAC tracks in your input would be, by default, transcoded to AC-3 format at 640 Kbps. But you could add --ac3-encoder eac3 --ac3-bitrate 384 to your command line to transcode them to E-AC-3 format at 384 Kbps.
The --pass-ac3-bitrate option only considers AC-3 input (or AC-3 and E-AC-3 input if you used --ac3-encoder eac3). It ignores, for example, FLAC and all other audio formats when considering what is copied.

I either convert the input audio to an output format, or I passthrough the input audio to an output format. I don't understand how (or why) I do both, which is what your statement sounded like what was happening. (But I'm confused, so that might not be what was meant at all.)

Yes, and normally you don't need to screw around with the rules for when passthrough happens. Just trust transcode-video to do the right thing. Which hopefully it has been doing for you.
That recommendation for @samhutchins to try was about modifying the default conversion behavior (i.e. using those --ac3-encoder eac3 --ac3-bitrate 384 options and arguments).
Did that clear things up any?

@vr8hub BTW, here's the Plex support article describing the difference between "Direct Play," "Direct Stream" and "Transcode" and what those terms mean in their world:
https://support.plex.tv/articles/200430303-overview/

@donmelton So, --ac3-bitrate handles what isn't [e]ac3 in input, and pass-ac3-bitrate handles what is [e]ac3 in input. Got it, I think. So FLAC input is handled by --ac3-bitrate, while [e]ac3 input is handled by --pass-ac3-bitrate. Hmmm. But --aac-encoder is a different option that presumably handles AAC input. So does --ac3-bitrate just handle FLAC input?
And from your statement above, the # on --pass-ac3-bitrate says "pass through anything at this rate or below." What happens to an [e]ac3 input above that rate? Is it converted to the --pass-ac3-bitrate or the --ac3-bitrate rate?
(Forgot to mention, the Plex article was this one.

@vr8hub Sorry, it was dog and dinner time there for awhile. You know how it is. Anyway...

So, --ac3-bitrate handles what isn't [e]ac3 in input, and pass-ac3-bitrate handles what is [e]ac3 in input.

Yes, you've got it! And that's actually a simpler way to put it than I did. Thanks! I will steal verbatim, sir, for another support answer. :) Seriously, you're on a roll.

But --aac-encoder is a different option that presumably handles AAC input. So does --ac3-bitrate just handle FLAC input?

Great question! And the answer... uh... not exactly. :)
The default format for surround output is AC-3 so the --ac3-encoder option configures whether you get AC-3 or E-AC-3.
The default format for stereo output is AAC so the --aac-encoder option configures... which encoder to use in order to get that AAC output. It doesn't change the format, just the encoder.
And this silly option is necessary because on Windows and Linux, sometime folks don't want the FFmpeg AAC encoder. On macOS, it's a really bad idea to ever change the AAC encoder because the default, ca_aac (the prefix is for "Core Audio"), is probably the best AAC encoder in the world.
Anyway, that's not the only complication.
Remember the new --audio-format option? Well you can use that to make stereo output use AC-3 or E-AC-3 format. So, if you add --audio-format stereo=ac3 to your command line, then the --ac3-encoder option affects that too.

And from your statement above, the # on --pass-ac3-bitrate says "pass through anything at this rate or below." What happens to an [e]ac3 input above that rate? Is it converted to the --pass-ac3-bitrate or the --ac3-bitrate rate?

Unless you add --ac3-encoder eac3 to your command line, E-AC-3 input is treated just like FLAC, DTS, PCM, etc. Meaning that it will be transcoded.
But let's say you do add --ac3-encoder eac3 to your command line. Since the default passthrough bitrate is 640 Kbps, any E-AC-3 audio above that bitrate will also be transcoded. You would have to add --pass-ac3-bitrate 1536 to your command line to allow any E-AC-3 audio input to qualify for passthrough and be copied instead of transcoded.
Confusing?  :) But imagine what it's like to code this stuff.

(Forgot to mention, the Plex article was this one.)

Ah. OK, no wonder you got confused. :) That's the guide for the player, not the server.

@donmelton

Unless you add --ac3-encoder eac3 to your command line, E-AC-3 input is treated just like FLAC, DTS, PCM, etc. Meaning that it will be transcoded.

Right, I understood that (some things are so simple even I can get them). Without that option, eac3 would be transcoded to ac3. And with that option, ac3 is transcoded to eac3.

You would have to add --pass-ac3-bitrate 1536 to your command line to allow any E-AC-3 audio input to qualify for passthrough and be copied instead of transcoded.

Right, I also understood that (I know, twice in one day, it's kind of shocking to me, too). My question was that if the bitrate was higher than whatever was specified (or defaulted) on the --pass-ac3-bitrate option, what bitrate is it transcoded to? Does it use the --pass-ac3-bitrate ("convert anything above this pass-through rate to this rate"), or does it use the --ac3-bitrate ("convert anything above this pass-through rate to the --ac3-bitrate"). IOW, with --ac3-bitrate 384 --pass-ac3-bitrate 640, and a bitrate of 1536, is the 1536 transcoded to 384 or 640?
And a hearty thank you for your patience. I actually (somewhat) understand all of the various audios out here in the real world. (IOW, I know the difference between TrueHD and DTS and AC3, etc. as it comes to a receivers, Blu-ray, etc.) What I have no grasp at all of is how all of this is handled and transcoded and used and abused in the transcode world. In my Handbrake GUI days, I avoided the audio tab; it had something about AC-3 and something about passthrough, but I didn't understand it and left it alone. I maybe should leave it alone now, too (although again with all of the wonderful options), but I'm no longer content with not understanding it.

@vr8hub ...

Right, I understood that (some things are so simple even I can get them). Without that option, eac3 would be transcoded to ac3. And with that option, ac3 is transcoded to eac3.

Actually, AC-3 will not be transcoded to E-AC-3 unless it's above the passthrough bitrate. And since the default passthrough bitrate is 640 Kbps, that never happens, by default.
Why is that? Basically because anything that can play E-AC-3 can also play AC-3 so there's no reason to re-transcode it. (Actually there is one "ooops" device out there that can play E-AC-3 but stupidly not AC-3. However, the manufacturer is trying to kill it. So we will not speak of it again. :) )

My question was that if the bitrate was higher than whatever was specified (or defaulted) on the --pass-ac3-bitrate option, what bitrate is it transcoded to? Does it use the --pass-ac3-bitrate ("convert anything above this pass-through rate to this rate"), or does it use the --ac3-bitrate ("convert anything above this pass-through rate to the --ac3-bitrate"). IOW, with --ac3-bitrate 384 --pass-ac3-bitrate 640, and a bitrate of 1536, is the 1536 transcoded to 384 or 640?

D'oh! Sorry, I misunderstood. That happens a lot, unfortunately.
It uses the setting for the --ac3-bitrate option which, by default, is 640 Kbps. But if you add --ac3-bitrate 384 --pass-ac3-bitrate 640 to your command line then an input bitrate of 1536 Kbps is transcoded to 384 Kbps.

And a hearty thank you for your patience. I actually (somewhat) understand all of the various audios out here in the real world. (IOW, I know the difference between TrueHD and DTS and AC3, etc. as it comes to a receivers, Blu-ray, etc.) What I have no grasp at all of is how all of this is handled and transcoded and used and abused in the transcode world. In my Handbrake GUI days, I avoided the audio tab; it had something about AC-3 and something about passthrough, but I didn't understand it and left it alone. I maybe should leave it alone now, too (although again with all of the wonderful options), but I'm no longer content with not understanding it.

And a hearty "you're welcome" to you sir! No worries.
Answering questions like this just comes with the job of being the lone insane autocratic project leader of a small-ass utility. :)
And thank god you understand the differences between the formats! Many of our users struggle with that because, as you well know, it's forking complicated out there.
But you're asking all the right questions to understand how it's handled. And, like I said, I don't mind. If anything, it clarifies my own thinking about it.
So, since now is the winter of your discontent, keep asking. :)

@donmelton

I don't have "Baby Driver (2017)"

You should rectify that, for the opening 10 minutes if nothing else

@samhutchins OK, now you have me curious. :)


feat: Weapons need VFX. Add them.

We had a conversation of what criteria we will be following for when a weapon should be granted a VFX. This is what became of that:
Vip: The user of the weapon its applied to is a threat but not an issue that should be considered a priority for more than 2 players.
Beta Infected: The weapon its applied to is a big enough threat that no more than 4 players should consider it a prioriy. Even if its in the hands of a inexperienced player
Infected alpha: A threat to a whole team, even if the weapon is in the hands of a inexperienced player.
Using this criteria these weapons have been given a VFX
[20] Attack Off Iratus: Beta Infected
[40] Guard Off Doisac: Beta Infected
[27] Scout Skewer: VIP

Adjusted details of other VFX weapons as well to bring docs up to the current situation. Removed mention about traits being removed for certain weapons when out of ammo as we are not pursuing that anymore. Approved.


New sentences translated

Coverage remained the same at 56.909% when pulling 4ff601df17290efdf4aaebc59a144f0944b570e8 on GRT1979:master into ddf041614f358e514d852bed32d366b974105e40 on codecombat:master.


React to NATS backend config changes

Description
Changes proposed in this pull request:

...
...
...

Related issue(s)

/test all


Add ModelExperimentalType enum

Added an enum to label models so we know if it's a single glTF or if it's part of a 3D Tileset (and furthermore if it's a .b3dm, .pnts, .gltf, etc.). This will be useful both in #9978 and #9968
@sanjeetsuhag could you review?

Thanks for the pull request @ptrgags!

:heavy_check_mark: Signed CLA found.
:grey_question: CHANGES.md was not updated.

If this change updates the public API in any way, please add a bullet point to CHANGES.md.

Reviewers, don't forget to make sure that:

[ ] Cesium Viewer works.
[ ] Works in 2D/CV.

@sanjeetsuhag updated! I decided to make ModelExperimentalType private to minimize the API surface area.


Renamed functions  e.g. (plot_locations, join_locations) may need a soft deprecation process

We discussed options to keep old functions working and thought the roxygen tag #' @alias would do the trick, but after some careful digging, it looks like this only allows functions tagged with @alias to pull up a more current help file e.g  ?join_sites would pull up the more recent join_locations .Rd file.
I think its sensible and kind to keep the "old" functions e.g plot_site_locations and join_sites working.
I like the idea of this wrapper approach:
Would look something like this:
plot_site_locations <- function(XXX){
 .Deprecated("plot_locations", package = "austraits")
 [old function content]
}

plot_locations <- function(XXX){
[new function content]
}

Probably good to use lifecycle badges too
Thoughts? Happy to discuss in person!

I like the idea with the wrapper. Set it up to run, but only with the old version of the data.
A slight variant - write a new function that takes either the old of new data
plot_locations <- function(XXX){
[new function content]
# maybe include switch statement to make the old data work with new function

}

then
plot_site_locations <- function(XXX){
 .Deprecated("plot_locations", package = "austraits")
 plot_locations(XXX)
}

Haha! We have a similar line of thinking @dfalster I thought that would be a good idea too!
Unfortunately, its tricky to use the switch statement and call it within the old plot_site_locations
This is because:

plot_site_locations takes the traits table as an input
e.g

austraits_old <- load_austraits(version = "3.0.2", path = "ignore/data/austraits")
austraits_old %>% extract_dataset("Falster_2003") -> Falster_2003

Falster_2003 %>% join_all() %>% purrr::pluck("traits") %>%  plot_site_locations(feature = "trait_name")

Current approach with switch statements is to accept the entire austraits list as an input and switch based on version in austraits$build_info$version

austraits_new %>% extract_dataset("Crous_2013") -> Crous_2013
Crous_2013 %>% join_all() %>% plot_locations(feature = "basis_of_record")

Falster_2003 %>% join_all() %>% plot_locations(feature = "collection_type")

What I've done at the moment is to keep plot_site_locations alive but with deprecation statement but it doesn't pass its contents on to plot_locations because of point 2)
I think it is possible to implement what you are suggesting but may need a fresh pair of eyes and drawing things out together.
Also I think its  worth discussing whether our functions should be traits table focussed or object focussed. I am drawn to latter and keep it consistent across all functions.

Notes for Fonti to return to:
Have option to accept list or traits table?

if list and versions <= 3.0.2, isolate list and pass to plot_locations1

If we want to keep traits table as an input like the original function.

We can try switch on something else? ncol(traits) can tell us if its version <= 3.0.2 or not?


Second generic added to HoCs to be able to specify return type of props callback

Fixes #803

I didn't run dev-test since it causes a lot of changes. But it effectively generates what is needed. (like in issue mentioned)


Use new model in attacks code

After doing everything required to create a unified Model interface, the attacks don't actually use it. Make the existing attacks use it.

(This should be merged before my L2 attack.)

There is a flaky test causing this to fail that I fix in #198.

Thanks, I restarted the test

LGTM

I've rebased this branch, so to push I had to --force it. If you want I can just submit a new PR that's clean.

There is a problem with the rebase (one of the tests should not be there anymore). I pointed this out to Nicholas in real life and he says he'll take care of it later today.

Okay, tests are good now.


[Feature Request]: APNG Support

Describe the feature you'd like
It would be amazing if Bookstack could support animated PNG graphics.
Describe the benefits this feature would bring to BookStack users
Another supported format for animated graphics that has better color etc. than gif is useful IMHO.
Additional context
Currently the generated scaled version of uploaded images looses the animation when using apng.

hello i've a problem with this modules after update a last version MagicMirror with node.

hello i've a problem with this modules after update a last version MagicMirror with node.

Thanks for the request @paviro, I've made some changes in 31f1dca8a81e70aa8b5598fdaf4af772a28ac9c9 to better support apng images. The generated "display" thumbnails will now be bypassed for files detected as apng to serve the originally uploaded image. This is what we do already for GIFs although APNGs proved trickier due to having the same extension and mime as normal png images.
Note: this may not work with already-upload apng images, only new ones.
This will be part of the next patch release, v21.12.1 so will therefore close this off.
@mecco86 To be honest I'm not sure what you're referring to in regards to node or MagicMirror. Neither of those terms are in discussion here. Feel free to open a new support/bug-report issue if you're having a BookStack specific issue.

Awesome thank you very much @ssddanbrown for the quick addition!


when a date is already selected in input box, and user edit the same item then old dates can't be disabled

What is the expected behavior?
What is the current behavior?
What are the steps to reproduce?
Providing a StackBlitz reproduction is the best way to share your issue.
You can fork the demo on StackBlitz: https://stackblitz.com/github/dalelotts/angular-bootstrap-datetimepicker-demo
Which versions of angular-bootstrap-datetimepicker, OS, TypeScript, browsers are affected?
Is there anything else we should know?

i am using this in my event management site. When user create an event then older dates are disabled, but on same form, when user edit the same event then older dates are not disabled.

Please fill out the bug template completely and post an example of this behavior - as


Term.echo a line ending with closing bracket not shown

Expected behavior
Echoing multiline strings with a line ending with a closing bracket should work correctly.
Actual behavior
When I printed a multiline string with the first line ending with a closing square bracket, the first line didn't show, while the other lines did.
Steps to reproduce
term is an instance of the terminal.
term.echo(`haha [
123`);

Then only the second line 123 showed.
Browser and OS
Browser: Chrome 62.0.3202.94
OS: Linux Mint 18.2

Sorry, forget about this bug in version 1.11.0 will fix soon and it will be in version 1.11.1

The fix is in devel branch.

in version 1.11.1


Typo

Summary
Fixed typo in 'Notification'

@CalvinWilliams1012 I changed the target branch from "live" to "master".  (We use master for all work, and update the 'live' branch as part of the publish cycle, once the content in 'master' has been reviewed on an internal staging site.)
Did you pick 'live' as the target branch, or was it the default? I want to make sure we have the defaults configured correctly.

@BillWagner It was default when I used githubs "Fork this project and edit this file" button.


Adds or remove muted html5 video attribute on volume change

These changes allow autoplay on mobile devices when mute player option is set to true. (and playback playInline is set to true on iOS).
Thank you to @tomas2387 for original pull request #1260.
Example usage :
var player = new Clappr.Player({
  parentId: '#player-wrapper',
  source: 'http://clappr.io/highline.mp4',
  poster: 'http://clappr.io/poster.png',
  mute: true,
  autoPlay: true,
  playback: { playInline: true }, // Required only by iOS
  height: 360,
  width: 640
});

Requirements :

iOS version >= 10
Android with Chrome version >= 53

supersede #1260, should fixes #1314

Coverage increased (+0.02%) to 73.535% when pulling 776e2b635bccdb7e99fedd8a06aed13590574c9c on kslimani:feat-muted-autoplay into 59c905c0ddc7da227b50575a32ceadca0095a5ea on clappr:master.

Thank you @kslimani  🍰

BTW, note it seems to not work with HLS source. I will investigate why.

Coverage increased (+0.05%) to 73.561% when pulling 34c992449da9c5f4bb9203314935547b2c5f2ac0 on kslimani:feat-muted-autoplay into 59c905c0ddc7da227b50575a32ceadca0095a5ea on clappr:master.

Coverage decreased (-0.1%) to 73.383% when pulling 4f63afa35a3f44ad294d955a2588d08a003d1750 on kslimani:feat-muted-autoplay into f4449dd231692265dec1559a581a1e548a4fee92 on clappr:master.

Added a fix for HLS source on mobile devices.

@kslimani you rock! 🚀


Release Google.Cloud.Retail.V2 version 1.0.0

Changes in this release:
No API changes since 1.0.0-beta01.

Created release for Google.Cloud.Retail.V2-1.0.0

Created release for Google.Cloud.Retail.V2-1.0.0


generate_rolling_dataset with real dynamic features

I saw that there is a way to generate a rolling dataset in the master version. This is useful for me as I had to implement my own  a couple months ago and it was incredibly messy and I could not get the evaluator to work with my implementation.
Using the implementation in the master repo, without any dynamic features, the evaluator works with generate_rolling_datasets. When you add in dynamic features, although the resulting target is getting sliced shorter step_size every time, the associated dynamic features are not which gives you this error:
ValueError: all the input array dimensions except for the concatenation axis must match exactly

I was able to overcome this by cutting the dynamic features myself when I want to plot things, as shown below:
for i,train_dict in enumerate(dataset_rolled):
    feat_dynamic= train_dict['feat_dynamic_real']
    feat_dynamic_changed = feat_dynamic[:,:feat_dynamic.shape[1]-i * step_size]
    train_data = ListDataset([{"start": train_dict['start'], "target": train_dict['target'],
                               "feat_dynamic_real" : feat_dynamic_changed}],freq="1B")

   for test_entry, forecast in zip(train_data, predictor.predict(train_data)):
        to_pandas(test_entry).plot(linewidth=1, color='b', zorder=0, figsize=(13, 7))
        forecast.plot(color='g', prediction_intervals=prediction_intervals, show_mean=True, zorder=10)

However, I now want to get some metrics for my rolled dataset using this function call:
forecast_it, ts_it = make_evaluation_predictions(
        dataset_rolled, predictor=predictor, num_samples=100)
training_agg_metrics, _ = Evaluator(num_workers = 0)(ts_it, forecast_it)

This of course gives me the same error as above as (likely) the dynamic features is not being cut down. I tried to look into the _base.py code of the evaluator class but I am bit confused. I know that this is not in the stable version yet, but if someone can point to where in the evaluator code I can change, that would great.
Thank you for the great library and the rolling dataset implementation,
Cheers

Hi @GabrielDeza, thank you for the issue.
I have been looking into the issue and you are right, none of the feat_dynamic_real gets truncated when calling generate_rolling_dataset the same goes for the other feature vectors.
The lines which cause this are these.
I solved this on my local branch by truncating the lengths of the feat_dynamic_real to match the length of the target.

A fix for this was merged in #1392, @GabrielDeza is your problem solved and can I close the issue?

Yeah this fixed my problem, I'll close this issue. Thank you so much @arangatang for your help, this library is amazing :D

Are rolling datasets compatible with multivariate datasets (ie: datasets for models like DeepVAR or GPVAR)? I am trying to make it work but I am getting a dimensionality error and it would be great to know if this is a mistake in my implementation or not.


Update sample to reflect breaking changes introduced with Preview 14

References to "Native" have been renamed to "Platform", so now it is PlatformView instead of NativeView.
Also, the sample shows how to remove the underline from Android entry views for example. However, "EntryMapper" has been simplified to Mapper with .NET MAUI PR#4780.

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: 659665da-2ff3-3550-2e0c-20902c15c3e6
Version Independent ID: 70227b04-808f-1370-186b-10cfef525959
Content: .NET MAUI control customization with handlers - .NET MAUI
Content Source: docs/user-interface/handlers/customize.md
Product: dotnet-mobile
Technology: dotnet-maui
GitHub Login: @davidbritch
Microsoft Alias: dabritch

Fixed by https://github.com/dotnet/docs-maui/pull/390


PostgreSQL Task script shows Success status when its script file doesn't exist

System information:

Operating system (distribution) and version Win10
DBeaver version 7.3.5 EA
PostgreSQL

Steps to reproduce, if exist:

Save a script file somewhere
Create a script task with this script file
Delete the file
Execute the task

Expected: an error appears
Actual result: no errors, success status is displayed

Cannot reproduce:

Reproducible with external file.

Verified


certs: Sync with Mozilla bundle as of Oct 19, 2024

https://github.com/bagder/ca-bundle/commit/4d3fe6683f651d96be1bbef316b201e9b33b274d
Include certdata.txt as the original source for the processed data.
I'll cherry-pick this to all Godot branches, including EOL ones, which should resolve #98851.

Am I correctly understand that it will affect only git repo without affecting binary at all?

Am I correctly understand that it will affect only git repo without affecting binary at all?

There's two elements in this PR:

ca-certificates.crt is updated to a newer version, this affects binaries by removing outdated CA certificates and adding new valid ones.
certdata.txt is provided for documentation purposes and isn't used anywhere. It's just adding 1.5 MB of diff for the sake of satisfying a license claim I'm doubtful about, but heh /shrug

Actually I'll rework this, I'm having second thoughts about including a source file of cryptic data in our repo when we don't need it. Instead, I'll included the hash of the relevant Mozilla commit used by bagder in thirdparty/README.md.

Instead, I'll included the hash of the relevant Mozilla commit used by bagder in thirdparty/README.md.

Here’s a tip (since I had to find a bunch of these in order to add the table to the ca-bundle README): the most surefire way to find the hash is to go to here and then find the push that came right before the timestamp that’s in ca-certificates.crt. I had originally tried doing this with hg log instead of the pushlog, but it didn’t work well because some commits were made on one date but then pushed to the relevant branch on a later date. The pushlog is the way to go.

Cherry-picked for all Git branches (4.3, 4.2, 4.1, 4.0, 3.x, 3.6, 3.5, etc. down to 2.1, which is the first release with ca certificates).


github registration listener refactoring + tests

As promised in #286 this PR moves registration listener from closure in User\Module to separate listener class. There is both unit and integration test case to assure that listener is attached and registerViaProvider event triggered in ScnSocialAuth module.
I still have to find a way how to update existing local user profile from actual GitHub data after login.
@Ocramius could you please provide code review?

@lku
Needs a rebase, can you have a look?

@localheinz
Done. There was just a little conflict in User module config (because of switch to short array syntax).

Thank you, @lku!


Fix Dashboard XPaths for RHODS v1.20

Some changes in patternfly broke some test cases leveraging on Dashboard. This PR wants to fix the broken TCs

Jenkins job on v1.20: 1410 RUNNING
Jenkins job on v1.19: 1411 RUNNING


feat: add math/base/special/bernoullif

Progresses #649
Description

What is the purpose of this pull request?

adds math/base/special/bernoullif, which would be the single-precision equivalent for math/base/special/bernoullif.

float stdlib_base_bernoullif( const int32_t n )

Related Issues

Does this pull request have any related issues?

This pull request:

Progresses: #649

Questions

Any questions for reviewers of this pull request?

No.
Other

Any other information relevant to this pull request? This may include screenshots, references, and/or implementation notes.

No.
Checklist

Please ensure the following tasks are completed before submitting this pull request.

[x] Read, understood, and followed the contributing guidelines.

@stdlib-js/reviewers

@gunjjoshi This is not a problem exclusively with this PR, since it also applies to math/base/special/bernoulli, which you added in https://github.com/stdlib-js/stdlib/pull/1860, but I noticed that the implementation returns zero for all odd numbers. However, Wikipedia says that this is incorrect for input value 1: https://en.wikipedia.org/wiki/Bernoulli_number
Could you please take a look and confirm whether we need to handle this case separately?

@Planeshifter Thanks for catching this. After digging for some time, I found that there is a mix of opinions on whether B(1) = +1/2 or B(1) = -1/2. For instance, here is a discussion from sympy: https://github.com/sympy/sympy/issues/23866.
While it is incorrect to use B(1) = 0, the choice that must be made is between +1/2 or -1/2.
sympy now uses +1/2 (it used -1/2 earlier). There's a discussion at sagemath too: https://github.com/sagemath/sage/issues/34521.
Overall, I think, it would be better if we too, use B(1) = +1/2. I'll make this change in math/base/special/bernoulli, if this is fine.

Let's go ahead and use 1/2. This will match SymPy and is also used as a convention in R. As commented elsewhere, how much the choice actually matters in practice is subject to some debate. In this case, I'm more inclined to go with Knuth.

Similar to the changes proposed in https://github.com/stdlib-js/stdlib/pull/3108, we'll want to make similar changes here.

Refactored it as suggested.

/stdlib merge

@gururaj1512 You can represent numbers till B(64) in single-precision, rather than the current B(62) in this PR. You'll have to modify everything accordingly in all files.

@gururaj1512 Looks like this PR still has failing tests. We'll need to get those resolved before further review and subsequent merge.

@gururaj1512 Looks like this PR still has failing tests. We'll need to get those resolved before further review and subsequent merge.

Resolved.


[Event Request] Table 11400 - "CBG Statement" - OnBeforeCheckBalance

Dear Support,
We would like to add a new event OnBeforeCheckBalance in the following Procedure below, using the IsHandled pattern. This would allow us to further customize the code and migrate existing customizations.
procedure CheckBalance()
var
    IsHandled: Boolean;  //New  Code --++
begin
    //New  Code --
    IsHandled := false;
    OnBeforeCheckBalance(Rec, IsHandled);
    if IsHandled then
    exit;
    //New  Code ++
    CalcFields("Net Change Debit", "Net Change Credit");

    if "Opening Balance" - "Net Change Debit" + "Net Change Credit" <> "Closing Balance" then
        if Confirm(
             StrSubstNo(
               Text1000005 +
               Text1000006 +
               Text1000007,
               "Opening Balance",
               -"Net Change Debit" + "Net Change Credit",
               "Closing Balance", Abs("Opening Balance" - "Net Change Debit" + "Net Change Credit" - "Closing Balance")), false)
        then begin
            "Closing Balance" := "Opening Balance" - "Net Change Debit" + "Net Change Credit";
            Modify();
            Commit();
        end else
            Error(Text1000008);
end;

Event Signature:
[IntegrationEvent(false, false)]
local procedure OnBeforeCheckBalance(var CBGStatement: Record "CBG Statement"; var IsHandled: Boolean)
begin
end;

Thanks for reporting this. We agree, and we’ll publish a fix asap, either in an update for the current version or in the next major release. Please do not reply to this, as we do not monitor closed issues. If you have follow-up questions or requests, please create a new issue where you reference this one.
Build ID: 53230.


add infra node resize notification

Corresponding control plan notification: https://github.com/openshift/managed-notifications/blob/master/osd/controlplane_resized.json

/lgtm


Salmonella enterica IIIa 	UGXG01000002

Salmonella enterica IIIa 	UGXG01000002 seems to have a lot of premature stops.  Might want to switch it out.

I replaced it with CP000880 in e1d7170..9848649 and locally confirmed a better assembly when running Busco on the old and new assemblies.


Legend Formatter?

I'm trying to format the legend on my Donut chart to include some extra data. I see that the source apexcharts docs show that there is a formatter for the legend:

I may have missed it, but don't see an option for this in the wrapper. Any clue on how to do this?

Hello,
The formatter is missing, I have added it and it will be available in the next release

fivex in Release v0.9.19-beta


GAH: Remove crop marks from layers 2, 3, 4, and 5

Removed only from layers 2, 3, and 4 so that the unit can be turned upside down and still have crop marks.