Removing filter on listing.jet.html

Filtering here would mean giving random number of results instead of showing constant number. And can mislead people to think that there are no results and also force people to switch pages more often.
For example, if there are 48 hentai results on the 50 results. It will display only 2 results on the page. People would therefore think that there are only two results for the search or would make them changing the page every two (or more) results instead of 50.
Finally this doesn't fix at all the results in the RSS feeds & the API endpoint.
The hentai results should be fixed in the scrapper.

Coverage remained the same at 33.478% when pulling 4904a2b95dfe64f6b9ec323555999b56200f4086 on akuma06-patch-1 into c6168be8b1d049a80c13d91a786648d558b8e66b on dev.

I disagree with this.
https://nyaa.pantsu.cat/search?c=2_&userID=0&q=

Browsing the audio categories is pure 100% hell with these garbage torrents around
Yeah, it's not a fix but a workaround and is certainly not ideal, but it's much much better than the shit we have on live right now
I browse the audio category frequently and i'd rather see only 5 torrents per page than having to scroll so much because of garbage, completely unrelated torrent
Showing only 5 good torrents is objectively much better than showing 5 good and 45 completely unrelated and uninteresting ones
The scrapper problem isn't going away anytime too, and it's idealist to think it will.
If you want an actual fix you prevent torrent with unmatching categories to pop up in the search period (instead of just hiding it as we are doing now), but deleting the filtering without submitting any fix yourself is pure idiocy.
The picture above has 7 normal torrents, followed by 40 garbage ones in a row and then 3 normal ones.

Like I said, showing 7 results on 50 because there are garbage results mixed in is not a fix, it's bad workaround and lead to wrong coding behaviours/other bugs. You don't introduce fix by introducing new bugs.
And it actually fix nothing since the results in rss&api search are not impacted by this. So the results from them and the results by a website search are not consistent.
Finally, by doing this you lead to randomized number of results and force people who wants for example to search between 300 results to look through much less (even if there are garbages mixed in).
If you want a fix, fix scrapper (which is fixed according to @ewhal).

Start thinking more like an user, there is nothing more irritating than browsing the audio categories only to find it filled with non-audio torrents. Yeah, it's not showing the 50 or more torrent it should show, what about it?  Do you really think swimming through garbage torrents just to find new content is okay whatsoever? Not showing these useless torrent is infinitely better for the user, it removes one massive inconvenience to introduce a very small one.
 Counting on ewhal to fix this is stupid: not only does he have trouble fixing it every time it happens, but a simple a change on anidex's html would completely break the scrapper again. You could make a PR right now that would simply ignore garbage torrents during search in order to show the right amount of torrents, but you're not doing it. This problem isn't going away and removing a workaround without fixing the problem is useless.
Showing garbage torrent > Showing a random number of torrent per page, inconvenience wise. From a dev point of view it is indeed messy but from an user point of view it is more convenient.

Like I said, ewhal said it's already fixed so why are you complaining?
For anidex html changes, the scrapper can easily filter out hentai when parsing the result by having a cookie: "anidex_h_toggle=1" which is how anidex knows not to show hentai torrents.
Moreover, the scrapper adds the hentai torrents in a non-existant category on nyaa, another easy fix for this was to just check the category before adding it.
So a change of the anidex html occuring another bug like that could easily be prevented by some checks and more profound filtering. This has already in part been implemented in the scrapper by ewhal.
Furthermore, if you want to easy fix this, just remove the torrents with category=2 and sub_category=2 in the database. This has already been given by sfan5 as a fix for these hentai torrents.
Doing the filter on the fly is however not a fix (especially when you do it only for the torrents listing and not for the RSS & API search). Fixing scrapper (done) and removing hentai from database (can be easily done by a simple query, DELETE FROM torrents WHERE category=2 AND sub_category=2 ) are better options.
Making a filter to prevent category from appearing on the search function would make it more complicated that it is already and other solution would use more cpu ressources. When you have solutions that can ease the burden of the program to achieve the same results, you choose them.
And finally, not showing garbages torrents introduce another thing, moderators won't know that there is garbages torrents mixed in. And don't tell me "if there are not enough results they can think that there are garbages torrent", because not showing enough results can lead to many more problems. For example, a bug in Elastic Search, a corrupted database, a function in Golang that is broken due to some unexpected data handling. All this leading to more difficult bug resolution.
And don't give me the "think of a user perspective", if you think from this, you should know many uses RSS to actually download torrents automatically with their torrent client. This doesn't fix it.

I forgot that moderators can remove the torrents easily also with the modtool bar. This is also another way to prove that knowing and showing when there are garbages is important in order to moderate them.

Like I said, ewhal said it's already fixed so why are you complaining?

You'd know if you actually used the website ;)
And regardless it's not like this issue is never gonna pop up again so removing the workaround without submitting a fix yourself is silly.

Furthermore, if you want to easy fix this, just remove the torrents with category=2 and sub_category=2 in the database. This has already been given by sfan5 as a fix for these hentai torrents.
It doesn't happen only with the audio (2) category, you'd know if you actually used the website ;)

And don't give me the "think of a user perspective",
too late ;)

For example, a bug in Elastic Search, a corrupted database, a function in Golang that is broken due to some unexpected data handling. All this leading to more difficult bug resolution.

It's not like it's using some extremely fancy function to check if the torrent is garbage, it uses the CategoryName() function that will get called anyway for the title of the category image, there is no possible way to have an unexpected data handling in there or a Golang function breaking or any other silly thing you may think.

"It doesn't happen only with the audio (2) category, you'd know if you actually used the website ;)"
As long as the category is not one of nyaa, you just have to make the delete query with the category & sub_category set.
And if it happens with a category set in nyaa, then your code won't remove the torrent, since the category exist.
Of course they are still there but they shouldn't be there in the future. Just removing those already in database is easy. And checking before adding the torrents in database that the category you're actually adding is in nyaa fix the problem. Even a change in anidex html or anything else can't produce the bug.
When I spoke about ES bug and everything else, I'm speaking about when you resolve bug. Having the wrong number of results can make devs believe that what they are doing causes display bugs when they test their code. Or on the contrary, a bug that have happened can make people believe that there are no bugs and it is just the code that filter the thing. Anyway even if the possibility is not high, I don't see why you would still have this when you don't need it anymore. Because it is fixed and if, by chance new hentais does appear on nyaa, they would be added on already existing categories which would be not prevented by this code.

Coverage remained the same at 33.478% when pulling 17706f456d0e8fb3799242d5fd8e6d4d615c71d2 on akuma06-patch-1 into 2a6d7dcda86bd123e1e9625bd9546ef74b040a92 on dev.


What is the difference between conf_thr and score_thr in the yolo model parameters?

In yolo model setting can you explain the exact difference between conf_thr and score_thr ?
https://github.com/open-mmlab/mmdetection/blob/fa10539397af557853cc5f72f4cd1aba8a174d44/configs/yolo/yolov3_d53_mstrain-608_273e_coco.py#L55
...
test_cfg=dict(
    nms_pre=1000,
    min_bbox_size=0,
    score_thr=0.05,
    conf_thr=0.005,
    nms=dict(type='nms', iou_threshold=0.45),
    max_per_img=100))
...

In other model setting such as vfnet, only score_thr is set.
https://github.com/open-mmlab/mmdetection/blob/fa10539397af557853cc5f72f4cd1aba8a174d44/configs/vfnet/vfnet_r50_fpn_1x_coco.py#L55
Thanks !

conf_thr is used to first filter the results by their objectness score before applying nms.  score_thr is used in the nms function to filter results by their class scores.
From the get_bboxes() method:
'''
conf_thr = cfg.get('conf_thr', -1)
if conf_thr > 0:
conf_inds = objectness >= conf_thr
bboxes = bboxes[conf_inds, :]
scores = scores[conf_inds, :]
objectness = objectness[conf_inds]
'''

@PeterVennerstrom Thanks , I'm not sure what their objectness means, can you be more specific?

Anchor based methods often predict an objectness score for each anchor.  In YOLO's case, the class scores are predicted separately per grid and there are multiple anchors per grid.
Objectness is described in the original YOLO paper as "... how confident the model is that the box contains an object and also how accurate it think the box is that it predicts".


Retry fork/exec errors when running hook

A customer reported that their jobs were unable to run a hook because the hook wrapper script was locked.
The hooks should have collision avoidant names, and they should have closed by the agent worker goroutine that created them prior to execution, which is in the same goroutine. So it's a bit of a mystery how the script wrapper could remain open.
We could just add more retry to work around this, but it would like to find the cause. So, I've done two things in this PR:

Retry executing the hook if we get a fork/exec error
If the retry is exhausted, log the error and try to determine what process has the file open

That latter will only work if:

the process that has the file open is long-lived enough for the error handling to catch it with the file open, and
the agent has permission to read the open file descriptors of the other processes

So we can't be certain what the other process is, but at least we should be able to prove or disprove that it is the agent itself.
Detecting other processes only works on Linux because it uses the procfs. For other Unixes, we can use /dev/fd to check that the agent process does not have the file open. I'm not sure if this will work if the two goroutines are scheduled on different OS threads, however.

@moskyb after chatting with @pda, we decided to feed back errors from failing to close files that are opened in NewScriptWrapper. If the files are kept open by the agent, that's the likely cause.


[docs] Clean up filenames + update links

The Problem/Issue/Bug:
The documentation source uses inconsistent separators and a few filenames that could be more terse.
How this PR Solves The Problem:
This consistently uses all lowercase filenames with hyphens as word separators, updating the navigation and links. It will require a few redirects:

users/extend/database_types.md → users/extend/database-types.md
users/basics/database_management.md → users/basics/database-management.md
users/configuration/config_yaml.md → users/configuration/config.md
users/topics/whats_in_ddev_dir.md → users/topics/directory-tour.md
users/topics/cms_specific_help.md → users/topics/cms-specific-help.md
docs/content/Logo_w_text.svg → docs/content/logo.svg

Bonus Sub-Issue

⚠ The noteworthy one here is config_yaml.md → config.md, which I consider foreshadowing.

On many pages, conceptual descriptions of config settings refer to config.yaml when they don’t need to. It needlessly forces the mechanics of setting the thing into the explanation of what it does, and implies it must be set via YAML when most settings could be set via CLI. Better to leave out the explicit YAML reference in most cases and link to the reference that prominently clarifies—with examples—how to set the value of a given thing.
Examples

Open your .ddev/config.yaml file and check the docroot value, (...)

👍 Keep it! This is an instruction pointing you to a file where you can check and edit the docroot setting.

(...), you can easily add them using web_extra_daemons in .ddev/config.yaml.

🤔 Could go either way. Might be more efficient to say “add them using the web_extra_daemons setting” and link directly to the config page, even though someone will not be setting this via CLI.

You can choose the Node.js version you want to use in .ddev/config.yaml with nodejs_version.

👎 Change it: “You can specify the Node.js version you want with the nodejs_version setting.”
Shorter sentence, link to the config page which explains how you can set it and further points out that nvm is there waiting. No need to be overly-prescriptive with the .ddev/config.yaml reference here, which makes this sentence harder to parse if the reader doesn’t already have a working knowledge of .ddev/config.yaml. It’s safer to assume they know what a config setting is and link them to a page that thoroughly explores config settings.
Manual Testing Instructions:
Examine this branch locally or check out the automatic preview build.
Automated Testing Overview:
n/a
Related Issue Link(s):
#4188
Release/Deployment notes:
n/a

Pull whenever you’d like, @rfay!


Support running all tests in project

Modifications to support running all tests in project. Looking for some feedback to see if everything looks in the right direction and some implied assumptions are fine.

The order of the files appears in the same order returned by the TAP reporter.

I haven't removed TerminalCommandExecutor yet but this class is now using BufferedProcess. BufferedProcess produces side effects as it already spawns the process and could make testing harder as it is hard to mock. I'm trying to figure out this before completely removing the class. For now, acts as a wrapper (related: https://github.com/avajs/atom-ava/issues/16).

As suggested, the package will execute all tests with ctrl-alt-a and the current file with ctrl-alt-shift-a.

An editor screen must be opened to deduce the project.

This extension needs AVA 0.15 to work properly (https://github.com/avajs/ava/commit/3c4babd0efed2ddd9cfe6e2dc23952338f0c9879). Previous versions will display the ANSI scape codes. I think I should be removing them also to support previous versions, not done yet.

This feature was already started, but IMO next step should be migrate the test suite to AVA.

Related: https://github.com/avajs/atom-ava/issues/13

Added an initial but hopefully reasonable implementation of the ESCAPE key for closing the pane. Based on: https://github.com/atom/find-and-replace/blob/master/lib/find.coffee#L78.
For our case:

Used core:cancel. Not used core:close as the panel may not be related specifically to the current file and you want to keep it visible.
You need to have selected the main editor, which will be active when running tests.
Events triggered from the mini-editor (that is, other components) will be skipped.

Only one thing and it's ready: https://github.com/avajs/atom-ava/pull/18#discussion_r69033888

@sindresorhus, as always, very grateful for all the feedback. Really appreciated.

Found and edge case yesterday. When the user selected run all the files but only one test was in the folder, the package was unable to render.
On my side, ready to merge now.

Excellent. Works great! Thanks for your hard work on this :)

Thank you @sindresorhus for all your feedback and support. Learning lots of things!.


Default value for repeatable section with the resetFieldOnHide enabled

Description
The default value is ignored for repeatable section with the resetFieldOnHide extra option enabled.
Minimal Reproduction

https://stackblitz.com/edit/formly-array-default-value?file=src%2Fapp%2Fapp.module.ts
Your Environment

Angular version: 7.2.16
Formly version: 5.10.0

Note
Works perfectly before 5.10.

I will check thanks.


Bug on refresmapobjects

Hello everybody, after several tests some of them of several hours I come to realize that the dispach stops working after some temp 30 to 40 minutes in log debug does not appear the GetMapObjetcs, I think that au receive sessioninvalidate or platform causes a throw and should close it I'm not sure .. on the other hand I did this https://github.com/Furtif/POGOLib/commit/89436c42c23c4860327f1324054943786093b173 and I get even result passed some time the dispach does not refresh the map hence the rate of xp / h decreases considerably .
If anyone has any idea about this thank you from now on, modify and make a pr for testing.
@Xelwon and @PeterDM65 you who are active in this api who think you?

Fixed


addAffixes misses a suffix

The method addAffixes in AffixesTrait does not add the concluding "}" to a BibTeX record if the inner data ends in a "}", which is common with BibTeX. The reason for this is that the method contains a guard against repeated suffixes. Since I do not (yet) see where this guard might be necessary (and do, at any rate, think that different precautions should be taken if it currently is) I remove this guard to get proper formatting.

Note that, like the solution to the next issue, this one is just tentative and the simplest thing that works. As yet I do not fully comprehend the purpose of the coder I removed, but removing it solved the immerdiate problem.


Update some doc links.

This updates some links to their new locations.
This also switches to relative-style cross-book links. This allows the links
to work better when viewing local documentation (such as through rustup),
keeps links to the same toolchain (not just stable), and allows the rust-repo
linkchecker to validate the links. The downside is that when working on the
documentation in the cargo repo, the links won't work.

r? @Eh2406
(rust_highfive has picked a reviewer for you, use r? to override)

@bors r+

:pushpin: Commit b54748ef1c8789364c2322b14019270a0508fd25 has been approved by Eh2406

:hourglass: Testing commit b54748ef1c8789364c2322b14019270a0508fd25 with merge ba2e53747e58c780cb461a57ac07c5d7caba9afd...

That is an odd test failure...
@bors retry

:hourglass: Testing commit b54748ef1c8789364c2322b14019270a0508fd25 with merge bb8a583d1323d35e5619b01c92898fdfb52444a4...

:sunny: Test successful - checks-travis, status-appveyor
Approved by: Eh2406
Pushing bb8a583d1323d35e5619b01c92898fdfb52444a4 to master...


Podman support?

Do you support podman as well?

Not yet, but many people request it, so I think I will have a look at this.


[ feature 💅  ] extended theme support for tina's UI

Summary
I am working on a project where the client would like to have tina's UI styled (more) according to his CD. It would be great if we could extend the existing theme to support more customizations. Ideally, that would be done in a way that respects the work you have done already and just offer a more granular approach of being able to set variables for example.
Basic example
For example, this could be done by introducing more specific css custom properties that could optionally be set if the need arises to do more granular styling. The current variables could be set as default/fallback value and thus the current style would not break if the more granular variables are not set.
Example:
export const Button = styled.button<ButtonProps>`
  text-align: center;
  border: 0;
  border-radius: var(--tina-button-border-radius, --tina-radius-big);
  box-shadow: var(--tina-button-box-shadow, --tina-shadow-small);
  background-color: var(--tina-button-background-color, --tina-color-grey-0);
  // ...
`;

Motivation
This would allow a more customizable UI and therefore improve UX in projects where users are already accustomed to working with an interface they know.

Great, I will open a draft PR today or tomorrow


shows "Cannot enable firestore for this project" while creating the cloud database in firebase

Sorry, this seems to be a Firebase issue.

It was. I had solved it nonetheless ans thanks for the tutorial.I
personally learned a lot from it.
On Wed, Nov 18, 2020 at 4:57 AM Karl Hadwen<EMAIL_ADDRESS>wrote:

Sorry, this seems to be a Firebase issue.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/karlhadwen/netflix/issues/11#issuecomment-729275351,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AQ33UNS4QYTTIQ2KBKMSFELSQMBFZANCNFSM4TVUWPVQ
.

Glad to hear that!


Error while building go application, issue with github.com/XiaoMi/pegasus-go-client

Unable to build go application on go version 1.18.2 on MacOS and Ubuntu
My guess is that problem is in this library: https://github.com/XiaoMi/pegasus-go-client which is used in github.com/eko/gocache/v3/store

Steps for Reproduction

Use store.WithExpiration(5*time.Minute) in code
Error is there even if using any other time value

Expected behavior:
App should build
Actual behavior:
Error while building application
Error Log:
divkix@Divs: …/AlitaGoRobot [ Beta][+3595 -17369][📦🗑×22📝×41🛤 ×2][🐳 desktop-linux][🐹 v1.18.2][🐏 11GiB/16GiB]
❯ go build .
# github.com/XiaoMi/pegasus-go-client/idl/cmd
vendor/github.com/XiaoMi/pegasus-go-client/idl/cmd/cmd.go:41:15: not enough arguments in call to iprot.ReadStructBegin
        have ()
        want (context.Context)
vendor/github.com/XiaoMi/pegasus-go-client/idl/cmd/cmd.go:46:35: not enough arguments in call to iprot.ReadFieldBegin
        have ()
        want (context.Context)
vendor/github.com/XiaoMi/pegasus-go-client/idl/cmd/cmd.go:60:26: not enough arguments in call to iprot.Skip
        have (thrift.TType)
        want (context.Context, thrift.TType)
vendor/github.com/XiaoMi/pegasus-go-client/idl/cmd/cmd.go:70:26: not enough arguments in call to iprot.Skip
        have (thrift.TType)
        want (context.Context, thrift.TType)
vendor/github.com/XiaoMi/pegasus-go-client/idl/cmd/cmd.go:75:25: not enough arguments in call to iprot.Skip
        have (thrift.TType)
        want (context.Context, thrift.TType)
vendor/github.com/XiaoMi/pegasus-go-client/idl/cmd/cmd.go:79:13: not enough arguments in call to iprot.ReadFieldEnd
        have ()
        want (context.Context)
vendor/github.com/XiaoMi/pegasus-go-client/idl/cmd/cmd.go:83:12: not enough arguments in call to iprot.ReadStructEnd
        have ()
        want (context.Context)
vendor/github.com/XiaoMi/pegasus-go-client/idl/cmd/cmd.go:90:15: not enough arguments in call to iprot.ReadString
        have ()
        want (context.Context)
vendor/github.com/XiaoMi/pegasus-go-client/idl/cmd/cmd.go:99:18: not enough arguments in call to iprot.ReadListBegin
        have ()
        want (context.Context)
vendor/github.com/XiaoMi/pegasus-go-client/idl/cmd/cmd.go:107:16: not enough arguments in call to iprot.ReadString
        have ()
        want (context.Context)
vendor/github.com/XiaoMi/pegasus-go-client/idl/cmd/cmd.go:107:16: too many errors
# github.com/XiaoMi/pegasus-go-client/idl/base
vendor/github.com/XiaoMi/pegasus-go-client/idl/base/blob.go:18:15: not enough arguments in call to iprot.ReadBinary
        have ()
        want (context.Context)
vendor/github.com/XiaoMi/pegasus-go-client/idl/base/blob.go:27:27: not enough arguments in call to oprot.WriteBinary
        have ([]byte)
        want (context.Context, []byte)
vendor/github.com/XiaoMi/pegasus-go-client/idl/base/error_code.go:94:18: not enough arguments in call to iprot.ReadString
        have ()
        want (context.Context)
vendor/github.com/XiaoMi/pegasus-go-client/idl/base/error_code.go:99:27: not enough arguments in call to oprot.WriteString
        have (string)
        want (context.Context, string)
vendor/github.com/XiaoMi/pegasus-go-client/idl/base/gpid.go:18:12: not enough arguments in call to iprot.ReadI64
        have ()
        want (context.Context)
vendor/github.com/XiaoMi/pegasus-go-client/idl/base/gpid.go:30:24: not enough arguments in call to oprot.WriteI64
        have (int64)
        want (context.Context, int64)
vendor/github.com/XiaoMi/pegasus-go-client/idl/base/rpc_address.go:26:18: not enough arguments in call to iprot.ReadI64
        have ()
        want (context.Context)
vendor/github.com/XiaoMi/pegasus-go-client/idl/base/rpc_address.go:35:24: not enough arguments in call to oprot.WriteI64
        have (int64)
        want (context.Context, int64)

Platforms:

MacOS Monterey Version 12.3.1 (21E258)
Ubuntu 20.04 LTS

Include browser, operating system and respective versions
Versions:

v3.0.0 (latest)

Which versions are you running?
Go Version: v1.18.2
gocache version: v3.0.0
OS: MacOS 12.3.1 and Ubuntu 20.04 LTS

same issue looks like it moved https://github.com/apache/incubator-pegasus/tree/master/go-client

same issue looks like it moved https://github.com/apache/incubator-pegasus/tree/master/go-client
Can't seem to revert after running a go get -u with v2.3.1

I'm still facing this issue even when using v2.3.0

Experiencing the same issue on v3.0.0 😢

this is a work around:
add replace in your go.mod
replace github.com/pegasus-kv/thrift v0.14.1  => github.com/pegasus-kv/thrift v0.13.0

this is a work around: add a replace into your go.mod
replace github.com/pegasus-kv/thrift v0.14.1  => github.com/pegasus-kv/thrift v0.13.0

This solves the build issue, thanks!

Hello, the pegasus store is now in a separated Go module so this should be fixed in case you only use the Gocache library (by importing github.com/eko/gocache/v4/lib).
I close this issue for now but feel free to reopen if you still have any issue with this new v4.0.0 release.


fix(reduce): fix overload ordering

Description:
Type inference for Observable.prototype.reduce currently behaves incorrectly, resulting in spurious type errors, in many common cases, when the type of seed is a different type than the value type of the Observable.
One of the declared overloads is intended to specifically cater to this scenario but fails to do so because of its ordering with respect to the other overload declared.
The overload in question takes two type arguments, T and R, making it more specific than the overloads declared before it.
Due to TypeScript's overload resolution algorithm, which picks the first matching overload, this overload does not have the intended effect.
This is documented here https://www.typescriptlang.org/docs/handbook/declaration-files/do-s-and-don-ts.html in the section entitled Function Overloads, under the Ordering heading, which states

Don’t put more general overloads before more specific overloads:

Do sort overloads by putting the more general signatures after more specific signatures:

Why: TypeScript chooses the first matching overload when resolving function calls. When an earlier overload is “more general” than a later one, the later one is effectively hidden and cannot be called.

Related issue (if exists):
This fixes #2338

@kwonoj Thank you, I most definitely will.

It looks like there is more nuance here, the overload taking an array seems to be producing more issues than I had thought.

@aluanhaddad it looks like there are build errors with the specs. Do you think you can fix them?

Yes I've been very busy recently. I will try to fix them tonight and add some additional tests as well. When I looked at the specs, they seemed to rely on the seed being inferred to have the value type of the Observable. I need to double-check if that is the case.
Perhaps I misunderstand the behavior of RxJS or the intent of the Declarations but this doesn't seem like a reasonable assumption at face value.

I am having some trouble replicating the test failures locally.
When I run
npm run build_spec && npm run test_mocha && node ./node_modules/markdown-doctest/bin/cmd.js

Any tips would be greatly appreciated.

Coverage remained the same at 97.688% when pulling 99fd39d636b2d75100f475a5cf1f3350f588bd15 on aluanhaddad:patch-1 into 023d436b3beead009bbbb24593775b51c9b97623 on ReactiveX:master.

@kwonoj I added several new test including tests covering behavior that was an error before these changes.
@blesh I fixed the failing tests and also broke them down into multiple discrete tests, for assignability.
I added a local binding and a subsequent statement to each test I touched so that the resulting value is now used in such a way that it validates that the types are propagated.
Let me know if these tests are sufficient and also let me know if I should have added the same tests to spec/operator/scan-spec.

I think this change is ready, re-approving. /cc @david-driscoll for second eye just in case.

lgtm

@david-driscoll can you review this please? <3

Just to note, when I first looked at this, I believed the issue was simply due to the overload ordering but the root cause turned out to have as much to do with the optionality of the seed arguments as signature ordering. The now required seed arguments eliminate a previously applicable overload from the candidate set, but a minor order change was still ultimately necessary.

Thanks @aluanhaddad !!!


FanzyZones: Editing unassigned layout, assigns before editing

Microsoft PowerToys version
0.75.1
Installation method
WinGet
Running as admin
No
Area(s) with issue?
FancyZones
Steps to reproduce

Open zones editor and have at least two monitors, each with their own custom zones assigned.
Click the edit icon (pencil) of the OTHER monitor without first selecting the monitor from the top of the window, and without first clicking to assign the zone about to be edited to the current monitor.

✔ Expected Behavior
The zones editor opens on the monitor that that zone config is assigned to.
❌ Actual Behavior
The zone editor opens on the currently selected monitor, even though we're editing the zones layout of another monitor, and that layout gets assigned to the current monitor (temporarily?), before the editor opens.
Other Software
None

Hi @brokenthorn, let me, please clarify the issue. It's expected that the zones editor is opened on the monitor that is selected on the top of the Editor window, no matter where this layout is assigned. Is that the issue you encountered?
/needinfo

Hi @brokenthorn, let me, please clarify the issue. It's expected that the zones editor is opened on the monitor that is selected on the top of the Editor window, no matter where this layout is assigned. Is that the issue you encountered?
/needinfo

Yes, but if you click to edit another zone without assigning it first, it is not expected to also assign that zone to your current monitor.
To do that you would not click the pencil icon button, but the zone itself.

Yes, but if you click to edit another zone without assigning it first, it is not expected to also assign that zone to your current monitor.

Now I see. When you save the changes after editing the layout, the layout is applied automatically (as the button says "Save and apply"). Although this is the expected behavior, it may not be the most user-friendly experience. Perhaps we could improve it by adding an option to simply save changes without applying the new layout to the monitor. Will that resolve the issue? /needinfo

I can create a video if that helps, with audio.

If my assumption isn't correct, I would appreciate it if you could provide a video with comments.

"Save and apply" makes no sense to me. I started my user journey with the
intent to edit a layout and save those edits, not edit, save and apply the
layout to the current monitor.
I don't find that user friendly. I find it confusing. Hopefully you also
understand.
While your proposed solution seems to solve the problem, it doesn't in fact
solve the user journey discrepancy.
Like if I click the edit button on a layout, I expect to edit that layout
and that's all!
And if I click the layout, I expect it to be applied to the current
monitor, that's all!
None of these operations have any other side effects.
Instead of adding another button, why not just remove the code that's also
applying the layout when all I did was click an edit button.
Interestingly, the bug seems to be gone now after a couple of updates. I'm
on 0.75.1 now.
Here's the configuration I used to start with:
[image: image.png]
Then I used to click edit on the configuration that's NOT assigned to the
current monitor (no blue border on it):
[image: image.png]
As you can see I do not assign the layout first (blue border stays on the
same initial layout).
And there is no Save and Apply button, just a Save button now:
[image: image.png]
Maybe it's been fixed?
Paul-Sebastian, Manole
@.*** | +40 720-231-791 <+40720231791> | LinkedIn
https://www.linkedin.com/in/paulsebastianmanole/
On Fri, Nov 3, 2023 at 1:34 PM Seraphima Zykova @.***>
wrote:

Yes, but if you click to edit another zone without assigning it first, it
is not expected to also assign that zone to your current monitor.
Now I see. When you save the changes after editing the layout, the layout
is applied automatically (as the button says "Save and apply"). Although
this is the expected behavior, it may not be the most user-friendly
experience. Perhaps we could improve it by adding an option to simply save
changes without applying the new layout to the monitor. Will that resolve
the issue? /needinfo
I can create a video if that helps, with audio.
If my assumption isn't correct, I would appreciate it if you could provide
a video with comments.
—
Reply to this email directly, view it on GitHub
https://github.com/microsoft/PowerToys/issues/29628#issuecomment-1792282464,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAQFKXERDZN6ILZBNIT6XETYCTJC3AVCNFSM6AAAAAA62W5XQOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTOOJSGI4DENBWGQ
.
You are receiving this because you were mentioned.Message ID:
@.***>

No, actually it hasn't been fixed. Sorry. I had forgotten how to reproduce it.
Yes there is a save and apply button. It's still unexpected for me. I would expect the layout editor to open on the monitor that the layout is assigned to. Not on the current monitor which has a different layout. That's because the monitors can have different sizes and the pixel counts don't transfer over correctly from one monitor to another, it becomes relative leading to for example instead of simulating 1080p on half of the screen to 1079p etc.
Here is a demo:
https://github.com/microsoft/PowerToys/assets/2119004/4e56dc80-a9c7-4fe6-bb77-18546678dded

The work associated with this issue has been released as part of the 0.76 sprint. Please update PowerToys to the latest. https://github.com/microsoft/PowerToys/releases


Note regarding CNG certs not being supported.

Added note in certificates section that Skype for Business Server 2015 does not support CNG certificates.

@LanaChin PR has been copyedited and is ready for final review, could you please check and merge? Thanks!


things are blurry

the rendered images are blurry. Any ideas on how to improve?

@JunzheJosephZhu Maybe you could increase the NeRF rendering resolution (current is 64x64), but it leads to large GPU memory consumption. Another idea is to follow Magic3D, and train a mesh finetuning stage.

@ashawkey Awsome work thank you! Were you able to implement the fine tuning stage by any chance?
Another thing I was thinking was to use something like esrgan to upscale the nerf model: any thoughts?


Hedera REST Mirror Net support

HederaNetwork has been moved to hedera folder
~- HederaNetwork.getClient() has been changed to HederaNetwork.client (property)~
Removed a bunch of config variables from StratoContext (see comment)
Removed Contract.serialize() and Contract.deserialize(...) methods since they were, most likely, never used
Reorganized HederaNetwork.defaults (simplified and augmented with the new rest api baseurl reference)

All tests pass ~except for a Given an NFT Shop, a user is able to mint one which, oddly enough, when creating a Token fails with  INSUFFICIENT_TX_FEE. Could be a network fluke.~

Everything is green again. Awaiting review


te-3.1: update test coverage as per #1132

added support for non-default VRF VRF-1 and added route into VRF-1
Added MAC next-hop coverage
Added MAC validation in MAC next-hop scenario
Added MAC  next-hop support AddNH() in gribi.go
Copied README.md from PR #1132
Updated README.md and script  with /32 as mask for gRIBI entry
cleaned up the code as per 1132 README
Added enhancement in gRIBI configuration by using gribi.go client
Added PBR support for VRF traffic redirect

This code is a Contribution to the OpenConfig Feature Profiles project ("Work") made under the Google Software Grant and Corporate Contributor License Agreement ("CLA") and governed by the Apache License 2.0. No other rights or licenses in or to any of Nokia's intellectual property are granted for any other purpose. This code is provided on an as is basis without any warranties of any kind.

Also, I'm ok with copying the content of PR#1132 here, close PR#1332, and simply mention PR#1132 in your description.

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 56.88%

Totals

Change from base Build<PHONE_NUMBER>:
0.0%

Covered Lines:
1236

Relevant Lines:
2173

💛  - Coveralls

Seems like comments are not replied/addressed. So revert it back to the author.

@bkreddy143 can you help resolve the conflict at the base? Thanks.

@LimeHat can you help review this code too? Just want to make sure it's consistent with some of your recent changes. Thanks.

@xw-g we discussed with @bkreddy143 offline and he made a few changes (including PBF) to match the other PRs.

This is a change of test plan (internal bug b/268525668), therefore we will rely on vendor review. cc: @vosipchu @sachendras @rszarecki.
@mojiiba can you help review? Thanks!
@cprabha can you help review? Thanks!
(Note: needed vendor specific deviations should be followed up in separate PRs to iterate).

ping @mojiiba

@bkreddy143 can you help resolve the conflict? I think we are close to be ready to merge. Thanks!

Pull Request Functional Test Report for #1315 / a9aafe07131045c798d731ae536bf4e6245a76f0
Virtual Devices

Device
Test
Test Documentation
Job

Arista cEOS

TE-3.1: Base Hierarchical Route Installation

Cisco 8000E

TE-3.1: Base Hierarchical Route Installation

Cisco XRd

TE-3.1: Base Hierarchical Route Installation

Juniper cPTX

TE-3.1: Base Hierarchical Route Installation

Nokia SR Linux

TE-3.1: Base Hierarchical Route Installation

/gcbrun

Internal presubmit effort: b/286247682


Ad missing monthly update reports

Description
We need to add monthly reports starting from June  2024.
Here is a template for the monthly report: https://github.com/facebookincubator/velox/pull/11195
Please update here if you are interested in picking up a month

I am working on the June update.

CC: @kgpai, @pedroerp

I can take up July . Will send preliminary PR in day or so.

I can take August then. Once you guys publish your and I follow the template and publish the next :)


Endorser protocol configuration, automation and demo integration

See issue https://github.com/hyperledger/aries-cloudagent-python/issues/1238
This PR adds automation support for requesting, endorsing and writing transactions, and for executing the workflow of creating a cred def that supports revocation.
The next stage of work will re-factor the code to use the event bus and eliminate the code duplication (see https://hackmd.io/51flx8CVS1ypyOjEqVl1tg?view#Implementation-Details)

Codecov Report

Merging #1422 (841fac6) into main (024c624) will decrease coverage by 0.08%.
The diff coverage is 67.81%.

:exclamation: Current head 841fac6 differs from pull request most recent head 2c02dda. Consider uploading reports for the commit 2c02dda to get more accurate results

@@            Coverage Diff             @@
##             main    #1422      +/-   ##
==========================================
- Coverage   95.30%   95.22%   -0.09%
==========================================
  Files         483      483
  Lines       29237    29294      +57
==========================================
+ Hits        27865    27894      +29
- Misses       1372     1400      +28

I didn't find anything in testing this using alice/faber, but I couldn't figure out how to activate it in the demo.  Do you have instructions?
We also need some tweaks to the run_demo help handling.  I'm going to put in some suggestions in a separate issue.

I didn't find anything in testing this using alice/faber, but I couldn't figure out how to activate it in the demo. Do you have instructions?

The demo is in an "interim" state right now, endorser support is added but not fully added.  The following is how it works now (sets up the endorser roles to allow manual testing using the swagger page) but not ultimately how I see the demo demonstrating endorsement ...
Run the following in 2 separate shells (make sure you are running von-network and the tails server first):
./run_demo faber --endorser-role endorser --revocation
./run_demo alice --endorser-role author --revocation

Copy the invitation from faber to alice to complete the connection.
Then in the alice shell, select option "D" and copy faber's DID to alice (it is the DID displayed on faber agent startup).
This starts up the aca-py agents with the endorser role set (via the new command-line args) and sets up the connection between the 2 agents with appropriate configuration.
Then, in the alice swagger page (http://localhost:8031) you can create a schema and cred def, and all the endorser steps will happen automatically.  You don't need to specify a connection id or explicitly request endorsement (aca-py does it all automatically based on the startup args).

Nice -- that worked.
I'm thinking we need to have a "von-network"-like Endorser so that we can start it when needed for testing.  Perhaps it should be built into von-network?   We should brainstorm a bit how to do that.  We also need to have one that we can put into production, ahead of a BPA-based Endorser.
I think an "Endorser.md" file is needed for this to document how to use it both in real usage, and a section on how to use it in the demo.  Seems like a fun thing to do on a Friday, no?  :-). I'm thinking that should be done before merging.
I'm hoping you can demo this on Tuesday morning at the ACA-Pug meeting.  Doable?

I think an "Endorser.md" file is needed for this to document how to use it both in real usage, and a section on how to use it in the demo. Seems like a fun thing to do on a Friday, no? :-). I'm thinking that should be done before merging.

I added some docs both for ACA-Py as well as the demo.  These docs will need to be updated as the Endorser code is updated & re-factored.

Approved -- but you might want to clean up the typos first. Or just merge.

I'll include the doc updates/fixes in the next PR


Fix nameblacklist target auth check

Ugh, at this point I'm going to say no, fix the call signatures of these functions.

No function should be taking an id parameter instead of a userid parameter.

Heck, I'd nearly advocate changing id back to userid everywhere.
We should maybe even release a UserID type.

toID should return ID & UserID.

The function takes a user object as an argument, but because it just uses the ID from that, we mock up a fake user object that just contains an ID. That's my understanding what's happening here.

Ohhhh. That's fine, then.

I don't like the "fake user" pattern, though; we should maybe do something about that.


fix package-systemd

https://github.com/gardenlinux/package-systemd/actions/runs/120213
patching file debian/systemd.install
Hunk #1 FAILED at 4.
1 out of 1 hunk FAILED -- saving rejects to file debian/systemd.install.rej

Duplicate of : https://github.com/gardenlinux/gardenlinux/issues/2491

I've marked the PR as a draft. I guess it will be useful to start from there once the non-rc release is ready. Moving this issue to blocked until debian has a version in testing that we want to use again.


Whether ipv6 is supported?

I try to connect db with ipv6 but faild.
when I use connetion string like "oracle://username:password@fe80::250:56ff:fea0:b9cb:1521/orcl", it return "dial tcp: lookup fe80 on xxxx:xx: server misbehaving ".
when I use BuildUrl function get the url like "oracle://oracle:oracle@fe80%3A%3A250%3A56ff%3Afea0%3Ab9cb:1521/orcl", it return "parse "oracle://username:password@fe80%3A%3A250%3A56ff%3Afea0%3Ab9cb:1521/orcl": invalid URL escape "%3A""

yes I will fix

fixed
you can do one of the following
url := go_ora.BuildUrl("::1", 1521, "service", "user", "password", nil)
url = "oracle://user:password@[::1]:1521/service"


Adding to swift project

I'm doing as said here https://github.com/googlemaps/google-maps-ios-utils/blob/master/Swift.md
But got an error

Sorry, my mistake. I added files without creating groups.


AzureOpenAI Not Working

This line should be
completion = client.chat.completions.create(
It is also not working when I fix this line, I am still troubleshooting, but the version I updated was working fine. Will you be making any changes to fix this, or should I just maintain my own version? Thank you
https://github.com/Holmeswww/AgentKit/blob/15000a976bbff8fc8e6480208ebaa5ec227afc6f/src/agentkit/llm_api/GPT.py#L92

The other problem is because of the isInstance check, an AzureOpenAI client returns true for the isInstance check against OpenAI

This line should be completion = client.chat.completions.create(
It is also not working when I fix this line, I am still troubleshooting, but the version I updated was working fine. Will you be making any changes to fix this, or should I just maintain my own version? Thank you
https://github.com/Holmeswww/AgentKit/blob/15000a976bbff8fc8e6480208ebaa5ec227afc6f/src/agentkit/llm_api/GPT.py#L92

Thank you.  Yes, we should be using client.chat.completions.create and we don't need to check for Azure instance.  PR ready #16

Merged


Simplify Stub._run

WIP – think I need to rewrite some stuff related to modal serve in a separate PR then revisit this

Closing it because it's too hard to rebase at this point – will start over


longboy-proto

Moved generic boundary outside of longboy-proto and cleaned up tests a bit plus made tests try multiple permutations of (SIZE, WINDOW_SIZE).

Bless.
On Thu, Jun 27, 2024 at 3:29 PM James Leitch @.***>
wrote:

@.**** commented on this pull request.
 I'm
going to just redefine the constants based on the other thing, aka const
DATAGRAM_SIZE: usize = <Constants<SIZE, WINDOW_SIZE>>::DATAGRAM_SIZE; and
then I can use Self::DATAGRAM_SIZE everywhere.
—
Reply to this email directly, view it on GitHub
https://github.com/JKurzer/longboy/pull/3#discussion_r1657881481, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AB3D7B3O4ZPPPR7HLIWAKODZJSG4TAVCNFSM6AAAAABKAXE5QKVHI2DSMVQWIX3LMV43YUDVNRWFEZLROVSXG5CSMV3GSZLXHMZDCNBWGYZDKMRSGQ
.
You are receiving this because you commented.Message ID:
@.***>


No matches found for -

Description
Can't find match for the song
Version info
Client used: https://github.com/SudhanPlayz/Discord-MusicBot
Output of java -version:
openjdk version "16.0.1" 2021-04-20
OpenJDK Runtime Environment (build 16.0.1+9-Ubuntu-120.04)
OpenJDK 64-Bit Server VM (build 16.0.1+9-Ubuntu-120.04, mixed mode, sharing)

2022-08-22 14:54:16.839 ERROR 264186 --- [XNIO-1 I/O-1] org.xnio.listener                        : XNIO001007: A channel event listener threw an exception

java.util.concurrent.RejectedExecutionException: XNIO007007: Thread is terminating
	at org.xnio.nio.WorkerThread.execute(WorkerThread.java:590) ~[xnio-nio-3.3.8.Final.jar!/:3.3.8.Final]
	at io.undertow.websockets.jsr.UndertowSession$3.handleEvent(UndertowSession.java:396) ~[undertow-websockets-jsr-2.0.26.Final.jar!/:2.0.26.Final]
	at io.undertow.websockets.jsr.UndertowSession$3.handleEvent(UndertowSession.java:388) ~[undertow-websockets-jsr-2.0.26.Final.jar!/:2.0.26.Final]
	at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92) ~[xnio-api-3.3.8.Final.jar!/:3.3.8.Final]
	at io.undertow.server.protocol.framed.AbstractFramedChannel$FrameCloseListener.handleEvent(AbstractFramedChannel.java:1063) ~[undertow-core-2.0.26.Final.jar!/:2.0.26.Final]
	at io.undertow.server.protocol.framed.AbstractFramedChannel$FrameCloseListener.handleEvent(AbstractFramedChannel.java:978) ~[undertow-core-2.0.26.Final.jar!/:2.0.26.Final]
	at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92) ~[xnio-api-3.3.8.Final.jar!/:3.3.8.Final]
	at org.xnio.conduits.WriteReadyHandler$ChannelListenerHandler.terminated(WriteReadyHandler.java:70) ~[xnio-api-3.3.8.Final.jar!/:3.3.8.Final]
	at org.xnio.nio.NioSocketConduit.writeTerminated(NioSocketConduit.java:234) ~[xnio-nio-3.3.8.Final.jar!/:3.3.8.Final]
	at org.xnio.nio.NioSocketConduit.terminateWrites(NioSocketConduit.java:223) ~[xnio-nio-3.3.8.Final.jar!/:3.3.8.Final]
	at org.xnio.nio.NioSocketConduit.truncateWrites(NioSocketConduit.java:228) ~[xnio-nio-3.3.8.Final.jar!/:3.3.8.Final]
	at io.undertow.conduits.IdleTimeoutConduit.truncateWrites(IdleTimeoutConduit.java:387) ~[undertow-core-2.0.26.Final.jar!/:2.0.26.Final]
	at org.xnio.conduits.ConduitStreamSinkChannel.close(ConduitStreamSinkChannel.java:186) ~[xnio-api-3.3.8.Final.jar!/:3.3.8.Final]
	at org.xnio.IoUtils.safeClose(IoUtils.java:134) ~[xnio-api-3.3.8.Final.jar!/:3.3.8.Final]
	at org.xnio.conduits.WriteReadyHandler$ChannelListenerHandler.forceTermination(WriteReadyHandler.java:57) ~[xnio-api-3.3.8.Final.jar!/:3.3.8.Final]
	at org.xnio.nio.NioSocketConduit.forceTermination(NioSocketConduit.java:107) ~[xnio-nio-3.3.8.Final.jar!/:3.3.8.Final]
	at org.xnio.nio.WorkerThread.run(WorkerThread.java:494) ~[xnio-nio-3.3.8.Final.jar!/:3.3.8.Final]

2022-08-22 14:54:16.840 ERROR 264186 --- [XNIO-1 I/O-1] org.xnio.listener                        : XNIO001007: A channel event listener threw an exception

java.util.concurrent.RejectedExecutionException: XNIO007007: Thread is terminating
	at org.xnio.nio.WorkerThread.execute(WorkerThread.java:590) ~[xnio-nio-3.3.8.Final.jar!/:3.3.8.Final]
	at io.undertow.websockets.jsr.UndertowSession$3.handleEvent(UndertowSession.java:396) ~[undertow-websockets-jsr-2.0.26.Final.jar!/:2.0.26.Final]
	at io.undertow.websockets.jsr.UndertowSession$3.handleEvent(UndertowSession.java:388) ~[undertow-websockets-jsr-2.0.26.Final.jar!/:2.0.26.Final]
	at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92) ~[xnio-api-3.3.8.Final.jar!/:3.3.8.Final]
	at io.undertow.server.protocol.framed.AbstractFramedChannel$FrameCloseListener.handleEvent(AbstractFramedChannel.java:1063) ~[undertow-core-2.0.26.Final.jar!/:2.0.26.Final]
	at io.undertow.server.protocol.framed.AbstractFramedChannel$FrameCloseListener.handleEvent(AbstractFramedChannel.java:978) ~[undertow-core-2.0.26.Final.jar!/:2.0.26.Final]
	at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92) ~[xnio-api-3.3.8.Final.jar!/:3.3.8.Final]
	at org.xnio.conduits.WriteReadyHandler$ChannelListenerHandler.terminated(WriteReadyHandler.java:70) ~[xnio-api-3.3.8.Final.jar!/:3.3.8.Final]
	at org.xnio.nio.NioSocketConduit.writeTerminated(NioSocketConduit.java:234) ~[xnio-nio-3.3.8.Final.jar!/:3.3.8.Final]
	at org.xnio.nio.NioSocketConduit.terminateWrites(NioSocketConduit.java:223) ~[xnio-nio-3.3.8.Final.jar!/:3.3.8.Final]
	at org.xnio.nio.NioSocketConduit.truncateWrites(NioSocketConduit.java:228) ~[xnio-nio-3.3.8.Final.jar!/:3.3.8.Final]
	at io.undertow.conduits.IdleTimeoutConduit.truncateWrites(IdleTimeoutConduit.java:387) ~[undertow-core-2.0.26.Final.jar!/:2.0.26.Final]
	at org.xnio.conduits.ConduitStreamSinkChannel.close(ConduitStreamSinkChannel.java:186) ~[xnio-api-3.3.8.Final.jar!/:3.3.8.Final]
	at org.xnio.IoUtils.safeClose(IoUtils.java:134) ~[xnio-api-3.3.8.Final.jar!/:3.3.8.Final]
	at org.xnio.conduits.WriteReadyHandler$ChannelListenerHandler.forceTermination(WriteReadyHandler.java:57) ~[xnio-api-3.3.8.Final.jar!/:3.3.8.Final]
	at org.xnio.nio.NioSocketConduit.forceTermination(NioSocketConduit.java:107) ~[xnio-nio-3.3.8.Final.jar!/:3.3.8.Final]
	at org.xnio.nio.WorkerThread.run(WorkerThread.java:494) ~[xnio-nio-3.3.8.Final.jar!/:3.3.8.Final]

2022-08-22 14:54:16.840 ERROR 264186 --- [XNIO-1 I/O-1] org.xnio.listener                        : XNIO001007: A channel event listener threw an exception

java.util.concurrent.RejectedExecutionException: XNIO007007: Thread is terminating
	at org.xnio.nio.WorkerThread.execute(WorkerThread.java:590) ~[xnio-nio-3.3.8.Final.jar!/:3.3.8.Final]
	at io.undertow.websockets.jsr.UndertowSession$3.handleEvent(UndertowSession.java:396) ~[undertow-websockets-jsr-2.0.26.Final.jar!/:2.0.26.Final]
	at io.undertow.websockets.jsr.UndertowSession$3.handleEvent(UndertowSession.java:388) ~[undertow-websockets-jsr-2.0.26.Final.jar!/:2.0.26.Final]
	at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92) ~[xnio-api-3.3.8.Final.jar!/:3.3.8.Final]
	at io.undertow.server.protocol.framed.AbstractFramedChannel$FrameCloseListener.handleEvent(AbstractFramedChannel.java:1063) ~[undertow-core-2.0.26.Final.jar!/:2.0.26.Final]
	at io.undertow.server.protocol.framed.AbstractFramedChannel$FrameCloseListener.handleEvent(AbstractFramedChannel.java:978) ~[undertow-core-2.0.26.Final.jar!/:2.0.26.Final]
	at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92) ~[xnio-api-3.3.8.Final.jar!/:3.3.8.Final]
	at org.xnio.conduits.WriteReadyHandler$ChannelListenerHandler.terminated(WriteReadyHandler.java:70) ~[xnio-api-3.3.8.Final.jar!/:3.3.8.Final]
	at org.xnio.nio.NioSocketConduit.writeTerminated(NioSocketConduit.java:234) ~[xnio-nio-3.3.8.Final.jar!/:3.3.8.Final]
	at org.xnio.nio.NioSocketConduit.terminateWrites(NioSocketConduit.java:223) ~[xnio-nio-3.3.8.Final.jar!/:3.3.8.Final]
	at org.xnio.nio.NioSocketConduit.truncateWrites(NioSocketConduit.java:228) ~[xnio-nio-3.3.8.Final.jar!/:3.3.8.Final]
	at io.undertow.conduits.IdleTimeoutConduit.truncateWrites(IdleTimeoutConduit.java:387) ~[undertow-core-2.0.26.Final.jar!/:2.0.26.Final]
	at org.xnio.conduits.ConduitStreamSinkChannel.close(ConduitStreamSinkChannel.java:186) ~[xnio-api-3.3.8.Final.jar!/:3.3.8.Final]
	at org.xnio.IoUtils.safeClose(IoUtils.java:134) ~[xnio-api-3.3.8.Final.jar!/:3.3.8.Final]
	at org.xnio.conduits.WriteReadyHandler$ChannelListenerHandler.forceTermination(WriteReadyHandler.java:57) ~[xnio-api-3.3.8.Final.jar!/:3.3.8.Final]
	at org.xnio.nio.NioSocketConduit.forceTermination(NioSocketConduit.java:107) ~[xnio-nio-3.3.8.Final.jar!/:3.3.8.Final]
	at org.xnio.nio.WorkerThread.run(WorkerThread.java:494) ~[xnio-nio-3.3.8.Final.jar!/:3.3.8.Final]

Used both 3.5-rc3 and rc4

spring.log

Can you provide a whole log? The part you posted is not really relevant to song searching.

Please take a look, thank you.

You're on a very outdated build (with Lavaplayer 1.3.96-original). Please try updating first to see if this solves your issue.

You're on a very outdated build (with Lavaplayer 1.3.96-original). Please try updating first to see if this solves your issue. If your issue persists, please upload the logs from the updated build.

But the bot was running fine 12h ao with the same configuration.

Either way, we can't be certain that your issue isn't caused by outdated dependencies or missing fixes. I would hazard a guess your build is actually 3.4 which is approaching a year old. It is advised that you update to rule out an outdated build being the issue. This is generally best practice when reporting issues.

Either way, we can't be certain that your issue isn't caused by outdated dependencies or missing fixes. I would hazard a guess your build is actually 3.4 which is approaching a year old. It is advised that you update to rule out an outdated build being the issue. This is generally best practice when reporting issues.

I have deployed v3.5-rc4 and same thing happened. I tried many public lavalink server and also get the same result. Another public server hoster have confirm he is getting the same error.

Can you post your full logs again?

Can you post your full logs again?

I deleted the whole lavalink folder and installed v3.5-rc4, no logs so far. Sorry, I only have the log file with 3.4, which I posted before.

You can also just look at your console

You can also just look at your console

Thats all I have.
2022-08-22 19:16:29.403  INFO 15851 --- [           main] lavalink.server.Launcher                 : Starting Launcher using Java 16.0.1 on lava.islantay.tk with PID 15851 (/root/lavalink/Lavalink.jar started by root in /root/lavalink)
2022-08-22 19:16:29.412  INFO 15851 --- [           main] lavalink.server.Launcher                 : No active profile set, falling back to 1 default profile: "default"
2022-08-22 19:16:31.306  INFO 15851 --- [           main] lavalink.server.Launcher                 : Started Launcher in 2.704 seconds (JVM running for 3.459)
2022-08-22 19:16:31.311  INFO 15851 --- [           main] lavalink.server.Launcher                 : You can safely ignore the big red warning about illegal reflection. See https://github.com/freyacodes/Lavalink/issues/295
2022-08-22 19:16:31.407  INFO 15851 --- [           main] lavalink.server.Launcher                 :

       .   _                  _ _       _    __ _ _
      /\\ | | __ ___   ____ _| (_)_ __ | | __\ \ \ \
     ( ( )| |/ _` \ \ / / _` | | | '_ \| |/ / \ \ \ \
      \\/ | | (_| |\ V / (_| | | | | | |   <   ) ) ) )
       '  |_|\__,_| \_/ \__,_|_|_|_| |_|_|\_\ / / / /
    =========================================/_/_/_/

	Version:        3.5-rc4
	Build time:     18.08.2022 16:03:31 UTC
	Branch          HEAD
	Commit:         b69f613
	Commit time:    18.08.2022 15:52:23 UTC
	JVM:            16.0.1
	Lavaplayer      <IP_ADDRESS>-original

2022-08-22 19:16:31.423  INFO 15851 --- [           main] lavalink.server.Launcher                 : No active profile set, falling back to 1 default profile: "default"
2022-08-22 19:16:32.563  WARN 15851 --- [           main] io.undertow.websockets.jsr               : UT026010: Buffer pool was not set on WebSocketDeploymentInfo, the default pool will be used
2022-08-22 19:16:32.604  INFO 15851 --- [           main] io.undertow.servlet                      : Initializing Spring embedded WebApplicationContext
2022-08-22 19:16:32.606  INFO 15851 --- [           main] w.s.c.ServletWebServerApplicationContext : Root WebApplicationContext: initialization completed in 1172 ms
2022-08-22 19:16:32.721  WARN 15851 --- [           main] l.server.config.SentryConfiguration      : Turning off sentry
2022-08-22 19:16:33.097  INFO 15851 --- [           main] c.s.d.l.tools.GarbageCollectionMonitor   : GC monitoring enabled, reporting results every 2 minutes.
2022-08-22 19:16:33.295  INFO 15851 --- [           main] lavalink.server.config.KoeConfiguration  : OS: LINUX, Arch: X86_64
2022-08-22 19:16:33.295  INFO 15851 --- [           main] lavalink.server.config.KoeConfiguration  : Enabling JDA-NAS
2022-08-22 19:16:33.298  INFO 15851 --- [           main] c.s.l.c.natives.NativeLibraryLoader      : Native library udpqueue: loading with filter null
2022-08-22 19:16:33.306  INFO 15851 --- [           main] c.s.l.c.natives.NativeLibraryLoader      : Native library udpqueue: successfully loaded.
2022-08-22 19:16:33.757  INFO 15851 --- [           main] io.undertow                              : starting server: Undertow - 2.2.16.Final
2022-08-22 19:16:33.777  INFO 15851 --- [           main] org.xnio                                 : XNIO version 3.8.6.Final
2022-08-22 19:16:33.787  INFO 15851 --- [           main] org.xnio.nio                             : XNIO NIO Implementation Version 3.8.6.Final
2022-08-22 19:16:33.916  INFO 15851 --- [           main] org.jboss.threads                        : JBoss Threads version 3.1.0.Final
2022-08-22 19:16:33.970  INFO 15851 --- [           main] o.s.b.w.e.undertow.UndertowWebServer     : Undertow started on port(s) 8880 (http)
2022-08-22 19:16:33.985  INFO 15851 --- [           main] lavalink.server.Launcher                 : Started Launcher in 2.668 seconds (JVM running for 6.137)
2022-08-22 19:16:33.987  INFO 15851 --- [           main] lavalink.server.Launcher                 : Lavalink is ready to accept connections.
2022-08-22 19:16:34.189  INFO 15851 --- [  XNIO-1 task-1] io.undertow.servlet                      : Initializing Spring DispatcherServlet 'dispatcherServlet'
2022-08-22 19:16:34.191  INFO 15851 --- [  XNIO-1 task-1] o.s.web.servlet.DispatcherServlet        : Initializing Servlet 'dispatcherServlet'
2022-08-22 19:16:34.195  INFO 15851 --- [  XNIO-1 task-1] o.s.web.servlet.DispatcherServlet        : Completed initialization in 4 ms
2022-08-22 19:16:34.236  INFO 15851 --- [  XNIO-1 task-1] l.server.io.HandshakeInterceptorImpl     : Incoming connection from /<IP_ADDRESS>:58204
2022-08-22 19:16:34.339  INFO 15851 --- [  XNIO-1 task-1] lavalink.server.io.SocketServer          : Connection successfully established from WaveLink
2022-08-22 19:16:34.379  INFO 15851 --- [   XNIO-1 I/O-1] lavalink.server.io.SocketServer          : {"op": "configureResuming", "key": "216ea91636bf9f36", "timeout": 60}
2022-08-22 19:16:34.385  INFO 15851 --- [  XNIO-1 task-1] l.server.io.HandshakeInterceptorImpl     : Incoming connection from /<IP_ADDRESS>:58206
2022-08-22 19:16:34.400  INFO 15851 --- [  XNIO-1 task-1] lavalink.server.io.SocketServer          : Connection successfully established from erela.js
2022-08-22 19:16:34.447  INFO 15851 --- [  XNIO-1 task-1] l.server.io.HandshakeInterceptorImpl     : Incoming connection from /<IP_ADDRESS>:58208
2022-08-22 19:16:34.459  INFO 15851 --- [  XNIO-1 task-2] l.server.io.HandshakeInterceptorImpl     : Incoming connection from /<IP_ADDRESS>:58210
2022-08-22 19:16:34.461  INFO 15851 --- [  XNIO-1 task-1] lavalink.server.io.SocketServer          : Connection successfully established from erela.js
2022-08-22 19:16:34.464  INFO 15851 --- [  XNIO-1 task-2] lavalink.server.io.SocketServer          : Connection successfully established from erela.js
2022-08-22 19:16:34.476  INFO 15851 --- [  XNIO-1 task-2] l.server.io.HandshakeInterceptorImpl     : Incoming connection from /<IP_ADDRESS>:58212
2022-08-22 19:16:34.491  INFO 15851 --- [  XNIO-1 task-2] lavalink.server.io.SocketServer          : Connection successfully established from erela.js
2022-08-22 19:17:07.487 ERROR 15851 --- [  XNIO-1 task-2] l.server.io.HandshakeInterceptorImpl     : Authentication failed from /<IP_ADDRESS>:60992
2022-08-22 19:17:07.724  INFO 15851 --- [  XNIO-1 task-2] l.server.io.HandshakeInterceptorImpl     : Incoming connection from /<IP_ADDRESS>:60994
2022-08-22 19:17:07.727  INFO 15851 --- [  XNIO-1 task-2] lavalink.server.io.SocketServer          : Connection successfully established from Wavelink
2022-08-22 19:18:13.118  INFO 15851 --- [  XNIO-1 task-2] l.server.io.HandshakeInterceptorImpl     : Incoming connection from /<IP_ADDRESS>:55914
2022-08-22 19:18:13.121  INFO 15851 --- [  XNIO-1 task-2] lavalink.server.io.SocketServer          : Connection successfully established from erela.js
2022-08-22 19:18:19.047  INFO 15851 --- [   XNIO-1 I/O-2] lavalink.server.io.SocketServer          : {"op":"volume","guildId":"553794295526588434","volume":100}
2022-08-22 19:18:19.085  INFO 15851 --- [  XNIO-1 task-2] l.server.player.AudioLoaderRestHandler   : Got request to load for identifier "ytsearch:never gonna give you up"
2022-08-22 19:18:19.096  INFO 15851 --- [ader-2-thread-1] lavalink.server.player.AudioLoader       : No matches found
2022-08-22 19:18:19.377  INFO 15851 --- [   XNIO-1 I/O-2] lavalink.server.io.SocketServer          : {"sessionId":"4f51ceca3a5a0e307d935fdf17d20969","op":"voiceUpdate","guildId":"553794295526588434","event":{"token":"3c72c06fbcb71dac","guild_id":"553794295526588434","endpoint":"us-west6586.discord.media:443"}}

That's exactly what I wanted
Do you perhaps by any chance have yt or yt search disabled?

That's exactly what I wanted Do you perhaps by any chance have yt or yt search disabled?

No, I don't have them disabled.
    sources:
      youtube: false
      bandcamp: true
      soundcloud: true
      twitch: true
      vimeo: true
      http: true
      local: false
    bufferDurationMs: 400 # The duration of the NAS buffer. Higher values fare better against longer GC pauses
    frameBufferDurationMs: 5000 # How many milliseconds of audio to keep buffered
    youtubePlaylistLoadLimit: 6 # Number of pages at 100 each
    playerUpdateInterval: 10 # How frequently to send player updates to clients, in seconds
    youtubeSearchEnabled: true
    soundcloudSearchEnabled: true
    gc-warnings: true
    #ratelimit:
      #ipBlocks: ["<IP_ADDRESS>/8", "..."] # list of ip blocks
      #excludedIps: ["...", "..."] # ips which should be explicit excluded from usage by lavalink
      #strategy: "RotateOnBan" # RotateOnBan | LoadBalance | NanoSwitch | RotatingNanoSwitch
      #searchTriggersFail: true # Whether a search 429 should trigger marking the ip as failing
      #retryLimit: -1 # -1 = use default lavaplayer value | 0 = infinity | >0 = retry will happen this numbers times

Does trying to play a YouTube URL work?

That's exactly what I wanted Do you perhaps by any chance have yt or yt search disabled?

No, No matches found for - https://www.youtube.com/watch?v=uVeSf_vIeAE&list=RDuVeSf_vIeAE&start_radio=1

There is literally a false for yt in your yml

Does trying to play a YouTube URL work?

If you want me to set true for Youtube in application.yml, I also did that with the youtube link. It doesn't work.
2022-08-22 19:29:08.591  INFO 16947 --- [           main] lavalink.server.Launcher                 : Starting Launcher using Java 16.0.1 on lava.islantay.tk with PID 16947 (/root/lavalink/Lavalink.jar started by root in /root/lavalink)
2022-08-22 19:29:08.594  INFO 16947 --- [           main] lavalink.server.Launcher                 : No active profile set, falling back to 1 default profile: "default"
2022-08-22 19:29:10.480  INFO 16947 --- [           main] lavalink.server.Launcher                 : Started Launcher in 2.676 seconds (JVM running for 3.437)
2022-08-22 19:29:10.485  INFO 16947 --- [           main] lavalink.server.Launcher                 : You can safely ignore the big red warning about illegal reflection. See https://github.com/freyacodes/Lavalink/issues/295
2022-08-22 19:29:10.596  INFO 16947 --- [           main] lavalink.server.Launcher                 :

       .   _                  _ _       _    __ _ _
      /\\ | | __ ___   ____ _| (_)_ __ | | __\ \ \ \
     ( ( )| |/ _` \ \ / / _` | | | '_ \| |/ / \ \ \ \
      \\/ | | (_| |\ V / (_| | | | | | |   <   ) ) ) )
       '  |_|\__,_| \_/ \__,_|_|_|_| |_|_|\_\ / / / /
    =========================================/_/_/_/

	Version:        3.5-rc4
	Build time:     18.08.2022 16:03:31 UTC
	Branch          HEAD
	Commit:         b69f613
	Commit time:    18.08.2022 15:52:23 UTC
	JVM:            16.0.1
	Lavaplayer      <IP_ADDRESS>-original

2022-08-22 19:29:10.604  INFO 16947 --- [           main] lavalink.server.Launcher                 : No active profile set, falling back to 1 default profile: "default"
2022-08-22 19:29:11.829  WARN 16947 --- [           main] io.undertow.websockets.jsr               : UT026010: Buffer pool was not set on WebSocketDeploymentInfo, the default pool will be used
2022-08-22 19:29:11.868  INFO 16947 --- [           main] io.undertow.servlet                      : Initializing Spring embedded WebApplicationContext
2022-08-22 19:29:11.869  INFO 16947 --- [           main] w.s.c.ServletWebServerApplicationContext : Root WebApplicationContext: initialization completed in 1250 ms
2022-08-22 19:29:11.995  WARN 16947 --- [           main] l.server.config.SentryConfiguration      : Turning off sentry
2022-08-22 19:29:12.387  INFO 16947 --- [           main] c.s.d.l.tools.GarbageCollectionMonitor   : GC monitoring enabled, reporting results every 2 minutes.
2022-08-22 19:29:12.712  INFO 16947 --- [           main] lavalink.server.config.KoeConfiguration  : OS: LINUX, Arch: X86_64
2022-08-22 19:29:12.712  INFO 16947 --- [           main] lavalink.server.config.KoeConfiguration  : Enabling JDA-NAS
2022-08-22 19:29:12.716  INFO 16947 --- [           main] c.s.l.c.natives.NativeLibraryLoader      : Native library udpqueue: loading with filter null
2022-08-22 19:29:12.724  INFO 16947 --- [           main] c.s.l.c.natives.NativeLibraryLoader      : Native library udpqueue: successfully loaded.
2022-08-22 19:29:13.242  INFO 16947 --- [           main] io.undertow                              : starting server: Undertow - 2.2.16.Final
2022-08-22 19:29:13.254  INFO 16947 --- [           main] org.xnio                                 : XNIO version 3.8.6.Final
2022-08-22 19:29:13.277  INFO 16947 --- [           main] org.xnio.nio                             : XNIO NIO Implementation Version 3.8.6.Final
2022-08-22 19:29:13.400  INFO 16947 --- [           main] org.jboss.threads                        : JBoss Threads version 3.1.0.Final
2022-08-22 19:29:13.471  INFO 16947 --- [           main] o.s.b.w.e.undertow.UndertowWebServer     : Undertow started on port(s) 8880 (http)
2022-08-22 19:29:13.480  INFO 16947 --- [           main] lavalink.server.Launcher                 : Started Launcher in 2.983 seconds (JVM running for 6.437)
2022-08-22 19:29:13.489  INFO 16947 --- [           main] lavalink.server.Launcher                 : Lavalink is ready to accept connections.
2022-08-22 19:29:23.335  INFO 16947 --- [  XNIO-1 task-1] io.undertow.servlet                      : Initializing Spring DispatcherServlet 'dispatcherServlet'
2022-08-22 19:29:23.339  INFO 16947 --- [  XNIO-1 task-1] o.s.web.servlet.DispatcherServlet        : Initializing Servlet 'dispatcherServlet'
2022-08-22 19:29:23.341  INFO 16947 --- [  XNIO-1 task-1] o.s.web.servlet.DispatcherServlet        : Completed initialization in 2 ms
2022-08-22 19:29:23.365  INFO 16947 --- [  XNIO-1 task-1] l.server.io.HandshakeInterceptorImpl     : Incoming connection from /<IP_ADDRESS>:44342
2022-08-22 19:29:23.463  INFO 16947 --- [  XNIO-1 task-1] lavalink.server.io.SocketServer          : Connection successfully established from erela.js
2022-08-22 19:29:24.845 ERROR 16947 --- [  XNIO-1 task-1] l.server.io.HandshakeInterceptorImpl     : Authentication failed from /<IP_ADDRESS>:44344
2022-08-22 19:29:25.047  INFO 16947 --- [  XNIO-1 task-1] l.server.io.HandshakeInterceptorImpl     : Incoming connection from /<IP_ADDRESS>:44346
2022-08-22 19:29:25.054  INFO 16947 --- [  XNIO-1 task-1] lavalink.server.io.SocketServer          : Connection successfully established from Wavelink
2022-08-22 19:29:25.947  INFO 16947 --- [   XNIO-1 I/O-1] lavalink.server.io.SocketServer          : {"op":"volume","guildId":"553794295526588434","volume":100}
2022-08-22 19:29:25.970  INFO 16947 --- [  XNIO-1 task-1] l.server.player.AudioLoaderRestHandler   : Got request to load for identifier "ytsearch:never gonna give you up"
2022-08-22 19:29:26.064  INFO 16947 --- [   XNIO-1 I/O-1] lavalink.server.io.SocketServer          : {"sessionId":"92ba1a979ed284d270b9e41b4689e12d","op":"voiceUpdate","guildId":"553794295526588434","event":{"token":"3c72c06fbcb71dac","guild_id":"553794295526588434","endpoint":"us-west6586.discord.media:443"}}
2022-08-22 19:29:27.194  INFO 16947 --- [ader-2-thread-1] lavalink.server.player.AudioLoader       : Loaded playlist Search results for: never gonna give you up
2022-08-22 19:29:42.030  INFO 16947 --- [  XNIO-1 task-1] l.server.io.HandshakeInterceptorImpl     : Incoming connection from /<IP_ADDRESS>:33172
2022-08-22 19:29:42.037  INFO 16947 --- [  XNIO-1 task-1] lavalink.server.io.SocketServer          : Connection successfully established from WaveLink
2022-08-22 19:29:42.062  INFO 16947 --- [   XNIO-1 I/O-2] lavalink.server.io.SocketServer          : {"op": "configureResuming", "key": "216ea91636bf9f36", "timeout": 60}
2022-08-22 19:30:12.524  INFO 16947 --- [  XNIO-1 task-1] l.server.player.AudioLoaderRestHandler   : Got request to load for identifier "ytsearch:Mic"
2022-08-22 19:30:13.051  INFO 16947 --- [ader-2-thread-1] lavalink.server.player.AudioLoader       : Loaded playlist Search results for: Mic
2022-08-22 19:30:38.444  INFO 16947 --- [  XNIO-1 task-1] l.server.player.AudioLoaderRestHandler   : Got request to load for identifier "https://www.youtube.com/watch?v=EumXak7TyQ0"
2022-08-22 19:30:38.448  WARN 16947 --- [ader-2-thread-1] c.s.d.l.s.y.YoutubeAccessTokenTracker    : YouTube auth tokens can't be retrieved because email and password is not set in YoutubeAudioSourceManager, age restricted videos will throw exceptions.
2022-08-22 19:30:38.948  INFO 16947 --- [ader-2-thread-1] lavalink.server.player.AudioLoader       : Loaded track Why I Don't Use Else When Programming
2022-08-22 19:31:25.780  INFO 16947 --- [  XNIO-1 task-1] l.server.player.AudioLoaderRestHandler   : Got request to load for identifier "https://www.youtube.com/watch?v=uVeSf_vIeAE&list=RDuVeSf_vIeAE&start_radio=1"
2022-08-22 19:31:26.361  INFO 16947 --- [ader-2-thread-1] lavalink.server.player.AudioLoader       : Loaded playlist Mix - 【HD】Sleepless Nights - Aimer - Re:pray【ENG Sub】

There is literally a false for yt in your yml

I turned that off because I was suspecting it is youtube's issue

Well you can clearly see it providing a result now
How do you expect yt to work when you disable it lmao

Well you can clearly see it providing a result now
How do you expect yt to work when you disable it lmao

But still gives No matches found for - Musicname

No I can't see that in the logs. This was resolved by upgrading to 3.5-rc4

No I can't see that in the logs. This was resolved by upgrading to 3.5-rc4

The error on the top
(java.util.concurrent.RejectedExecutionException: XNIO007007: Thread is terminating)
was actually caused by v3.5-rc2/3/4. I was running lavalink with supervisor, I replaced the old 3.4 with 3.5-rc4, I don't know why in log file it still shows as 3.4. I have installed v3.4 again and here is the log, It gives errors to youtube link but it works when you try to search with keywords.
2022-08-22 19:46:03.639  INFO 18381 --- [           main] lavalink.server.Launcher                 :

       .   _                  _ _       _    __ _ _
      /\\ | | __ ___   ____ _| (_)_ __ | | __\ \ \ \
     ( ( )| |/ _` \ \ / / _` | | | '_ \| |/ / \ \ \ \
      \\/ | | (_| |\ V / (_| | | | | | |   <   ) ) ) )
       '  |_|\__,_| \_/ \__,_|_|_|_| |_|_|\_\ / / / /
    =========================================/_/_/_/

	Version:        3.4
	Build:          1257
	Build time:     26.10.2021 14:18:37 UTC
	Branch          master
	Commit:         a364833
	Commit time:    26.10.2021 14:15:20 UTC
	JVM:            16.0.1
	Lavaplayer      1.3.96-original

2022-08-22 19:46:03.809  INFO 18381 --- [           main] lavalink.server.Launcher                 : Starting Launcher on lava.islantay.tk with PID 18381 (/root/lavalink/Lavalink.jar started by root in /root/lavalink)
2022-08-22 19:46:03.815  INFO 18381 --- [           main] lavalink.server.Launcher                 : No active profile set, falling back to default profiles: default
2022-08-22 19:46:03.950  WARN 18381 --- [kground-preinit] o.s.h.c.j.Jackson2ObjectMapperBuilder    : For Jackson Kotlin classes support please add "com.fasterxml.jackson.module:jackson-module-kotlin" to the classpath
2022-08-22 19:46:05.645  WARN 18381 --- [           main] io.undertow.websockets.jsr               : UT026010: Buffer pool was not set on WebSocketDeploymentInfo, the default pool will be used
2022-08-22 19:46:05.670  INFO 18381 --- [           main] io.undertow.servlet                      : Initializing Spring embedded WebApplicationContext
2022-08-22 19:46:05.670  INFO 18381 --- [           main] o.s.web.context.ContextLoader            : Root WebApplicationContext: initialization completed in 1755 ms
2022-08-22 19:46:06.016  WARN 18381 --- [           main] l.server.config.SentryConfiguration      : Turning off sentry
2022-08-22 19:46:06.464  INFO 18381 --- [           main] c.s.d.l.tools.GarbageCollectionMonitor   : GC monitoring enabled, reporting results every 2 minutes.
2022-08-22 19:46:06.717  INFO 18381 --- [           main] lavalink.server.config.KoeConfiguration  : OS: Linux, Arch: amd64
2022-08-22 19:46:06.718  INFO 18381 --- [           main] lavalink.server.config.KoeConfiguration  : Enabling JDA-NAS
2022-08-22 19:46:06.720  INFO 18381 --- [           main] c.s.l.c.natives.NativeLibraryLoader      : Native library udpqueue: loading with filter null
2022-08-22 19:46:06.723  INFO 18381 --- [           main] c.s.l.c.natives.NativeLibraryLoader      : Native library udpqueue: successfully loaded.
2022-08-22 19:46:07.135  INFO 18381 --- [           main] o.s.s.concurrent.ThreadPoolTaskExecutor  : Initializing ExecutorService 'applicationTaskExecutor'
2022-08-22 19:46:07.627  INFO 18381 --- [           main] org.xnio                                 : XNIO version 3.3.8.Final
2022-08-22 19:46:07.641  INFO 18381 --- [           main] org.xnio.nio                             : XNIO NIO Implementation Version 3.3.8.Final
2022-08-22 19:46:07.724  INFO 18381 --- [           main] o.s.b.w.e.u.UndertowServletWebServer     : Undertow started on port(s) 8880 (http) with context path ''
2022-08-22 19:46:07.732  INFO 18381 --- [           main] lavalink.server.Launcher                 : Started Launcher in 5.057 seconds (JVM running for 5.812)
2022-08-22 19:46:07.733  INFO 18381 --- [           main] lavalink.server.Launcher                 : You can safely ignore the big red warning about illegal reflection. See https://github.com/freyacodes/Lavalink/issues/295
2022-08-22 19:46:08.788  INFO 18381 --- [  XNIO-1 task-1] io.undertow.servlet                      : Initializing Spring DispatcherServlet 'dispatcherServlet'
2022-08-22 19:46:08.788  INFO 18381 --- [  XNIO-1 task-1] o.s.web.servlet.DispatcherServlet        : Initializing Servlet 'dispatcherServlet'
2022-08-22 19:46:08.803  INFO 18381 --- [  XNIO-1 task-1] o.s.web.servlet.DispatcherServlet        : Completed initialization in 14 ms
2022-08-22 19:46:08.828  INFO 18381 --- [  XNIO-1 task-1] l.server.io.HandshakeInterceptorImpl     : Incoming connection from /<IP_ADDRESS>:34140
2022-08-22 19:46:08.893  INFO 18381 --- [  XNIO-1 task-1] lavalink.server.io.SocketServer          : Connection successfully established from WaveLink
2022-08-22 19:46:08.923  INFO 18381 --- [   XNIO-1 I/O-1] lavalink.server.io.SocketServer          : {"op": "configureResuming", "key": "216ea91636bf9f36", "timeout": 60}
2022-08-22 19:46:11.563 ERROR 18381 --- [  XNIO-1 task-2] l.server.io.HandshakeInterceptorImpl     : Authentication failed from /<IP_ADDRESS>:34150
2022-08-22 19:46:11.783  INFO 18381 --- [  XNIO-1 task-3] l.server.io.HandshakeInterceptorImpl     : Incoming connection from /<IP_ADDRESS>:59688
2022-08-22 19:46:11.785  INFO 18381 --- [  XNIO-1 task-3] lavalink.server.io.SocketServer          : Connection successfully established from Wavelink
2022-08-22 19:46:14.792  INFO 18381 --- [  XNIO-1 task-4] l.server.io.HandshakeInterceptorImpl     : Incoming connection from /<IP_ADDRESS>:59690
2022-08-22 19:46:14.796  INFO 18381 --- [  XNIO-1 task-4] lavalink.server.io.SocketServer          : Connection successfully established from erela.js
2022-08-22 19:46:19.080  INFO 18381 --- [   XNIO-1 I/O-1] lavalink.server.io.SocketServer          : {"op":"volume","guildId":"553794295526588434","volume":100}
2022-08-22 19:46:19.125  INFO 18381 --- [  XNIO-1 task-5] l.server.player.AudioLoaderRestHandler   : Got request to load for identifier "https://www.youtube.com/watch?v=uVeSf_vIeAE&list=RDuVeSf_vIeAE&start_radio=1"
2022-08-22 19:46:19.249  INFO 18381 --- [   XNIO-1 I/O-1] lavalink.server.io.SocketServer          : {"sessionId":"ac88127ebb89a791f2962ecb3a3b6e57","op":"voiceUpdate","guildId":"553794295526588434","event":{"token":"6c9431df6de6003f","guild_id":"553794295526588434","endpoint":"us-west6586.discord.media:443"}}
2022-08-22 19:46:19.823 ERROR 18381 --- [ader-2-thread-1] lavalink.server.player.AudioLoader       : Load failed

com.sedmelluq.discord.lavaplayer.tools.FriendlyException: Unknown file format.
	at com.sedmelluq.discord.lavaplayer.source.ProbingAudioSourceManager.handleLoadResult(ProbingAudioSourceManager.java:34) ~[lavaplayer-fork-1.3.96.jar!/:na]
	at com.sedmelluq.discord.lavaplayer.source.http.HttpAudioSourceManager.loadItem(HttpAudioSourceManager.java:81) ~[lavaplayer-fork-1.3.96.jar!/:na]
	at com.sedmelluq.discord.lavaplayer.player.DefaultAudioPlayerManager.checkSourcesForItemOnce(DefaultAudioPlayerManager.java:436) ~[lavaplayer-fork-1.3.96.jar!/:na]
	at com.sedmelluq.discord.lavaplayer.player.DefaultAudioPlayerManager.checkSourcesForItem(DefaultAudioPlayerManager.java:418) ~[lavaplayer-fork-1.3.96.jar!/:na]
	at com.sedmelluq.discord.lavaplayer.player.DefaultAudioPlayerManager.lambda$createItemLoader$0(DefaultAudioPlayerManager.java:217) ~[lavaplayer-fork-1.3.96.jar!/:na]
	at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264) ~[na:na]
	at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1130) ~[na:na]
	at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:630) ~[na:na]
	at java.base/java.lang.Thread.run(Thread.java:831) ~[na:na]
	Suppressed: com.sedmelluq.discord.lavaplayer.tools.exception.EnvironmentInformation:
  lavaplayer.version: 1.3.96-original
  os.arch: amd64
  os.name: Linux
  os.version: 5.4.0-124-generic
  java.vendor: Private Build
  java.version: 16.0.1
  java.runtime.version: 16.0.1+9-Ubuntu-120.04
  java.vm.version: 16.0.1+9-Ubuntu-120.04

2022-08-22 19:46:19.829 ERROR 18381 --- [ader-2-thread-1] l.server.player.AudioLoaderRestHandler   : Track loading failed

com.sedmelluq.discord.lavaplayer.tools.FriendlyException: Unknown file format.
	at com.sedmelluq.discord.lavaplayer.source.ProbingAudioSourceManager.handleLoadResult(ProbingAudioSourceManager.java:34) ~[lavaplayer-fork-1.3.96.jar!/:na]
	at com.sedmelluq.discord.lavaplayer.source.http.HttpAudioSourceManager.loadItem(HttpAudioSourceManager.java:81) ~[lavaplayer-fork-1.3.96.jar!/:na]
	at com.sedmelluq.discord.lavaplayer.player.DefaultAudioPlayerManager.checkSourcesForItemOnce(DefaultAudioPlayerManager.java:436) ~[lavaplayer-fork-1.3.96.jar!/:na]
	at com.sedmelluq.discord.lavaplayer.player.DefaultAudioPlayerManager.checkSourcesForItem(DefaultAudioPlayerManager.java:418) ~[lavaplayer-fork-1.3.96.jar!/:na]
	at com.sedmelluq.discord.lavaplayer.player.DefaultAudioPlayerManager.lambda$createItemLoader$0(DefaultAudioPlayerManager.java:217) ~[lavaplayer-fork-1.3.96.jar!/:na]
	at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264) ~[na:na]
	at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1130) ~[na:na]
	at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:630) ~[na:na]
	at java.base/java.lang.Thread.run(Thread.java:831) ~[na:na]
	Suppressed: com.sedmelluq.discord.lavaplayer.tools.exception.EnvironmentInformation:
  lavaplayer.version: 1.3.96-original
  os.arch: amd64
  os.name: Linux
  os.version: 5.4.0-124-generic
  java.vendor: Private Build
  java.version: 16.0.1
  java.runtime.version: 16.0.1+9-Ubuntu-120.04
  java.vm.version: 16.0.1+9-Ubuntu-120.04

2022-08-22 19:46:26.495  INFO 18381 --- [  XNIO-1 task-7] l.server.io.HandshakeInterceptorImpl     : Incoming connection from /<IP_ADDRESS>:44754
2022-08-22 19:46:26.500  INFO 18381 --- [  XNIO-1 task-7] lavalink.server.io.SocketServer          : Connection successfully established from DiscordMusic/v5.0.0-beta (Bot:<PHONE_NUMBER>18433301)
2022-08-22 19:46:40.147  INFO 18381 --- [  XNIO-1 task-8] l.server.player.AudioLoaderRestHandler   : Got request to load for identifier "ytsearch:never gonna give you up"
2022-08-22 19:46:40.148  INFO 18381 --- [ader-2-thread-1] lavalink.server.player.AudioLoader       : No matches found

The error on the top(java.util.concurrent.RejectedExecutionException: XNIO007007: Thread is terminating) was actually caused by v3.5-rc2/3/4

That usually only appears when a connection is closed or the jar is shutting down. Please use the RC4 jar and provide a full log.

Okay so this is getting nowhere and we're just going in circles.
You're providing No matches found logs for an outdated Lavalink build, this was a known issue that has been resolved in rc3 and rc4.
Thread is terminating is caused by your Lavalink jar quitting, or the websocket connection between Lavalink and your bot closing, as evidenced by the lines in your log resembling:
2022-08-22 00:15:55.482  INFO 264186 --- [XNIO-1 I/O-1] lavalink.server.io.SocketServer          : Connection closed from /<IP_ADDRESS>:35822 -- CloseStatus[code=1006, reason=]
```.

Closing this issue as resolved for now. If there's further discussion to be had, please direct it into the Discord server linked in README.

The error on the top(java.util.concurrent.RejectedExecutionException: XNIO007007: Thread is terminating) was actually caused by v3.5-rc2/3/4

That usually only appears when a connection is closed or the jar is shutting down. Please use the RC4 jar and provide a full log.

2022-08-22 20:34:28.832  INFO 22582 --- [           main] lavalink.server.Launcher                 : Starting Launcher using Java 16.0.1 on lava.islantay.tk with PID 22582 (/root/lavalink/Lavalink.jar started by root in /root/lavalink)
2022-08-22 20:34:28.840  INFO 22582 --- [           main] lavalink.server.Launcher                 : No active profile set, falling back to 1 default profile: "default"
2022-08-22 20:34:30.775  INFO 22582 --- [           main] lavalink.server.Launcher                 : Started Launcher in 2.802 seconds (JVM running for 3.553)
2022-08-22 20:34:30.787  INFO 22582 --- [           main] lavalink.server.Launcher                 : You can safely ignore the big red warning about illegal reflection. See https://github.com/freyacodes/Lavalink/issues/295
2022-08-22 20:34:30.895  INFO 22582 --- [           main] lavalink.server.Launcher                 :

       .   _                  _ _       _    __ _ _
      /\\ | | __ ___   ____ _| (_)_ __ | | __\ \ \ \
     ( ( )| |/ _` \ \ / / _` | | | '_ \| |/ / \ \ \ \
      \\/ | | (_| |\ V / (_| | | | | | |   <   ) ) ) )
       '  |_|\__,_| \_/ \__,_|_|_|_| |_|_|\_\ / / / /
    =========================================/_/_/_/

	Version:        3.5-rc4
	Build time:     18.08.2022 16:03:31 UTC
	Branch          HEAD
	Commit:         b69f613
	Commit time:    18.08.2022 15:52:23 UTC
	JVM:            16.0.1
	Lavaplayer      <IP_ADDRESS>-original

2022-08-22 20:34:30.908  INFO 22582 --- [           main] lavalink.server.Launcher                 : No active profile set, falling back to 1 default profile: "default"
2022-08-22 20:34:31.968  WARN 22582 --- [           main] io.undertow.websockets.jsr               : UT026010: Buffer pool was not set on WebSocketDeploymentInfo, the default pool will be used
2022-08-22 20:34:32.004  INFO 22582 --- [           main] io.undertow.servlet                      : Initializing Spring embedded WebApplicationContext
2022-08-22 20:34:32.004  INFO 22582 --- [           main] w.s.c.ServletWebServerApplicationContext : Root WebApplicationContext: initialization completed in 1081 ms
2022-08-22 20:34:32.127  WARN 22582 --- [           main] l.server.config.SentryConfiguration      : Turning off sentry
2022-08-22 20:34:32.535  INFO 22582 --- [           main] c.s.d.l.tools.GarbageCollectionMonitor   : GC monitoring enabled, reporting results every 2 minutes.
2022-08-22 20:34:32.746  INFO 22582 --- [           main] lavalink.server.config.KoeConfiguration  : OS: LINUX, Arch: X86_64
2022-08-22 20:34:32.746  INFO 22582 --- [           main] lavalink.server.config.KoeConfiguration  : Enabling JDA-NAS
2022-08-22 20:34:32.749  INFO 22582 --- [           main] c.s.l.c.natives.NativeLibraryLoader      : Native library udpqueue: loading with filter null
2022-08-22 20:34:32.755  INFO 22582 --- [           main] c.s.l.c.natives.NativeLibraryLoader      : Native library udpqueue: successfully loaded.
2022-08-22 20:34:33.254  INFO 22582 --- [           main] io.undertow                              : starting server: Undertow - 2.2.16.Final
2022-08-22 20:34:33.266  INFO 22582 --- [           main] org.xnio                                 : XNIO version 3.8.6.Final
2022-08-22 20:34:33.291  INFO 22582 --- [           main] org.xnio.nio                             : XNIO NIO Implementation Version 3.8.6.Final
2022-08-22 20:34:33.412  INFO 22582 --- [           main] org.jboss.threads                        : JBoss Threads version 3.1.0.Final
2022-08-22 20:34:33.477  INFO 22582 --- [           main] o.s.b.w.e.undertow.UndertowWebServer     : Undertow started on port(s) 8880 (http)
2022-08-22 20:34:33.485  INFO 22582 --- [           main] lavalink.server.Launcher                 : Started Launcher in 2.689 seconds (JVM running for 6.264)
2022-08-22 20:34:33.491  INFO 22582 --- [           main] lavalink.server.Launcher                 : Lavalink is ready to accept connections.
2022-08-22 20:34:35.022  INFO 22582 --- [  XNIO-1 task-1] io.undertow.servlet                      : Initializing Spring DispatcherServlet 'dispatcherServlet'
2022-08-22 20:34:35.023  INFO 22582 --- [  XNIO-1 task-1] o.s.web.servlet.DispatcherServlet        : Initializing Servlet 'dispatcherServlet'
2022-08-22 20:34:35.025  INFO 22582 --- [  XNIO-1 task-1] o.s.web.servlet.DispatcherServlet        : Completed initialization in 2 ms
2022-08-22 20:34:35.046 ERROR 22582 --- [  XNIO-1 task-1] l.server.io.HandshakeInterceptorImpl     : Authentication failed from /<IP_ADDRESS>:59374
2022-08-22 20:34:35.293  INFO 22582 --- [  XNIO-1 task-1] l.server.io.HandshakeInterceptorImpl     : Incoming connection from /<IP_ADDRESS>:59376
2022-08-22 20:34:35.337  INFO 22582 --- [  XNIO-1 task-1] lavalink.server.io.SocketServer          : Connection successfully established from Wavelink
2022-08-22 20:34:36.484  INFO 22582 --- [  XNIO-1 task-1] l.server.io.HandshakeInterceptorImpl     : Incoming connection from /<IP_ADDRESS>:59378
2022-08-22 20:34:36.487  INFO 22582 --- [  XNIO-1 task-1] lavalink.server.io.SocketServer          : Connection successfully established from WaveLink
2022-08-22 20:34:36.518  INFO 22582 --- [   XNIO-1 I/O-2] lavalink.server.io.SocketServer          : {"op": "configureResuming", "key": "216ea91636bf9f36", "timeout": 60}
2022-08-22 20:38:36.600  INFO 22582 --- [  XNIO-1 task-1] l.server.io.HandshakeInterceptorImpl     : Incoming connection from /<IP_ADDRESS>:40306
2022-08-22 20:38:36.603  INFO 22582 --- [  XNIO-1 task-1] lavalink.server.io.SocketServer          : Connection successfully established from DiscordMusic/v5.0.0-beta (Bot:<PHONE_NUMBER>18433301)
2022-08-22 20:43:03.016  INFO 22582 --- [  XNIO-1 task-1] l.server.io.HandshakeInterceptorImpl     : Incoming connection from /<IP_ADDRESS>:53612
2022-08-22 20:43:03.024  INFO 22582 --- [  XNIO-1 task-1] lavalink.server.io.SocketServer          : Connection successfully established from erela.js
2022-08-22 20:43:22.358  INFO 22582 --- [   XNIO-1 I/O-2] lavalink.server.io.SocketServer          : {"op":"volume","guildId":"553794295526588434","volume":100}
2022-08-22 20:43:22.401  INFO 22582 --- [  XNIO-1 task-1] l.server.player.AudioLoaderRestHandler   : Got request to load for identifier "https://www.youtube.com/watch?v=uVeSf_vIeAE&list=RDuVeSf_vIeAE&start_radio=1"
2022-08-22 20:43:22.714  INFO 22582 --- [   XNIO-1 I/O-2] lavalink.server.io.SocketServer          : {"sessionId":"3a7a7fe05f0143cf500da1d14cedd91f","op":"voiceUpdate","guildId":"553794295526588434","event":{"token":"a8d46b84e349df48","guild_id":"553794295526588434","endpoint":"us-west6643.discord.media:443"}}
2022-08-22 20:43:23.049 ERROR 22582 --- [ader-2-thread-1] lavalink.server.player.AudioLoader       : Load failed

com.sedmelluq.discord.lavaplayer.tools.FriendlyException: Unknown file format.
	at com.sedmelluq.discord.lavaplayer.source.ProbingAudioSourceManager.handleLoadResult(ProbingAudioSourceManager.java:34) ~[lavaplayer-<IP_ADDRESS>.jar!/:na]
	at com.sedmelluq.discord.lavaplayer.source.http.HttpAudioSourceManager.loadItem(HttpAudioSourceManager.java:81) ~[lavaplayer-<IP_ADDRESS>.jar!/:na]
	at com.sedmelluq.discord.lavaplayer.player.DefaultAudioPlayerManager.checkSourcesForItemOnce(DefaultAudioPlayerManager.java:436) ~[lavaplayer-<IP_ADDRESS>.jar!/:na]
	at com.sedmelluq.discord.lavaplayer.player.DefaultAudioPlayerManager.checkSourcesForItem(DefaultAudioPlayerManager.java:418) ~[lavaplayer-<IP_ADDRESS>.jar!/:na]
	at com.sedmelluq.discord.lavaplayer.player.DefaultAudioPlayerManager.lambda$createItemLoader$0(DefaultAudioPlayerManager.java:217) ~[lavaplayer-<IP_ADDRESS>.jar!/:na]
	at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264) ~[na:na]
	at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1130) ~[na:na]
	at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:630) ~[na:na]
	at java.base/java.lang.Thread.run(Thread.java:831) ~[na:na]
	Suppressed: com.sedmelluq.discord.lavaplayer.tools.exception.EnvironmentInformation:
  lavaplayer.version: <IP_ADDRESS>-original
  os.arch: amd64
  os.name: Linux
  os.version: 5.4.0-124-generic
  java.vendor: Private Build
  java.version: 16.0.1
  java.runtime.version: 16.0.1+9-Ubuntu-120.04
  java.vm.version: 16.0.1+9-Ubuntu-120.04

2022-08-22 20:43:23.060 ERROR 22582 --- [ader-2-thread-1] l.server.player.AudioLoaderRestHandler   : Track loading failed

com.sedmelluq.discord.lavaplayer.tools.FriendlyException: Unknown file format.
	at com.sedmelluq.discord.lavaplayer.source.ProbingAudioSourceManager.handleLoadResult(ProbingAudioSourceManager.java:34) ~[lavaplayer-<IP_ADDRESS>.jar!/:na]
	at com.sedmelluq.discord.lavaplayer.source.http.HttpAudioSourceManager.loadItem(HttpAudioSourceManager.java:81) ~[lavaplayer-<IP_ADDRESS>.jar!/:na]
	at com.sedmelluq.discord.lavaplayer.player.DefaultAudioPlayerManager.checkSourcesForItemOnce(DefaultAudioPlayerManager.java:436) ~[lavaplayer-<IP_ADDRESS>.jar!/:na]
	at com.sedmelluq.discord.lavaplayer.player.DefaultAudioPlayerManager.checkSourcesForItem(DefaultAudioPlayerManager.java:418) ~[lavaplayer-<IP_ADDRESS>.jar!/:na]
	at com.sedmelluq.discord.lavaplayer.player.DefaultAudioPlayerManager.lambda$createItemLoader$0(DefaultAudioPlayerManager.java:217) ~[lavaplayer-<IP_ADDRESS>.jar!/:na]
	at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264) ~[na:na]
	at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1130) ~[na:na]
	at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:630) ~[na:na]
	at java.base/java.lang.Thread.run(Thread.java:831) ~[na:na]
	Suppressed: com.sedmelluq.discord.lavaplayer.tools.exception.EnvironmentInformation:
  lavaplayer.version: <IP_ADDRESS>-original
  os.arch: amd64
  os.name: Linux
  os.version: 5.4.0-124-generic
  java.vendor: Private Build
  java.version: 16.0.1
  java.runtime.version: 16.0.1+9-Ubuntu-120.04
  java.vm.version: 16.0.1+9-Ubuntu-120.04

2022-08-22 20:45:23.104  INFO 22582 --- [  XNIO-1 task-1] l.server.player.AudioLoaderRestHandler   : Got request to load for identifier "ytsearch:Mic"
2022-08-22 20:45:23.105  INFO 22582 --- [ader-2-thread-1] lavalink.server.player.AudioLoader       : No matches found

Okay so this is getting nowhere and we're just going in circles.
You're providing No matches found logs for an outdated Lavalink build, this was a known issue that has been resolved in rc3 and rc4.
Thread is terminating is caused by your Lavalink jar quitting, or the websocket connection between Lavalink and your bot closing, as evidenced by the lines in your log resembling:
2022-08-22 00:15:55.482  INFO 264186 --- [XNIO-1 I/O-1] lavalink.server.io.SocketServer          : Connection closed from /<IP_ADDRESS>:35822 -- CloseStatus[code=1006, reason=]

Closing this issue as resolved for now. If there's further discussion to be had, please direct it into the Discord server linked in README.

You can see even in 3.5-rc4 it is still no matches found.

Misconfigured Lavalink. Again, please redirect your discussion to the Discord server. That URL works for me on the rc4 Lavalink build.


Formatting damaged while replacing text

Using a well formatted PPT template, I tried to replace a string within all existing components to get a well formatted customized presentation.
The text replacement worked fine, but the formatting was quite damaged making the PPT unusable for a  presentation. Is there a way to avoid damaging the formatting while replaceing the text placeholders?
Here the method I used to do the replacement:
for slide in ppt.slides:
    for shape in slide.shapes:
        if shape.has_text_frame:
            shape.text = shape.text.replace(   search_str    ,    repl_str    )

@some this is really a support question. The behavior you're seeing is the expected behavior. The short version is you need to replace text at the run level if you want to preserve formatting. If you post your question on StackOverflow (using the python-docx tag) you can receive a more detailed answer. Make sure to post there a picture of the resulting formatting along with this code you used.


Error on helm-run following quick-start instructions

Hi team,
I'm trying to use HELM to test performance on bunch of open-source LLMs (Cerebras, GLM, etc.) on different scenarios (e.g., code generation, common sense reasoning). I'm building the test using SageMaker notebook instance.
I'm new to HELM so I start with pip install my model in the Sagemaker environment and try following code
echo 'entries: [{description: "mmlu:subject=philosophy,model=huggingface/gpt2", priority: 1}]' > run_specs.conf
helm-run --conf-paths run_specs.conf --suite v1 --max-eval-instances 10
Firstly, it returns error saying '[Errno 2] No such file or directory: 'proxy_api_key.txt'
Then we create a proxy_api_key.txt thru vim proxy_api_key.txt and insert with API from Hugging Face User Access Tokens. However, we get error AuthenticationError(f"Invalid API key {auth.api_key}").
Then we replace the API key with HuggingFace GPT-2 inference API from https://huggingface.co/gpt2 and still get the same error.
We wonder how can we fix this issue. Thanks for your help!

This should be fixed with #1584, thanks for reporting the bug!

The v0.2.3 fixed this.
Please, add the following to https://crfm-helm.readthedocs.io/en/latest/tutorial/:
For MacBook before running '$run-helm', install 'wget' via
$brew install wget
'$pip install wget' does not work on MacBook, at least not on OS Ventura 13.4


Feature #8 unit testing

Initial unit tests for key functions.

Implement basic unit tests for key methods.