Data drift volume issues. Any workaround ?

Hello,
I'm currently using Evidently to perform a data drift analysis on my dataset. The dataset has a total shape of (356,251 rows, 797 columns) for both reference and current data.
When I execute the Run() function in Evidently, it seems to run indefinitely. To give you an idea of the issue:
When I analyze 50 columns, it takes approximately 3 minutes.
However, when I increase the number of columns to 100, the process takes about 23 minutes.
I'm wondering if there's a workaround for this situation. One idea I had is to break down the analysis into smaller chunks, perhaps 50 columns at a time, and then merge the results into a single comprehensive report.
Additionally, having a progress bar feature would be extremely helpful to monitor the analysis's progress, especially in cases where it takes a significant amount of time.
Any guidance or suggestions would be greatly appreciated.
Thank you

True when try to do column level metric test, it takes lot of time if you have more columns .
Try :

feature selection
PCA

@YassineR Datadrift test time depends a lot on

which test you're using
type of column (numerical or categorical)
structure of data, and particularly number of unique values for cat. columns

So it's possible that your columns are just different.
To check this you can run test separately for each column and measure the time.


Unable to return Detailed Error FIle after import

Issue: Anaplan Connector throws Null Pointer Exception while returning "Import" response in case the data upload is partially successful
Observations:

When "Import" operation of an Anaplan Connector 1.1.3 is invoked and the data is imported successfully in Anaplan without any errors or warnings, then Anaplan Connector returns response like below:

Sample Success Response:
Import ran successfully:
Date cells: 122
Type cells: 122
Document Number cells: 122
Name cells: 45
Account cells: 122
Memo cells: 113
Amount (LC) cells: 122
Department cells: 122
Subsidiary cells: 122
Account Type cells: 122
RPM ID cells: 17
Employee ID cells: 76
Employee Name cells: 76Import completed successfully: (122 records processed)

When "Import" operation of an Anaplan Connector 1.1.3 is invoked and there is some problem while importing the records, then Anaplan Connector should return valid response with detailed information about which records failed any why, but Anaplan Connector throws Null Pointer Exception. So, it is now hard for us to identify which record failed any why. Please find attached error log for this issue. I have also attached sample csv file generated from code. Please note that for testing purpose generated CSV has invalid Account.

I also tried to upload a sample CSV file (with invalid Account) manually using Anaplan for testing purpose. Please see result screenshots below.
It will be really great if we can get some help to fix Anaplan Connector so that valid error response is returned, then we can use that response for sent email notifications with failed records and reason for failure.

Error_Logs(1).txt

Sample_Incorrect_Data(2).xlsx

Could you also provide the correct Sample Data Xlsx file as well, so that we can recreate the issue? Thanks.

Hi Shuvo,
Please see attached file.
Thanks,
John
Sample_Incorrect_Data(3).xlsx

Hi John,
We have a fix for this issue and we're in the process of QA validation/verification for release with v1.1.4. After that, we will have to complete the re-certification process with Mulesoft to get it released in their marketplace. So, we don't have an exact date for when it will be available there, partly due to their own release timeline and re-certification criteria. But usually it takes a couple of weeks, maybe sooner.
In the meantime, if you wish to test-drive this fix, feel free to checkout the "bug/INTEGRA-915" branch from this repo and then import the connector as a connector project into Anypoint Studio. After that, install the connector from source and you are set to test-drive the fix. Just make sure that the Mule-flow Project points to the newly installed connector and not the pre-installed one (check Configure build path -> Libraries tab). Otherwise, I would recommend to wait until Mulesoft releases it in their market-place.
Thanks,
Spondon.

Thanks Spondon! That's great to hear!
I think we will take a shot at test driving this with the branch that you
added.
John
[image: http://www.twelvecg.com/] http://www.twelvecg.com/
*John Wihtol *| Partner
<EMAIL_ADDRESS>m:<PHONE_NUMBER> <916-215-8668>
skype: john.wihtol | twitter: @johnwihtol https://twitter.com/johnwihtol
website http://www.twelvecg.com/ | twitter https://twitter.com/twelvecg
On Fri, Apr 1, 2016 at 6:52 PM, Shuvo Saha<EMAIL_ADDRESS>wrote:

Hi John,
We have a fix for this issue and we're in the process of QA
validation/verification for release with v1.1.4. After that, we will have
to complete the re-certification process with Mulesoft to get it released
in their marketplace. So, we don't have an exact date for when it will be
available there, partly due to their own release timeline and
re-certification criteria. But usually it takes a couple of weeks, maybe
sooner.
In the meantime, if you wish to test-drive this fix, feel free to checkout
the "bug/INTEGRA-915" branch from this repo and then import the connector
as a connector project into Anypoint Studio. After that, install the
connector from source and you are set to test-drive the fix. Just make sure
that the Mule-flow Project points to the newly installed connector and not
the pre-installed one (check Configure build path -> Libraries tab).
Otherwise, I would recommend to wait until Mulesoft releases it in their
market-place.
Thanks,
Spondon.
—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
https://github.com/anaplaninc/anaplan-mulesoft/issues/62#issuecomment-204625772

Hi John,
Mulesoft just released v1.1.4 of the Mulesoft connector at their marketplace. Please go ahead and update your connector from Anypoint studio to get the latest fixes and updates.
Thanks,
Spondon.

Thanks Spondon, will do!
[image: http://www.twelvecg.com/] http://www.twelvecg.com/
*John Wihtol *| Partner
<EMAIL_ADDRESS>m:<PHONE_NUMBER> <916-215-8668>
skype: john.wihtol | twitter: @johnwihtol https://twitter.com/johnwihtol
website http://www.twelvecg.com/ | twitter https://twitter.com/twelvecg
On Mon, May 2, 2016 at 4:04 PM, Shuvo Saha<EMAIL_ADDRESS>wrote:

Hi John,
Mulesoft just released v1.1.4 of the Mulesoft connector at their
marketplace. Please go ahead and update your connector from Anypoint studio
to get the latest fixes and updates.
Thanks,
Spondon.
—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
https://github.com/anaplaninc/anaplan-mulesoft/issues/62#issuecomment-216390733


nrtcacheck: add option to dump node states

Add an option to just dump the node status (provided by RTE).
Differently from the scheduler, which dumps the status only if the resync fails, the RTEs always do.
Knowing the state of RTEs comes almost for free, and makes troubleshooting easier.

/cherry-pick release-4.13


Test "Jetstream.PullConsumer allows setting custom inbox prefix" (Jetstream.PullConsumer.ConnectivityTest) is wonky

https://github.com/mmmries/jetstream/runs/5688498005?check_suite_focus=true

🤔 Maybe jetstream wasn't full up and running by that time? Or we could try a slightly longer timeout on the assert_receive?

@mmmries possibly
@sswrk could you please take a look at this when you'll have spare cycles? 🙂
This is a low priority issue. So far, we only have encountered this case once.


Finish implementing HmGui

Josh's "hybrid mode" GUI system, called "HmGui" (see his Limit Theory forum post explaining how his HmGui takes the best parts of Immediate and Retained modes: http://forums.ltheory.com/viewtopic.php?f=11&t=5031&p=164057#p164057 ) is mostly done, and mostly works well.
But there are some important elements not implemented, and one large issue remaining:

Text, Button, and Checkbox are implemented, but useful higher-level components such as Textbox and ProgressBar are not implemented.
Slider is only partially implemented: mousewheel can be used to vertically scroll a scrollView, but horizontal and vertical scrollbars are not rendered.
Radio buttons are also not implemented, but can be simulated using Checkbox.
Layout (probably partially due to Immediate mode constraints) works only moderately well, and only as long as you allow it to automatically shrink the outermost containers to the size of their largest internal elements. Trying to pin containers to the edges of a panel that is given a fixed (large) size, such as a game window-sized screen, requires discovering exactly values for SetStretch() and SetAlign(), which must be applied to every single internal component... and this works only for a single screen resolution. Change that, and every component is the wrong size and in the wrong place. HmGui layout mostly works, but needs to be finished so that automatic layout works more easily and consistently across resizing. (See ./script/States/App/TestHmGui-MarketScreen.lua for a current example of the difficulty of getting automatic layout to work well.)

I´d rather replace it with a better solution tbh


Base Envoy implementation

Codecov Report

Merging #125 (b1f2868) into 2020.12.x (fedbbc6) will increase coverage by 1.13%.
The diff coverage is 54.91%.

@@              Coverage Diff              @@
##           2020.12.x     #125      +/-   ##
=============================================
+ Coverage      36.48%   37.61%   +1.13%
=============================================
  Files            386      432      +46
  Lines          37225    39615    +2390
=============================================
+ Hits           13580    14902    +1322
- Misses         21934    22763     +829
- Partials        1711     1950     +239

Impacted Files
Coverage Δ

compose/types/chart.go
80.00% <ø> (ø)

compose/types/module.go
100.00% <ø> (ø)

compose/types/namespace.go
82.60% <ø> (ø)

compose/types/record.go
53.06% <ø> (ø)

pkg/envoy/directory/decode.go
0.00% <0.00%> (ø)

pkg/rbac/rule.go
85.71% <ø> (ø)

pkg/envoy/store/compose_page.go
19.31% <19.31%> (ø)

pkg/envoy/store/user.go
24.39% <24.39%> (ø)

pkg/envoy/store/application.go
29.62% <29.62%> (ø)

pkg/envoy/store/compose_chart.go
29.90% <29.90%> (ø)

... and 94 more

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update fedbbc6...b1f2868. Read the comment docs.


Add installation instructions for Obsidian noobs? 😅

I couldn't figure out how to install this theme and googling around showed me several different instructions but it didn't work.
Would love some step-by-step instructions on the README. 😊

Ahh I'll add those! I still have to update it for the latest version so it might not be coming up in the Community Themes listing, too.

Thank you! I didn't see it within the themes listed in the app, no. So once that is done it is pretty self explanatory. :)


feat: Add organization environment variables

Draft while coordinating multiple PRs

In https://github.com/uselagoon/remote-controller/pull/275 the proposal to add another field to the CRD to support organization variables ties the feature to the release of the remote-controller. I'd prefer to avoid this, and it would be possible to do so.
Since the build-deploy-tool merges everything down into one set of variables that it consumes during the build, it doesn't make a lot of sense to continue doing that and extending CRDs with new fields when we could send the data to the build in a different way. The variable fields in the CRD are just []bytes, which means we're not currently restricted here with what the payload looks like except for what consumes it.
Alternative 1
Do the consolidation on the API side and only send the resulting variables as LAGOON_ENVIRONMENT_VARIABLES (leaving project variables payload empty, essentially deprecating the field, with the side benefit of reducing data sent in the payload in the process). With the possibility of extending the data with a source field that contains where it was sourced from in the event this could be useful in the future (or if there is an existing check in the build-deploy-tool that does care about where it is sourced)
[
	{"name":"ENV_VAR","value":"envvalue","scope": "build","source":"environment"},
	{"name":"PROJ_VAR","value":"projvalue","scope": "build","source":"project"},
	{"name":"ORG_VAR","value":"orgvalue","scope": "build","source":"organization"},
	{"name":"LAGOON_SYSTEM_VAR","value":"sysvalue","scope": "internal_system","source":"internal_system"}
]

This way the merging function in the build-deploy-tool can remain mostly there for backwards compatibility, but would basically be unused.
This would make changes to the build-deploy-tool minimal if it was simply extending variables with the source field. No changes to the remote-controller required (except for maybe a deprecation notice on the project variables field)
Alternative 2
Instead of sending 2 (or 3 in this case) variable payloads for each source type, adjust the way the data is sent to the build from core. Instead of the current []EnvironmentVariable slice for each type in a separate field, use a custom type, or map[string][]EnvironmentVariable. This could make a single payload look something like this:
{
    "environment":[{"name":"ENV_VAR","value":"envvalue","scope": "build"}],
    "project":[{"name":"PROJ_VAR","value":"projvalue","scope": "build"}],
    "organization":[{"name":"ORG_VAR","value":"orgvalue","scope": "build"}],
    "internal_system":[{"name":"LAGOON_SYSTEM_VAR","value":"sysvalue","scope": "internal_system"}]
}

This would then get shipped to the build-deploy-tool as LAGOON_ENVIRONMENT_VARIABLES (again, leaving the project variables empty). All the logic in the build-deploy-tool can still merge variables as required, just the way it would do it would be a bit different with the map. We'd also be able to perform a check in the build to see if the variable payloads received are of the new single payload type, or the older dual payload type. May require a check to allow for backwards compatible processing (ie, if new payload use X merge, if old payloads use Y merge)
This would make changes to the build-deploy-tool still fairly extensive, mostly just modifying what you've already got to instead source from a map. No changes to the remote-controller required either.
My preference would probably be alternative 1, it puts the majority of the changes into core. The variable merging functionality from the build-deploy-tool could even be reproduced in the api-sidecar-handler and benefit from Go tests, and we just call it as required like we do with the ssh key functions (might need some thinking done here, because builds can be triggered by both api and webhooks2tasks. Except webhooks2tasks doesn't have access to this sidecar. The node commons functions would need to know how to communicate with it, meaning the chart would need some adjustments to load the sidecar into the webhooks2tasks service)

Do the consolidation on the API side

We discussed this previously and we ruled it out because we also want support more complicated env vars that can't be calculated at pre-deployment time. I'm specifically thinking of service env vars, but the API can't know what services will exist until the deployment starts and parses the docker-compose.yml. I think it would be better to have it consolidated at the API, so maybe when we get NATS there can be a mid-deployment API request for env vars, that way all the environment info can be provided? I still have lots of open questions around this.

the proposal to add another field to the CRD to support organization variables ties the feature to the release of the remote-controller

I did account for this, so there isn't a hard dependency on a new remote-controller version for the next release, but eventually there would be a need to enforce a minimum version.

adjust the way the data is sent to the build from core...as LAGOON_ENVIRONMENT_VARIABLES (again, leaving the project variables empty)

I have no objections to this, from a technical perspective, to be done instead of changing the CRDs. I have philosophical questions about what the purpose of a CRD and it's version is if we can just change the data as we please. You've done more with those than I, I'll defer to your preference if you think it's a better way forward.

Do the consolidation on the API side

We discussed this previously and we ruled it out because we also want support more complicated env vars that can't be calculated at pre-deployment time. I'm specifically thinking of service env vars, but the API can't know what services will exist until the deployment starts and parses the docker-compose.yml. I think it would be better to have it consolidated at the API, so maybe when we get NATS there can be a mid-deployment API request for env vars, that way all the environment info can be provided? I still have lots of open questions around this.

Those conversations were a while ago now, and I don't remember ruling it out, I do remember we couldn't decide on how it would work which halted the conversation. However, I am fairly positive we can still do most of the consolidation API side with service env vars.
One of the nice things about builds is that they don't have a requirement to request information from the API (ignoring pre/post rollout tasks as these don't influence the build process directly). I'm mostly against a build requesting information from the API mid way, even with NATS, as it has the potential to make testing the build process even more complicated.

the proposal to add another field to the CRD to support organization variables ties the feature to the release of the remote-controller

I did account for this, so there isn't a hard dependency on a new remote-controller version for the next release, but eventually there would be a need to enforce a minimum version.

When I was saying do the consolidation on the API side, this is what I meant. Not modifying the API queries/mutations, or any database tables or how the data is stored in the API. Just doing what the build-deploy-tool is doing with those 2 fields, but only at the point of sending the build payload.

adjust the way the data is sent to the build from core...as LAGOON_ENVIRONMENT_VARIABLES (again, leaving the project variables empty)

I have no objections to this, from a technical perspective, to be done instead of changing the CRDs. I have philosophical questions about what the purpose of a CRD and it's version is if we can just change the data as we please. You've done more with those than I, I'll defer to your preference if you think it's a better way forward.

The data type for these two fields are []byte, there is no structured data. We could consider a move away from them being []byte and into an actual structure, but that could potentially happen when we start to consider a service scoped variable implementation. The fields currently being []byte gives us a bit of freedom to explore options though. As soon as we set a type on these fields, we are locked in and any changes to that type would be extremely painful. Additions are mostly fine, but changing or deleting parts of a type will be much more complicated, something we've been pretty shielded from due to the lack of major changes to the build and task CRDs.
Ignoring the purpose of a CRD though, it is only due to historical reasons that the environment and project variables are split payloads. Maybe in the past consolidating them wasn't even considered and we've just been running with that model because all the old bash required both. The build-deploy-tool only started to consolidate these variables in Go to avoid having to iterate over two sets of variables to compute what exists when they were being consumed like bash did. If I could go back in time, I would have pushed for the API to consolidate the variables sooner and only sent the one set of variables to builds.


[radio] use otDataset APIs instead of otPlatSettings APIs

This PR replaces use of otPlatSettingsSet() in radio_spinel_impl.hpp to equivalent otDatasetSetActive() and otDatasetSetPending(), because otPlatSettings APIs are not mandatory for all platforms while otDataset APIs are provided by openthread itself.

Closed this PR because using otPlatSettings API is essential and otDataset API seems doesn't work.


Connection error: connect EACCES

{"level":"ERROR","timestamp":"2022-07-19T09:52:20.557Z","logger":"kafkajs","message":"[Connection] Connection error: connect EACCES fe80::b03d:38e1:27b3:9e22:9092","broker":"W10-lTkFoL0JX1t.radisys.com:9092","clientId":"ScannerService","stack":"Error: connect EACCES fe80::b03d:38e1:27b3:9e22:9092\n    at  TCPConnectWrap.afterConnect [as oncomplete] (node:net:1187:16)"} {"level":"ERROR","timestamp":"2022-07-19T09:52:20.561Z","logger":"kafkajs","message":"[Connection] Connection error: connect EACCES fe80::b03d:38e1:27b3:9e22:9092","broker":"W10-lTkFoL0JX1t.radisys.com:9092","clientId":"ScannerService","stack":"Error: connect EACCES fe80::b03d:38e1:27b3:9e22:9092\n    at  TCPConnectWrap.afterConnect [as oncomplete] (node:net:1187:16)"}
I am not able to understand what is the issue over here?
I am running kafka on local machine with KAFKA_BROKERS="<IP_ADDRESS>:9092"

Hey @wishygupta if you're running Kafka on a local machine where does 'W10-lTkFoL0JX1t.radisys.com:9092' get set? This should be replaced with your localhost broker e.g <IP_ADDRESS>:9092

@rob3000  I am not sure from where this gets set W10-lTkFoL0JX1t.radisys.com:9092. Since in the JS code I am specifically assigning the localhost <IP_ADDRESS>:9092. Even in the kafka server properties it is not defined. Seems somehow it is triggering that

@wishygupta are you able to paste in your config on how you're defining it?

@rob3000
This is the kafka server properties files
`
broker.id=0
num.network.threads=3
num.io.threads=8
socket.send.buffer.bytes=102400
socket.receive.buffer.bytes=102400
socket.request.max.bytes=104857600
log.dirs=C:/Users/wgupta/Backend/kafka/kafka-logs
num.partitions=1
num.recovery.threads.per.data.dir=1
offsets.topic.replication.factor=1
transaction.state.log.replication.factor=1
transaction.state.log.min.isr=1
log.retention.hours=168
log.segment.bytes=1073741824
log.retention.check.interval.ms=300000
zookeeper.connect=localhost:2181
zookeeper.connection.timeout.ms=18000
group.initial.rebalance.delay.ms=0
`


Add useTranslate() hook

It would be really great to have a hook for getting localization data. And the simplest implementation could look like this:
// @flow
import React, { useContext } from 'react';
import { LocalizeContext, type LocalizeContextProps } from './LocalizeContext';

export function useTranslate(): LocalizeContextProps {
  return useContext(LocalizeContext)
}

I didn't test it yet, but it should work this way:
const MyComponent = () => {
  const { translate } = useTranslate()
  return <div>{translate('key')}</div>
}

@ryandrewjohnson any proposals on this feature?
UPD. I tried to switch from withLocalize to useTranslate in Books page of the demo app but I can't run it because there is no react-localize-redux in dependencies. @ryandrewjohnson how do you handle running the demo? Also, any ideas how to test hook in this case? The only thing we need is to be sure that useTranslate returns our context value.

@dmitrykrylov see the v4.0 Roadmap #140. This captures exactly the functionality you're describing. I started the work, but I've since become busy so had to put it on hold. If you're interested in contributing let me know.

v4.0 Roadmap #140

If you're interested in contributing let me know.

That's why I'm here. I would like to submit a pr, but can't come up with how to do tests or demo for this case

@dmitrykrylov if you want to contribute I recommend that you work off of the branch that was created for v4.0, which is outlined in #140. This hook will only be rolled out as part of a much larger release which includes all the scope items listed in the issue. Any help is appreciated, but if you are going to take on the hooks portion I recommend having a look at the v4  branch I started as reference, as I updated the library to use hooks internally, and wrote tests for them.
I'm going to close this issue in favour of moving conversation over to the #140

I have created a pretty simple hook for that.
import { useContext } from 'react';
import { LocalizeContext } from 'react-localize-redux';

const useTranslate = () => {

const context = useContext(LocalizeContext);
const { translate } = context;

if (!context) {
    throw new Error('useTranslate must be used within a LocalizeProvider')
}

return translate
};

export default useTranslate;

Use it like this.
 const translation = useTranslate();

<Text>{translation('key')}</Text>


Entity is unavailable

Hi,
on October 30th at around noon entity stopped working. I tried many restart but it keeps staying unavailable.
Can you help ?
Thanks

Send logo from HA.

Hello same i have. Everyting work good and after HA update just stopped. below is the logs:
Logger: homeassistant.components.sensor
Source: helpers/entity_platform.py:359
Integration: Sensor (documentation, issues)
First occurred: 08:39:10 (1 occurrences)
Last logged: 08:39:10
Error while setting up hoymiles_dtu platform for sensor
Traceback (most recent call last):
File "/usr/src/homeassistant/homeassistant/helpers/entity_platform.py", line 359, in _async_setup_platform
await asyncio.shield(task)
File "/usr/local/lib/python3.11/concurrent/futures/thread.py", line 58, in run
result = self.fn(*self.args, **self.kwargs)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/config/custom_components/hoymiles_dtu/sensor.py", line 76, in setup_platform
dev.append(HoymilesPVSensor(name, updater.data.microinverter_data[i-1].serial_number, i, updater.data.microinverter_data[i-1].port_number, variable, updater))
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^^^^^
IndexError: list index out of range

Have you restarted HA?


Error when calling get_top_fans() on artist object

I got an error when calling the get_top_fans() method on an artist object - everything else still works fine, just this error in this method.
The error message is in the attached screenshot.

Thanks for the report. Last.fm broke their API six weeks ago and there's still lots of broken things; artist.getTopFans amongst them. For example, I get errors from their example URLs here: http://www.last.fm/api/show/artist.search
<lfm status="failed">
  <error code="3">Invalid Method - No method with that name in this package</error>
</lfm>

I've reported this to Last.fm:
https://getsatisfaction.com/lastfm/topics/api-known-issues?topic-reply-list[settings][filter_by]=all&topic-reply-list[settings][reply_id]=16176464#reply_16176464
(If pylast can be made more robust to handle errors better, PRs are welcome, but it shouldn't break Libre.fm support. But the error it's gicing sounds about right for the current Last.fm server-side problems.)

It's been long enough and Last.fm still haven't fixed it, so this will be removed in the next pylast release.


(B4) Register as baker on node dashboard

confirmed:B4
address:3RjAbm3ihwGwW4k4NdjqLfx5xpaTkvFEWMBDZFneMNTniqxc7R
baker:277

confirmed:B4
address:3RjAbm3ihwGwW4k4NdjqLfx5xpaTkvFEWMBDZFneMNTniqxc7R
baker:277


interface is not working

interface is not working by default settings

how to enable interface by customized setting?

Fixed in 4.01 version


Wording suggestions

Hi Linus, just doing the full skill acceptance review and had some suggested wording changes. These are only suggestions though, it is of course up to you.

Thanks!


add codecov

same as #22
closes #12

Gonna hop back on this now that we are open-sourced.

closed in favour of #115


update dependencies to later version

Use new versions for clickhouse and prometheus that support features for Openshift

Can you please test the upgrade process? Specifically, install the chart before the changes and then upgrade.

Use new versions for clickhouse and prometheus that support features for Openshift

The install works (I just pushed an update that prevents unnecessary components from starting)
The upgrade does not work. There are multiple issues like this where backwards compatibility is not possible.


[BUG]: LM studio listed ads an embedding providers but it does not show up

How are you running AnythingLLM?
AnythingLLM desktop app
What happened?
LM Studio is listed as am embedding provider here in the doc (https://docs.useanything.com/features/embedding-models#supported-embedding-model-providers) but there is no such option in the AnythingLLM desktop app. In the app, only the other 4 providers are supported.

Are there known steps to reproduce?
No response

scroll down
https://github.com/user-attachments/assets/65eeae58-6b30-4a41-82ce-84bad6972ade


delete_old_custom_formats not removing CFs after removing includes from conf

Observed Behavior
recyclarr did not remove any CFs it added despite delete_old_custom_formats: true and the relevant section of the conf being removed.
Expected Behavior
recyclarr would remove the CFs it added, and i'd be left with only the one original CF that i had added manually.
Steps To Reproduce

start with a radarr instance with a single CF (manually created in radarr). SQP-5 QP does not exist yet.

run recyclarr sync radarr with:

radarr:
  radarr_hq:
    base_url: !secret radarr_hq_url
    api_key: !secret radarr_hq_key
    quality_definition:
      type: sqp-uhd
    delete_old_custom_formats: true
    include:
      - template: radarr-custom-formats-sqp-5
      - template: radarr-quality-profile-sqp-5

output:
[INF] Created 80 New Custom Formats
[INF] Total of 80 custom formats were synced
[INF] Created 1 Profiles: ["SQP-5"]
[INF] A total of 1 profiles were synced. 1 contain quality changes and 1 contain updated scores
[INF] Processing Quality Definition: sqp-uhd
[INF] Number of updated qualities: 0
[INF] Completed at 04/18/2024 21:38:03

debug log:
recyclarr_2024-04-18_21-38-00.debug.log

run recyclarr sync radarr again with:

radarr:
  radarr_hq:
    base_url: !secret radarr_hq_url
    api_key: !secret radarr_hq_key
    quality_definition:
      type: sqp-uhd
    delete_old_custom_formats: true

output:
[INF] Processing Quality Definition: sqp-uhd
[INF] Number of updated qualities: 0
[INF] Completed at 04/18/2024 21:39:26

debug log:
recyclarr_2024-04-18_21-39-25.debug.log
Environment & Versions
- Operating System: fedora server fc39
- Architecture: x64
- Recyclarr Version: 6.0.2+Branch.tags-v6.0.2.Sha.5b163d9dc621f28624270e2543334d8ee8599d98
- Recyclarr Build: docker
- Radarr Version: <IP_ADDRESS>23

Are you able to consistently reproduce this? If you add the include back, sync, remove, do another sync -- do you see those CFs appear but not disappear?

yes ofc lol :)
reproduced once more to be sure:
docker compose run --rm recyclarr delete custom-formats radarr_hq --all

docker compose run --rm recyclarr sync radarr -i radarr_hq
# result: CFs were added by includes

# after editing conf to remove includes:
docker compose run --rm recyclarr sync radarr -i radarr_hq
result: CFs are still there

complete config used just now
before:
# yaml-language-server: $schema=https://raw.githubusercontent.com/recyclarr/recyclarr/master/schemas/config-schema.json

radarr:
  radarr_hq:
    base_url: !secret radarr_hq_url
    api_key: !secret radarr_hq_key
    delete_old_custom_formats: true
    include:
      - template: radarr-custom-formats-sqp-5
      - template: radarr-quality-profile-sqp-5

after:
# yaml-language-server: $schema=https://raw.githubusercontent.com/recyclarr/recyclarr/master/schemas/config-schema.json

radarr:
  radarr_hq:
    base_url: !secret radarr_hq_url
    api_key: !secret radarr_hq_key
    delete_old_custom_formats: true
    # include:
    #   - template: radarr-custom-formats-sqp-5
    #   - template: radarr-quality-profile-sqp-5

hi again :)
have you had a chance to try reproducing or having a look?

I have not. Keep in mind this project is a volunteer effort. I spend my free time here. I appreciate your bug report and will get to it when I have time :-)


When Total=0 and Miss=0 I would expect the result to be SUCCESS rather than FAILED

Environment
python 3.7
interrogate 1.3.1
Description of the bug
When nothing is missed but the coverage is 0 because there was nothing to document, I would expect the result to be SUCCESS.

Summary -
| Name  | Total | Miss | Cover | Cover% |
|-------|-------|------|-------|--------|
|-------|-------|------|-------|--------|
| TOTAL |     0 |    0 |     0 |   0.0% |
RESULT: FAILED (minimum: 60.0%, actual: 0.0%) -

What you expected to happen
I would expect the result to be successful
How to reproduce (as minimally and precisely as possible)
Create a module that do not contain any methods or properties. (In my case it was a module only defining type aliases.
Use this configuration:
[tool.interrogate]
ignore-init-method = true
ignore-init-module = true
ignore-magic = true
ignore-semiprivate = true
ignore-private = true
ignore-property-decorators = true
ignore-module = true
ignore-nested-functions = true
fail-under = 60
exclude = ["setup.py", "docs", "build", "test"]
verbose = 1
quiet = false
whitelist-regex = []
color = true

FYI the fix has been released in 1.3.2 - thanks!


MODCLUSTER-806 Change the mod_proxy_cluster license to ASL 2.0

Resolves
https://issues.redhat.com/browse/MODCLUSTER-806
Goals:

Update the main repo licence at root - that gets picked up by GitHub UI
Update headers on source files + build scripts
Keep tests as they are now

[ERROR] Failed to execute goal on project mod_cluster_test: Could not resolve dependencies for project org.jboss.mod_cluster:mod_cluster_test:pom:2.0.4.Final-SNAPSHOT: The following artifacts could not be resolved: org.jboss.mod_cluster:mod_cluster-container-spi:jar:2.0.4.Final-SNAPSHOT, org.jboss.mod_cluster:mod_cluster-core:jar:2.0.4.Final-SNAPSHOT, org.jboss.mod_cluster:mod_cluster-container-tomcat-8.5:jar:2.0.4.Final-SNAPSHOT, org.jboss.mod_cluster:mod_cluster-load-spi:jar:2.0.4.Final-SNAPSHOT: Could not find artifact org.jboss.mod_cluster:mod_cluster-container-spi:jar:2.0.4.Final-SNAPSHOT -> [Help 1]
Our scripts rely on a version set to be the same as in main mod_cluster branch... we should rely on released versions unless necessary otherwise.

@jajik Since you already have experience with reviewing these - please have a look to make sure I didn't miss something. Thanks!
BTW This time I found it more readable to do an empty space after the licence header.

[ERROR] Failed to execute goal on project mod_cluster_test: Could not resolve dependencies for project org.jboss.mod_cluster:mod_cluster_test:pom:2.0.4.Final-SNAPSHOT: The following artifacts could not be resolved: org.jboss.mod_cluster:mod_cluster-container-spi:jar:2.0.4.Final-SNAPSHOT, org.jboss.mod_cluster:mod_cluster-core:jar:2.0.4.Final-SNAPSHOT, org.jboss.mod_cluster:mod_cluster-container-tomcat-8.5:jar:2.0.4.Final-SNAPSHOT, org.jboss.mod_cluster:mod_cluster-load-spi:jar:2.0.4.Final-SNAPSHOT: Could not find artifact org.jboss.mod_cluster:mod_cluster-container-spi:jar:2.0.4.Final-SNAPSHOT -> [Help 1]
Our scripts rely on a version set to be the same as in main mod_cluster branch... we should eventualy rely on released versions unless necessary otherwise.

A PR is already opened https://github.com/modcluster/mod_proxy_cluster/pull/174
I agree that we should rely on the released ones in the future. I plan to do it with some other changes regarding a better handling of the tests dependencies.


kitchen-sink unit tests failing

Hi, I'm seeing some test failures when running npm test in the kitchen-sink example directory.
I've added these dependencies to make the project run:
  "dependencies": {
    "@nestjs-plus/common": "^1.1.0",
    "@nestjs-plus/rabbitmq": "^1.4.1",

Test results:
 PASS  src/app.controller.spec.ts
 PASS  src/rabbit-example/messaging/messaging.service.spec.ts (5.057s)
 FAIL  src/rabbit-example/messaging/messaging.controller.spec.ts (5.084s)
  ● Messaging Controller › should be defined

    Nest can't resolve dependencies of the MessagingController (?). Please make sure that the argument AmqpConnection at index [0] is available in the _RootTestModule context.

    Potential solutions:
    - If AmqpConnection is a provider, is it part of the current _RootTestModule?
    - If AmqpConnection is exported from a separate @Module, is that module imported within _RootTestModule?
      @Module({
        imports: [ /* the Module containing AmqpConnection */ ]
      })

      at Injector.lookupComponentInExports (../node_modules/@nestjs/core/injector/injector.js:183:19)

  ● Messaging Controller › should be defined

    expect(received).toBeDefined()

    Received: undefined

      14 |
      15 |   it('should be defined', () => {
    > 16 |     expect(controller).toBeDefined();
         |                        ^
      17 |   });
      18 | });
      19 |

      at Object.it (rabbit-example/messaging/messaging.controller.spec.ts:16:24)

Test Suites: 1 failed, 2 passed, 3 total
Tests:       1 failed, 2 passed, 3 total
Snapshots:   0 total
Time:        5.505s
Ran all test suites.

Let me know how if there's a way to fix the tests?
Thanks,
Patrick

@patrickandroid I've fixed this. In general I've not put an effort into keeping the tests in the KitchenSink up to date as they're just the default scaffolded ones that come with a new Nest app. The actual tests (both unit and integration) which are run in Travis are all kept alongside the actual library code

Thanks


Roll engine ae024d755518..be6313d87545 (1 commits)

https://github.com/flutter/engine/compare/ae024d755518...be6313d87545
git log ae024d755518019f3618931fbc47d3f27e84fad5..be6313d87545874a6108edb2a311f30d9a027472 --no-merges --oneline
be6313d87 Roll src/third_party/skia 2fdbeae32785..83edfbe736fd (1 commits) (flutter/engine#8390)
The AutoRoll server is located here: https://autoroll.skia.org/r/flutter-engine-flutter-autoroll
Documentation for the AutoRoller is here:
https://skia.googlesource.com/buildbot/+/master/autoroll/README.md
If the roll is causing failures, please contact the current sheriff (bmparr@google.com), and stop
the roller if necessary.

Auto-roller completed checks. About to merge.


Bad LENGTH (check_syntax) - On Select-Option

Issue:
./src/ecc/#jcs#bc_se16n_batch.prog.abap[51, 1]                             - Bad LENGTH (check_syntax)
Source:

It looks like some of the typing of KABA00 is missing?
anyhow I'll add a fallback

try again, 2.39.26 published

issue resolved. Thanks.


multiple "Cc:" headers

Emails generated by gitgitgadget may contain multiple Cc: headers. For example:
Message-Id<EMAIL_ADDRESS>In-Reply-To<EMAIL_ADDRESS>References<EMAIL_ADDRESS>From: Johannes Schindelin via GitGitGadget<EMAIL_ADDRESS>Date: Fri, 9 Mar 2018 17:36:47 +0100
Subject: [PATCH 3/3] rebase --rebase-merges: adjust man page for octopus support
...
To<EMAIL_ADDRESS>Cc: Junio C Hamano<EMAIL_ADDRESS>Cc: Johannes Schindelin<EMAIL_ADDRESS>Sender<EMAIL_ADDRESS>List-ID: <git.vger.kernel.org>
X-Mailing-List<EMAIL_ADDRESS>
According to RFC 5322 § 3.6, only a single Cc: header is allowed.
Moreover, multiple Cc: headers may cause delivery problems. For instance, anti-spam software may reject such email:
X-Amavis-Alert: BAD HEADER SECTION Duplicate header field: "Cc"

Emails generated by gitgitgadget may contain multiple Cc: headers

I guess the code responsible for this is https://github.com/gitgitgadget/gitgitgadget/blob/c4805370f59532aa438283431b8ea7d4484c530f/lib/patch-series.ts#L271
Care to suggest how to fix this properly? (IIRC there are some sort of length limitations on Cc: lines, too, and they are not necessarily comma separated, continuations are usually indicated by the next line starting with a space, right?)

@sunshineco I could really use your help here, as I am rather swamped with other stuff...

I think you're correct about line length limit, commas, and continuation lines, based upon my reading of that RFC.
Is that ccMatch working correctly? Perhaps I'm misunderstanding the code, but it looks like it shouldn't be invoking the header += "\nCc: " + authorMatch[2]; line at all if a Cc: header is already present. It should simply be augmenting the existing Cc: header. In the email excerpt above, I'm guessing that Cc: junio was already present, and then Cc: dscho was added, having come from the From: header, so it doesn't make sense that it added a new Cc: header rather than merely augmenting the existing one (unless ccMatch isn't working or I'm misunderstanding the intent).
Regarding augmenting the Cc: header, rather than inserting authorMatch[2] on the same line as the existing Cc: and having to worry about line length, can you instead just append a comma to the existing Cc: line and then place authorMatch[2] indented on the next line?

Is that ccMatch working correctly?

No. The thing is, the Cc: line is the last line of the header here, and it does not end in a newline (that is cut off from header, on purpose).

Regarding augmenting the Cc: header, rather than inserting authorMatch[2] on the same line as the existing Cc: and having to worry about line length, can you instead just append a comma to the existing Cc: line and then place authorMatch[2] indented on the next line?

I think that this is not a completely correct solution, as it would still be possible to overrun the maximum line length (998 octets, according to https://tools.ietf.org/html/rfc2822#section-2.1.1).
But it should be good enough in our case.

I think that this is not a completely correct solution, as it would still be possible to overrun the maximum line length

True. The extra comma could exceed the limit. If I'm reading RFC 5322 § 2.2.3 correctly, I think that it would be legal to fold the line at the whitespace immediately following Cc:, which would be a simple way to avoid exceeding the limit without worrying about parsing email addresses.
That is, something like (pseudo-code):
if (existing "Cc:" header)
    if (len(header) < 998)
        ...as before...
    else
        header = "Cc:\n  " + header.strip_prefix("Cc:") + ",\n" + extra_cc
else
    ...as before...

Otherwise, you'd probably have to parse the email addresses to figure out where to split the line. Perhaps something like email-addresses.js would be useful there if the simpler proposal above is not valid.

Does the closed status of this issue indicate that the fix is now in production, or is there some window between the time the fix is accepted/merged before it goes into production?
I ask because I'm still seeing duplicate Cc: lines. For instance:
X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "Cc"
Date:   Wed, 18 Jul 2018 08:15:35 -0700 (PDT)
Message-Id<EMAIL_ADDRESS>In-Reply-To<EMAIL_ADDRESS>References<EMAIL_ADDRESS>From:   "Stefan Beller via GitGitGadget"<EMAIL_ADDRESS>Subject: [PATCH 1/8] refs.c: migrate internal ref iteration to pass thru
 repository argument
To<EMAIL_ADDRESS>Cc<EMAIL_ADDRESS>Junio C Hamano<EMAIL_ADDRESS>Cc:     Stefan Beller<EMAIL_ADDRESS>Sender<EMAIL_ADDRESS>List-ID: <git.vger.kernel.org>
X-Mailing-List<EMAIL_ADDRESS>

The fix is supposed to be in production. As soon as master is updated, it gets deployed to the web app.
So no, it should have worked.
Let's see whether it happens again in the next patch series.


2170_KQL_urlParse_port

Changelog category (leave one):

Bug Fix (user-visible misbehavior in official stable or prestable release)

Changelog entry (a user-readable short description of the changes that goes to CHANGELOG.md):

[parse_url() may not return the correct hostname and port when a username:password@ is present]

Information about CI checks: https://clickhouse.com/docs/en/development/continuous-integration/

It was a mistake from attempting to pull the style yaml fix but 189 is already merged into Kusto phase 3.

It was a mistake from attempting to pull the style yaml fix but 189 is already merged into Kusto phase 3.

189 was merged, you can remove them from this PR.

@mcmajam since this PR impacts ClickHouse core functionality significantly, it'd be preferable to submit as much of it to the main repo (https://github.com/ClickHouse/ClickHouse) as possible. You can save your changes specific to the KQL layer in a branch and come back to it once the core changes are merged.

Close this. Completely re-written in new pull request.
https://github.com/ClibMouse/ClickHouse/pull/272


Release 0.7.4

[x] write release notes
[x] bump version in meson.build to an even minor release number
[x] bump SIMDE_VERSION_{MAJOR,MINOR,MICRO} in simde/simde-common.h to match
[x] make release candidate (make sure to mark it as a "pre-release" in GitHub)
[ ] test on Debian against all official and unofficial architectures using all available gcc and clang versions
[x] Rebuild all packages in Debian that use SIMDe in experimental to see if there are any regressions.
[x] fix or ignore any errors found
[x] make another release candidate (repeating the above as necessary)
[ ] make final release
[ ] upload an amalgamated build of the headers
[ ] create a matching tag for the simde-no-tests repo
[ ] blog post
[ ] email the mailing list
[ ] ping vcpkg to update, example
[ ] post-release: bump version in meson.build to an odd minor release number
[ ] post-release: bump SIMDE_VERSION_{MAJOR,MINOR,MICRO} in simde/simde-common.h to match
[ ] copy this checklist to the wiki for next time

@wrv  I spoke too soon; still getting some errors on i386 for x86/avx512/dbsad (which I might just skip) and ppc64el (which seem more serious)

 267/1534 x86/avx512/range/native/cpp             ERROR           0.03s   exit status 1
 269/1534 x86/avx512/range/native/c               ERROR           0.09s   exit status 1
 271/1534 x86/avx512/range_round/native/c         ERROR           0.05s   exit status 1
 273/1534 x86/avx512/range_round/native/cpp       ERROR           0.05s   exit status 1
 436/1534 x86/sse/native/c                        ERROR           0.06s   exit status 1
 438/1534 x86/sse/native/cpp                      ERROR           0.06s   exit status 1
 440/1534 x86/sse2/native/c                       ERROR           0.07s   exit status 1
 442/1534 x86/sse2/native/cpp                     ERROR           0.07s   exit status 1
1364/1534 wasm_simd128/mul/native/c               ERROR           0.03s   exit status 1
1366/1534 wasm_simd128/mul/native/cpp             ERROR           0.03s   exit status 1
1424/1534 wasm_simd128/shr/native/c               ERROR           0.04s   exit status 1
1426/1534 wasm_simd128/shr/native/cpp             ERROR           0.04s   exit status 1

https://ci.debian.net/data/autopkgtest/testing/ppc64el/s/simde/30980831/log.gz
(i386 log is here, but a much lower priority https://ci.debian.net/data/autopkgtest/testing/i386/s/simde/30980676/log.gz )

Well, even for ppc64el, I'm not super concerned as all the test builds did finally succeed
https://buildd.debian.org/status/package.php?p=examl%2Clast-align%2Cminimap2%2Cpbcopper%2Chisat2%2Cfermi-lite%2Cbowtie2%2Cbwa%2Ckalign%2Cfasta3%2Cplink2%2Cmmseqs2%2Cspoa%2Ckmc%2Chhsuite%2Cabpoa%2Crna-star%2Cparasail%2Cngmlr%2Cseqan-raptor%2Cscrappie&suite=experimental&a=ppc64el


Removing jobs based on webpage?

Would there be any interest in some tests that check the url specified to make sure that the job titles still exist there? I started writing some tests like that here
https://github.com/diamond29/opportunities/commit/8f0880a88f61ce1501d457c14dd61a3e1606c79f
I noticed a few places where job listings were taken down, but I was wondering if you were interested in this functionality before I continued further.

I think it's interesting... possible stop gap until we get scrappers in play... however lately I've been leaning toward removing the job titles since I haven't found a good way to keep them updated...

could you elaborate on what you mean by scrappers? I'm not familiar.
My intention was to write these tests so that they'd run nightly with something like
http://nightli.es/
then if it started failing you could manually remove them. Just a tool to help you maintain the list.

Ha just looked at this again and realized you meant scrapers. Yeah what I wrote is just a scraper that validates the job titles.
I'm not a scraper expert but I would think that finding new job titles on sites would be a very difficult problem?


Create a webnative github org for examples

As discussed, we should make a separate org.

Pretty sure this happened :)

Link: https://github.com/webnative-examples


az deployment group what-if - Not returning the error details

$output = az deployment group what-if --resource-group {} --name {} --template-file {} --parameters {} - While running this command, we are able to capture the success and changes. But, unable to capture the error details in an object.
We are facing many challenges to find the cause for the issue in controlled environment

@zhoxing-ms for awareness

@shenglol Could you please help take a look at the what-if related issue?

@kalirajann Can you elaborate on this? On error cases What-If is expected to return error details since that's part of the contract: https://github.com/Azure/azure-rest-api-specs/blob/81cd88a080c4bf4bb251afbe62892a6e220cb2b4/specification/resources/resource-manager/Microsoft.Resources/stable/2021-04-01/resources.json#L6353.

$output = az deployment group what-if --resource-group {} --name {} --template-file {} --parameters {} - While running this command, we are able to capture the success and changes. But, unable to capture the error details in an object and always sets null.
$output is powershell object.


DD2:Crash after official frame generation update

Describe the bug
After CAPCOM updated Dragon's Dogma 2 and provided official frame generation on 31st May, the game starts crashing if I open frame generation in the setting menu. It seems that the new update is not compatible with REFramewok.
Upload logs and any crash dumps
re2_framework_log.txt
reframework_crash.dmp
Identify the REFramework version
I use the newest version(Nightly 939),and also try old versions. The problem always exists.
To Reproduce
Steps to reproduce the behavior:
One situation:

Download the game on Steam
Install dinput8.dll
Play the game normally
Open official frame generation
The game crashes with out CrashReport

Another situation:
1.Uninstall REFramework
2.Launch the game and open frame generation with out crashing
3.Install REFramework
4.Crash on RE engine start up screen
Expected behavior
I wish this problem will be fixed as soon as possible.
Screenshots
If applicable, add screenshots to help explain your problem.
Desktop and VR (please complete the following information):

OS : Windows 11
Graphics card: NVIDIA GeForce RTX 4070 LAPTOP
CPU: I7-14700HX

To be precise, in my case it crashes when I try to enable official FG option and then save the settings (until saving settings, there is no crash).

To be precise, in my case it crashes when I try to enable official FG option and then save the settings (until saving settings, there is no crash).

Thanks for your supplement. Actually my problem is the same as yours T_T

I'm having the exact same issue. RTX 4080 if that matters.
reframework_crash.dmp
re2_framework_log.txt

Fixed


Pass through clean certificates in Handshake

https://github.com/square/okhttp/issues/5138
Pass through clean certificates with only a single pass of cert cleaning.
TODO add test

@swankjesse Any advice for testing here?  We test RealConnection through CallTest, and the JVM code around KeyManager will likely send the clean certificates.

This situation is frustrating.
Cleaning the certificates could be non-trivial, so this has the potential of breaking or slowing code that works otherwise.
I’d like to land 4.1 without this, and then put this in 4.2 early with lots of bake time.

That said, the change itself looks great!
As for testing . . . wanna test with a fake cleaner?

That said, the change itself looks great!
As for testing . . . wanna test with a fake cleaner?

That route isn't great.  It makes new internal APIs for setting the cleaner in OkHttpClient.Builder.  Cleaner currently comes from the Platform, or via the TrustManager if you customise that.  But they are on a public API, so they tend to show up for Java clients.

@swankjesse I'm tempted to move this into sslSocketSession.handshake()
But also wondering whether we should retain the uncleaned certificates?  Handshake could have both, potentially interesting when trying to understand why a decision was made.  e.g. if certificates are served that have multiple root CAs for different clients.  Not sure if that happens in the wild.

We can hide things from Java clients with a - prefix on the @JvmName. Does that help? (We should probably do this universally!)

Can we always use the cleaner from the pinner? What’s the benefit of wiring it through the connection? If that one is null we shouldn’t bother.
I’m still unsatisfied with the performance cost here. It has a non-zero cost and a nearly-zero benefit.

Can we always use the cleaner from the pinner? What’s the benefit of wiring it through the connection? If that one is null we shouldn’t bother.
I’m still unsatisfied with the performance cost here. It has a non-zero cost and a nearly-zero benefit.

There is only one pass of cleaning, is it the additional copy of Handshake you are concerned about? It used to happen at CertificatePinner.kt, line 146.
The benefit is that callers can rely on the handshake certificates being those that we trust and validate.  If we choose to expose the handshake certificates (public API), I'd argue that we should provide the correct ones.

Now deferring cleaning until we either

need to check certificate pinning
caller looks at the peer certificates

But only done at most once.

n.b. I removed the test because the change otherwise becomes awkward with OkHttpClient, since that constructor generally always fetches a new cleaner from Platform :(

I think this is a very nice improvement.


[BEAM-12069] Make mock a test-only dependency

mock version pinned to 2.0.0 is breaking our tests (tensorflow-cloud) when we introduce tensorflow-transform as a dependency (which depends on apache beam).
Thank you for your contribution! Follow this checklist to help us incorporate your contribution quickly and easily:

[ ] Choose reviewer(s) and mention them in a comment (R: @username).
[ ] Format the pull request title like [BEAM-XXX] Fixes bug in ApproximateQuantiles, where you replace BEAM-XXX with the appropriate JIRA issue, if applicable. This will automatically link the pull request to the issue.
[ ] Update CHANGES.md with noteworthy changes.
[ ] If this contribution is large, please file an Apache Individual Contributor License Agreement.

See the Contributor Guide for more tips on how to make review process smoother.

GitHub Actions Tests Status (on master branch)

See CI.md for more information about GitHub Actions CI.

R: @TheNeuralBit

@TheNeuralBit Could you merge it? Thanks!

Run PythonLint PreCommit

@ TheNeuralBig  I registered an id (yinghsienwu) on apache jira.

You should probably also remove mock from this file:
https://github.com/apache/beam/blob/master/sdks/python/container/base_image_requirements.txt

Put up https://github.com/apache/beam/pull/14389 for base_image_requirements


Group Admins

Thanks for submitting a PR! Please check the boxes below:

[x] I have run pre-commit to check linting
[x] I have filled in the "Changes" section below?
[x] I have filled in the "How did you test this code" section below?

Changes

Migrate GET,Delete groups to TypeScript
Add a delete group admin / make group admin endpoint
Allow all users to see the manage groups page (org admins will see the standard manage org page instead)

How did you test this code?

@kyle-ssg a few things I've noticed:

It doesn't seem to work going from Group Admin -> User. I can't see that it ever makes a request to .../remove-admin? (see screen recording attached)
The UI is quite confusing. I think perhaps the best step would be to only show the users here that are already members of the group. Then we can show a separate form to add new users or something. I appreciate that's perhaps a larger chunk of work but could we perhaps tidy up what we have a little bit? Feels to me like the admin status should be a checkbox rather than a drop down since it can only take a value of on or off.

https://user-images.githubusercontent.com/14089968/230393561-a1c3c2f2-2f53-48eb-aaa5-82e0550b2b5d.mov

RE remove admin, this is now sorted.
Have adjusted the UI of this, the initial consideration was like organisation users where perhaps in future there could be other roles but yeah this seems unlikely.

I'm not seeing the admin switcher?

@matthewelwell, this was due to the group_admins flag being disabled in production - I've adjusted the PR to also hide the "Admin" heading in this case.
It can be tested against the staging deployment above or by enabling the group_admins flag.

@kyle-ssg this looks better, and the removal works now. The new 'Add user' workflow is slightly confusing though as you need to add them and then hit 'Update Group' but there's no indication that you need to do that. Could we add an indication that users haven't been added until they hit 'Update Group'?

@novakzaballa can't approve as it's my PR but latest changes look good from a code perspective 👍

@novakzaballa sorry - just found one more bug on the frontend. The interstitial modal also displays when you successfully update the group.
https://user-images.githubusercontent.com/14089968/233934166-84a3d941-074f-4a5d-98c3-0d76e7b6087c.mov

@novakzaballa sorry - just found one more bug on the frontend. The interstitial modal also displays when you successfully update the group.
Screen.Recording.2023-04-24.at.08.54.48.mov

@matthewelwell thanks for testing it. Corrected


direction ltr

Hello,
does jspdf support direction:ltr ?
For example:
i have this code,
doc.text('123', 0, 0);
This will output '123' from left to right. If i change i to '1234' it will keep adding the text to the end and it will expand to the right side.
But what if i want it to go from right to left, so it will use the rightside as an anchorpoint and keep expanding to the left side but it will still stay 1234.
i hope you'll understand what i mean. I can make screenshots if needed.

Thank you for the comment.
Sadly this doesn't work and my js will output the following error:
jspdf.min.js:29 Uncaught Error: Invalid arguments passed to jsPDF.text
at Object.l.private.text.l.text (jspdf.min.js:29)
at HTMLAnchorElement. (main.js:550)
at HTMLAnchorElement.dispatch (jquery.min.js:2)
at HTMLAnchorElement.y.handle (jquery.min.js:2)
Line 550 in main.js has "doc.text({text: '123', x:50, y:50, align: 'right'});"

jspdf by default ltr. I suppose you are searching for align
doc.text({text: '123', x:50, y:50, align: 'right'});
?

Thank you for the comment.
Sadly this doesn't work and my js will output the following error:
jspdf.min.js:29 Uncaught Error: Invalid arguments passed to jsPDF.text
at Object.l.private.text.l.text (jspdf.min.js:29)
at HTMLAnchorElement. (main.js:550)
at HTMLAnchorElement.dispatch (jquery.min.js:2)
at HTMLAnchorElement.y.handle (jquery.min.js:2)
Line 550 in main.js has "doc.text({text: '123', x:50, y:50, align: 'right'});"

doc.text('123', 50, 50, {align: 'right'});

doc.text('123', 50, 50, {align: 'right'});

Exactly what i needed ! Thank you for the fast response !


Ignore c_compiler and cxx_compiler variants on Windows

xref: https://github.com/conda/conda-build/issues/3017

Checklist

[ ] Used a fork of the feedstock to propose changes
[x] Bumped the build number (if the version is unchanged)
[ ] Reset the build number to 0 (if the version changed)
[x] Re-rendered with the latest conda-smithy
[x] Ensured the license file is being packaged.

Hi! This is the friendly automated conda-forge-linting service.
I just wanted to let you know that I linted all conda-recipes in your PR (recipe) and found it was in an excellent condition.

@conda-forge-admin, please re-render

@nehaljwani, it looks like you committed directly to the go-feedstock repository instead of your own fork

closing this in favor of #26 because the branch was created in the go-feedstock repository itself as opposed to a fork.


bug:  Align buttons "Apply as a Mentor" and "Check our Mentors"

Bug Report
Describe the bug
Currently buttons on the Mentorship, About page are not aligned. Also they are too close to the footer.
To Reproduce
Steps to reproduce the behavior:

Go to Mentorship, About page
Scroll to the bottom of the page

Expected behavior
Buttons aligned
More space between the bottom of the page and the footer
Screenshots

Desktop (please complete the following information):

OS: Windows 10
Browser: Chrome
Version:

Reproducibility

[x ] The bug is reproducible consistently.
[ ] The bug is sporadic or occurs randomly.

Impact

[ ] The bug affects critical functionality.
[ ] The bug affects minor functionality.
[x ] The bug is a cosmetic issue.

Assign @nverbic


Kotlin Project exposing dependency via extension functions in testFixtures claims dependency unused

Reproducing project
https://github.com/Nava2/dependency-analysis-gradle-plugin-testfixtures-failure
Build scan link
https://scans.gradle.com/s/qu6lenwhzmwce
Plugin version
1.20.0, 1.21.0
Gradle version
7.5
reason output for bugs relating to incorrect advice
Library is used.
 $ ./gradlew reason --id "org.assertj:assertj-core:3.24.0"            [19:33:18]

> Task :reason

----------------------------------------
You asked about the dependency 'org.assertj:assertj-core:3.24.0'.
You have been advised to remove this dependency from 'testFixturesApi'.
----------------------------------------

There is no path from root project to org.assertj:assertj-core:3.24.0 for compileClasspath

There is no path from root project to org.assertj:assertj-core:3.24.0 for runtimeClasspath

Shortest path from root project to org.assertj:assertj-core:3.24.0 for testCompileClasspath:
:
\--- org.assertj:assertj-core:3.24.0

Shortest path from root project to org.assertj:assertj-core:3.24.0 for testRuntimeClasspath:
:
\--- org.assertj:assertj-core:3.24.0

Source: main
------------
(no usages)

Source: test
------------
(no usages)

BUILD SUCCESSFUL in 2s
31 actionable tasks: 1 executed, 30 up-to-date

Describe the bug
testFixturesApi is recommended to be removed, but is used.
To Reproduce
Steps to reproduce the behavior:

Run ./gradlew projectHealth in project https://github.com/Nava2/dependency-analysis-gradle-plugin-testfixtures-failure

Expected behavior
Not deemed unused

Confirmed still an issue on 1.21.0

Thanks for the report.

@Nava2 you gave me a reproducer, which puts you in the top 1% of people submitting issues, which is why I added this issue to the next milestone. You're good! Thanks for asking though.
If you're feeling spunky you could try to write a test case, but most people find those challenging because writing Gradle tests is not very straightforward. If that interests you, I could provide some pointers.

I cannot reproduce this with the latest version, 1.24.0. Going to close, but feel free to reopen if you see it again.


Intel GPU (PVC) support on Linux

Hi @Anjok07, Does UVR support Intel GPUs on Linux and especially do you support Intel PVC yet?

Since UVR uses Pytorch and this seems to be nailed to CUDA at the moment, only GPUs that have CUDA and are supported by the Pytorch library will work. AMD have dropped the approach to fully support CUDA meanwhile. Intel never tried to implement CUDA, they have their DPCPP and SYCL interfaces.
TL;DR: No luck with Intel GPUs and UVR, neither on Windows, MacOS or Linux - sorry!

@ChrisTG742 Thanks for your update. would it be possible for you to share sample test instructions via cli and point me to source that support CUDA/AMD this will help me in my exploration.


USA - 2022 Kia K5 GT - Heated/vented seats setting not functional/not sent

Region/vehicle/version information

USA
2022 Kia K5 GT (GT1 package)
Kia Uvo / Hyundai Bluelink integration via HACS, v2.14.0
Home Assistant 2023.8.3

HA Supervisor 2023.08.3
HA Operating System 10.5
HA Frontend 20230802.1 - latest

Description
kia_uvo.start_climate doesn't trigger the heated/cooled seats for my K5, regardless of setting. Dumping the request when activating from the Kia Connect webpage's interface, I get this (url decoded and pretty printed after):
https://owners.kia.com/apps/services/owners/remotevehicledata?requestJson={%22action%22:%22ACTION_EXEC_REMOTE_CLIMATE_ON%22,%22remoteClimate%22:{%22airTemp%22:{%22value%22:%2276%22,%22unit%22:1},%22airCtrl%22:true,%22defrost%22:true,%22ventilationWarning%22:false,%22ignitionOnDuration%22:{%22value%22:%2210%22,%22unit%22:4},%22heatingAccessory%22:{%22steeringWheel%22:1,%22steeringWheelStep%22:%22undefined%22,%22sideMirror%22:1,%22rearWindow%22:1},%22heatVentSeat%22:{%22driverSeat%22:{%22heatVentType%22:1,%22heatVentLevel%22:3,%22heatVentStep%22:2},%22passengerSeat%22:{%22heatVentType%22:1,%22heatVentLevel%22:4,%22heatVentStep%22:1},%22rearLeftSeat%22:{%22heatVentType%22:0,%22heatVentLevel%22:1,%22heatVentStep%22:0},%22rearRightSeat%22:{%22heatVentType%22:0,%22heatVentLevel%22:1,%22heatVentStep%22:0}}}}
{
  "action": "ACTION_EXEC_REMOTE_CLIMATE_ON",
  "remoteClimate": {
    "airTemp": {
      "value": "LOW",
      "unit": 1
    },
    "airCtrl": true,
    "defrost": false,
    "ventilationWarning": false,
    "ignitionOnDuration": {
      "value": "10",
      "unit": 4
    },
    "heatingAccessory": {
      "steeringWheel": 0,
      "steeringWheelStep": "undefined",
      "sideMirror": 0,
      "rearWindow": 0
    },
    "heatVentSeat": {
      "driverSeat": {
        "heatVentType": 2,
        "heatVentLevel": 2,
        "heatVentStep": 3
      },
      "passengerSeat": {
        "heatVentType": 2,
        "heatVentLevel": 3,
        "heatVentStep": 2
      },
      "rearLeftSeat": {
        "heatVentType": 0,
        "heatVentLevel": 1,
        "heatVentStep": 0
      },
      "rearRightSeat": {
        "heatVentType": 0,
        "heatVentLevel": 1,
        "heatVentStep": 0
      }
    }
  }
}

Looks like the values the Kia Connect webpage sends for these seats are:

High vent/cool: {"heatVentType": 2,"heatVentLevel": 4, "heatVentStep": 1}
Med vent/cool: {"heatVentType": 2,"heatVentLevel": 3, "heatVentStep": 2}
Low vent/cool: {"heatVentType": 2,"heatVentLevel": 2, "heatVentStep": 3}
-Off: {"heatVentType": 0,"heatVentLevel": 1, "heatVentStep": 0}
Low heat: {"heatVentType": 1,"heatVentLevel": 2, "heatVentStep": 3}
Med heat: {"heatVentType": 1,"heatVentLevel": 3, "heatVentStep": 2}
High heat: {"heatVentType": 1,"heatVentLevel": 4, "heatVentStep": 1}

And the webpage's request does include the rear seats despite the seats not having any related features and the UI on the webpage not giving any controls to set for them. The settings for temperatures, time, defrost, steering wheel, mirrors, and rear window heaters all appear to trigger as expected from the integration's service.
Regardless of whether I select only the driver, both the driver and passenger seats, or all of them including the rear seats set to "off" (which would match the way the query is sent by the kia connect web interface), the start_climate log entry appears to leave out the seat settings altogether:
2023-09-07 17:30:31.455 DEBUG (SyncWorker_6) [hyundai_kia_connect_api.KiaUvoAPIUSA] hyundai_kia_connect_api - Planned start_climate payload: {'remoteClimate': {'airCtrl': True, 'airTemp': {'unit': 1, 'value': '62'}, 'defrost': False, 'heatingAccessory': {'rearWindow': 0, 'sideMirror': 0, 'steeringWheel': 0}, 'ignitionOnDuration': {'unit': 4, 'value': 10}}}
I'm happy to poke whatever I need to for testing or the like to help out, but haven't tried diving into the code myself yet. If you need any of the vehicleInfoList I can clean that up and pass it along as well.
Thank you!

The mobile app traffic will need to be sniffed and this payload corrected in the code.   Unfortunately no regular USA devs today so happy to receive help and PRs.

Even with latest update, the heated seats in my USA K5 are always off after using climate_start

To confirm it works in your native app?

Yes it does.  I see the same request url as OP
https://owners.kia.com/apps/services/owners/remotevehicledata?requestJson={%22action%22:%22ACTION_EXEC_REMOTE_CLIMATE_ON%22,%22remoteClimate%22:{%22airTemp%22:{%22value%22:%2274%22,%22unit%22:1},%22airCtrl%22:true,%22defrost%22:false,%22ventilationWarning%22:false,%22ignitionOnDuration%22:{%22value%22:10,%22unit%22:4},%22heatingAccessory%22:{%22steeringWheel%22:1,%22steeringWheelStep%22:null,%22sideMirror%22:0,%22rearWindow%22:0},%22heatVentSeat%22:{%22driverSeat%22:{%22heatVentType%22:1,%22heatVentLevel%22:4,%22heatVentStep%22:1},%22passengerSeat%22:{%22heatVentType%22:0,%22heatVentLevel%22:1,%22heatVentStep%22:0},%22rearLeftSeat%22:{%22heatVentType%22:0,%22heatVentLevel%22:1,%22heatVentStep%22:0},%22rearRightSeat%22:{%22heatVentType%22:0,%22heatVentLevel%22:1,%22heatVentStep%22:0}}}}
This is with only the driver seat set at high heat and the rest set to off.

To confirm the above is a sniff from the native app?  If so how does it compare to this integration? What yaml are you sending?

Looking at the source of the connect api, it looks like vent step is hard coded to "1".  Also seats with no setting default to 0 and then subtract 4 so I would suppose -4 is being sent in the actual request

It's from the Kia Connect website in the chrome browser

To confirm the above is a sniff from the native app? If so how does it compare to this integration? What yaml are you sending?

service: kia_uvo.start_climate
data:
  duration: 10
  climate: true
  temperature: 74
  heating: '1'
  device_id: cf054bd276f7e10643c99f56b5984ef8
  flseat: '8'
  frseat: '0'
  rlseat: '0'
  rrseat: '0'
  defrost: false

I also tried using
service: kia_uvo.start_climate data:   duration: 10   climate: true   temperature: 74   heating: '1'   device_id: cf054bd276f7e10643c99f56b5984ef8   flseat: '8'   frseat: '4'   rlseat: '4'   rrseat: '4'   defrost: false

What are the debug logs showing for the payload?

I just started using HACS and Home Assistant a few hours ago.  Where do I find the debug logs?

Looking at the source of the connect api, it looks like vent step is hard coded to "1". Also seats with no setting default to 0 and then subtract 4 so I would suppose -4 is being sent in the actual request

Where would they subtract 4?  That -4 is within an if statement so only applies on 6,7,8.
As for debug logs you will need to enable them.   If you go to the bottom of the readme on this repo it shows how to do that.     After that it will be in settings>system>logs>scroll to bottom and click full logs.

Where would they subtract 4? That -4 is within an if statement so only applies on 6,7,8.

Oh right, duh
Here's the error log
Logger: hyundai_kia_connect_api.KiaUvoAPIUSA
Source: /usr/local/lib/python3.11/site-packages/hyundai_kia_connect_api/KiaUvoAPIUSA.py:85
First occurred: 1:26:17 PM (1 occurrences)
Last logged: 1:26:17 PM

hyundai_kia_connect_api - Error: unknown error response {"status":{"statusCode":1,"errorType":1,"errorCode":9001,"errorMessage":"Incorrect request payload format"}}

Where would they subtract 4? That -4 is within an if statement so only applies on 6,7,8.

Oh right, duh
Here's the error log
Logger: hyundai_kia_connect_api.KiaUvoAPIUSA
Source: /usr/local/lib/python3.11/site-packages/hyundai_kia_connect_api/KiaUvoAPIUSA.py:85
First occurred: 1:26:17 PM (1 occurrences)
Last logged: 1:26:17 PM

hyundai_kia_connect_api - Error: unknown error response {"status":{"statusCode":1,"errorType":1,"errorCode":9001,"errorMessage":"Incorrect request payload format"}}

Sorry, that's a different error that I get when setting Steering wheel heating.  I'm able to bypass that error by setting the heating option to 1 manually
Hold on and I'll grab the most recent log

Make sure debug logs are enabled.  That looks to just be the regular error logs.

023-12-28 12:53:15.854 WARNING (SyncWorker_3) [homeassistant.loader] We found a custom integration kia_uvo which has not been tested by Home Assistant. This component might cause stability problems, be sure to disable it if you experience issues with Home Assistant
2023-12-28 12:53:15.854 WARNING (SyncWorker_3) [homeassistant.loader] We found a custom integration ha_kia_hyundai which has not been tested by Home Assistant. This component might cause stability problems, be sure to disable it if you experience issues with Home Assistant
2023-12-28 12:53:15.854 WARNING (SyncWorker_3) [homeassistant.loader] We found a custom integration hacs which has not been tested by Home Assistant. This component might cause stability problems, be sure to disable it if you experience issues with Home Assistant
2023-12-28 12:56:40.474 ERROR (MainThread) [homeassistant.config_entries] Error unloading entry My K5 (K5) for ha_kia_hyundai
Traceback (most recent call last):
File "/usr/src/homeassistant/homeassistant/config_entries.py", line 557, in async_unload
result = await component.async_unload_entry(hass, self)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/config/custom_components/ha_kia_hyundai/__init__.py", line 286, in async_unload_entry
config_update_listener()
TypeError: 'NoneType' object is not callable
2023-12-28 12:57:12.941 WARNING (SyncWorker_5) [homeassistant.loader] We found a custom integration kia_uvo which has not been tested by Home Assistant. This component might cause stability problems, be sure to disable it if you experience issues with Home Assistant
2023-12-28 12:57:12.941 WARNING (SyncWorker_5) [homeassistant.loader] We found a custom integration hacs which has not been tested by Home Assistant. This component might cause stability problems, be sure to disable it if you experience issues with Home Assistant
2023-12-28 13:26:17.895 ERROR (SyncWorker_11) [hyundai_kia_connect_api.KiaUvoAPIUSA] hyundai_kia_connect_api - Error: unknown error response {"status":{"statusCode":1,"errorType":1,"errorCode":9001,"errorMessage":"Incorrect request payload format"}}
2023-12-28 13:26:17.896 ERROR (MainThread) [homeassistant.components.script.warm_up] Warm Up: Error executing script. Unexpected error for call_service at pos 1:
Traceback (most recent call last):
File "/usr/src/homeassistant/homeassistant/helpers/script.py", line 468, in _async_step
await getattr(self, handler)()
File "/usr/src/homeassistant/homeassistant/helpers/script.py", line 704, in _async_call_service_step
response_data = await self._async_run_long_action(
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/src/homeassistant/homeassistant/helpers/script.py", line 666, in _async_run_long_action
return long_task.result()
^^^^^^^^^^^^^^^^^^
File "/usr/src/homeassistant/homeassistant/core.py", line 2067, in async_call
response_data = await coro
^^^^^^^^^^
File "/usr/src/homeassistant/homeassistant/core.py", line 2104, in _execute_service
return await target(service_call)
^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/config/custom_components/kia_uvo/services.py", line 70, in async_handle_start_climate
await coordinator.async_start_climate(vehicle_id, climate_request_options)
File "/config/custom_components/kia_uvo/coordinator.py", line 198, in async_start_climate
await self.hass.async_add_executor_job(
File "/usr/local/lib/python3.11/concurrent/futures/thread.py", line 58, in run
result = self.fn(*self.args, **self.kwargs)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/local/lib/python3.11/site-packages/hyundai_kia_connect_api/VehicleManager.py", line 134, in start_climate
return self.api.start_climate(self.token, self.get_vehicle(vehicle_id), options)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/local/lib/python3.11/site-packages/hyundai_kia_connect_api/KiaUvoAPIUSA.py", line 720, in start_climate
response = self.post_request_with_logging_and_active_session(
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/local/lib/python3.11/site-packages/hyundai_kia_connect_api/KiaUvoAPIUSA.py", line 41, in request_with_active_session_wrapper
return func(*args, **kwargs)
^^^^^^^^^^^^^^^^^^^^^
File "/usr/local/lib/python3.11/site-packages/hyundai_kia_connect_api/KiaUvoAPIUSA.py", line 86, in request_with_logging_wrapper
raise RequestException
requests.exceptions.RequestException
2023-12-28 13:26:17.897 ERROR (MainThread) [homeassistant.components.websocket_api.http.connection] [139985800237888]
Traceback (most recent call last):
File "/usr/src/homeassistant/homeassistant/components/websocket_api/commands.py", line 238, in handle_call_service
response = await hass.services.async_call(
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/src/homeassistant/homeassistant/core.py", line 2067, in async_call
response_data = await coro
^^^^^^^^^^
File "/usr/src/homeassistant/homeassistant/core.py", line 2104, in _execute_service
return await target(service_call)
^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/src/homeassistant/homeassistant/components/script/__init__.py", line 605, in _service_handler
response = await self._async_start_run(
^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/src/homeassistant/homeassistant/components/script/__init__.py", line 563, in _async_start_run
script_result = await coro
^^^^^^^^^^
File "/usr/src/homeassistant/homeassistant/components/script/__init__.py", line 594, in _async_run
return await self.script.async_run(script_vars, context)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/src/homeassistant/homeassistant/helpers/script.py", line 1578, in async_run
return await asyncio.shield(run.async_run())
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/src/homeassistant/homeassistant/helpers/script.py", line 420, in async_run
await self._async_step(log_exceptions=False)
File "/usr/src/homeassistant/homeassistant/helpers/script.py", line 470, in _async_step
self._handle_exception(
File "/usr/src/homeassistant/homeassistant/helpers/script.py", line 493, in _handle_exception
raise exception
File "/usr/src/homeassistant/homeassistant/helpers/script.py", line 468, in _async_step
await getattr(self, handler)()
File "/usr/src/homeassistant/homeassistant/helpers/script.py", line 704, in _async_call_service_step
response_data = await self._async_run_long_action(
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/src/homeassistant/homeassistant/helpers/script.py", line 666, in _async_run_long_action
return long_task.result()
^^^^^^^^^^^^^^^^^^
File "/usr/src/homeassistant/homeassistant/core.py", line 2067, in async_call
response_data = await coro
^^^^^^^^^^
File "/usr/src/homeassistant/homeassistant/core.py", line 2104, in _execute_service
return await target(service_call)
^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/config/custom_components/kia_uvo/services.py", line 70, in async_handle_start_climate
await coordinator.async_start_climate(vehicle_id, climate_request_options)
File "/config/custom_components/kia_uvo/coordinator.py", line 198, in async_start_climate
await self.hass.async_add_executor_job(
File "/usr/local/lib/python3.11/concurrent/futures/thread.py", line 58, in run
result = self.fn(*self.args, **self.kwargs)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/local/lib/python3.11/site-packages/hyundai_kia_connect_api/VehicleManager.py", line 134, in start_climate
return self.api.start_climate(self.token, self.get_vehicle(vehicle_id), options)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/local/lib/python3.11/site-packages/hyundai_kia_connect_api/KiaUvoAPIUSA.py", line 720, in start_climate
response = self.post_request_with_logging_and_active_session(
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/local/lib/python3.11/site-packages/hyundai_kia_connect_api/KiaUvoAPIUSA.py", line 41, in request_with_active_session_wrapper
return func(*args, **kwargs)
^^^^^^^^^^^^^^^^^^^^^
File "/usr/local/lib/python3.11/site-packages/hyundai_kia_connect_api/KiaUvoAPIUSA.py", line 86, in request_with_logging_wrapper
raise RequestException
requests.exceptions.RequestException
2023-12-28 13:27:38.280 DEBUG (MainThread) [custom_components.kia_uvo.coordinator] Finished fetching kia_uvo data in 0.779 seconds (success: True)
2023-12-28 13:57:41.060 DEBUG (MainThread) [custom_components.kia_uvo.coordinator] Finished fetching kia_uvo data in 3.159 seconds (success: True)
2023-12-28 14:04:56.798 DEBUG (MainThread) [custom_components.kia_uvo.coordinator] Finished fetching kia_uvo data in 0.820 seconds (success: True)
2023-12-28 14:28:14.971 DEBUG (MainThread) [custom_components.kia_uvo.coordinator] Finished fetching kia_uvo data in 0.934 seconds (success: True)

The difference I see is that KIA Connect website sends "heatVentStep": 0 for seats that are off and the api sends 1
I think VentStep should be 3 for low, 2 med, 1 for high, and 0 for off

You aren't running this integration. You are running another one that supports KiaUSA.   You can open issues for that integration here: https://github.com/dahlb/ha_kia_hyundai

"custom_components.kia_uvo.coordinator" isn't part of this integration?  I did try that other integration which explains why you see it in the log, but I removed it because it's lacking most of the options available in this one.

Oops I saw ha_kia_hyundai.
Looks like you don't have debug logging enabled.  Please edit your config yaml to enable that. It is outlined at the bottom of the readme on this page.  Restart HA and you should have much more detail in the logs. Including the planned payload for this.

Sorry about that.  I think this is right
2023-12-28 14:50:38.701 WARNING (SyncWorker_4) [homeassistant.loader] We found a custom integration kia_uvo which has not been tested by Home Assistant. This component might cause stability problems, be sure to disable it if you experience issues with Home Assistant
2023-12-28 14:50:38.701 WARNING (SyncWorker_4) [homeassistant.loader] We found a custom integration hacs which has not been tested by Home Assistant. This component might cause stability problems, be sure to disable it if you experience issues with Home Assistant
2023-12-28 14:50:40.928 DEBUG (SyncWorker_3) [hyundai_kia_connect_api.KiaUvoAPIUSA] hyundai_kia_connect_api - Sign In Response {"status":{"statusCode":0,"errorType":0,"errorCode":0,"errorMessage":"Success with response body"}}
2023-12-28 14:50:40.928 DEBUG (SyncWorker_3) [hyundai_kia_connect_api.KiaUvoAPIUSA] got session id f32e4dc0-3c63-4aee-837e-4b747b77870e
2023-12-28 14:50:41.952 DEBUG (SyncWorker_3) [hyundai_kia_connect_api.KiaUvoAPIUSA] hyundai_kia_connect_api - Get Vehicles Response {"status":{"statusCode":0,"errorType":0,"errorCode":0,"errorMessage":"Success with response body"},"payload":{"vehicleSummary":[{"vin":"5XXG34J25PG185846","vehicleIdentifier":"185846","modelName":"K5","modelYear":"2023","nickName":"My K5","generation":2,"extColorCode":"ERG","trim":"EX","imagePath":{"imageName":"2023-k5-ex-erg.png","imagePath":"/content/dam/kia/us/owners/image/vehicle-app/2023/k5/ex/","imageType":"1","imageSize":{"length":"100","width":"100","uom":0}},"enrollmentStatus":1,"fatcAvailable":0,"telematicsUnit":1,"fuelType":1,"colorName":"EVERLASTING SILVER","activationType":2,"mileage":"11140","dealerCode":"GA055","mobileStore":[{"osType":0,"downloadURL":"https://itunes.apple.com/us/app/kia-access-with-uvo-link/id1280548773?mt=8","image":{"imageName":"iosImage.png","imagePath":"/content/dam/kia/us/owners/image/common/app/","imageType":"2","imageSize":{"length":"100","width":"100","uom":0}}},{"osType":1,"downloadURL":"https://play.google.com/store/apps/details?id=com.myuvo.link","image":{"imageName":"androidImage.png","imagePath":"/content/dam/kia/us/owners/image/common/app/","imageType":"2","imageSize":{"length":"100","width":"100","uom":0}}}],"supportedApp":{"appType":"5","appImage":{"imageName":"uvo-app.png","imagePath":"/content/dam/kia/us/owners/image/common/app/access/","imageType":"2","imageSize":{"length":"100","width":"100","uom":0}}},"licensePlate":"","psi":"","supportAdditionalDriver":1,"customerType":0,"projectCode":"DL3","headUnitDesc":"AVN5.0W","provStatus":"4","enrollmentSuppressionType":0,"rsaStatus":0,"dsEnrollment":0,"ubiEnrollment":0,"notificationCount":0,"genType":"2","vehicleKey":"d97ba5d3-0930-46c5-9677-ee602da60235"}],"chatbotSupport":true}}
2023-12-28 14:50:41.953 DEBUG (SyncWorker_3) [hyundai_kia_connect_api.KiaUvoAPIUSA] hyundai_kia_connect_api - sending https://api.owners.kia.com/apigw/v1/cmm/gvi request with {'vehicleConfigReq': {'airTempRange': '0', 'maintenance': '1', 'seatHeatCoolOption': '0', 'vehicle': '1', 'vehicleFeature': '0'}, 'vehicleInfoReq': {'drivingActivty': '0', 'dtc': '1', 'enrollment': '1', 'functionalCards': '0', 'location': '1', 'vehicleStatus': '1', 'weather': '0'}, 'vinKey': ['d97ba5d3-0930-46c5-9677-ee602da60235']}
2023-12-28 14:50:42.758 DEBUG (SyncWorker_3) [hyundai_kia_connect_api.KiaUvoAPIUSA] hyundai_kia_connect_api got response {"status":{"statusCode":0,"errorType":0,"errorCode":0,"errorMessage":"Success with response body"},"payload":{"vehicleInfoList":[{"vinKey":"d97ba5d3-0930-46c5-9677-ee602da60235","vehicleConfig":{"vehicleDetail":{"vehicle":{"vin":"5XXG34J25PG185846","trim":{"modelYear":"2023","salesModelCode":"L4262","optionGroupCode":"017","modelName":"K5","factoryCode":"EX","projectCode":"DL3","trimName":"EX","driveType":"0","transmissionType":"1","ivrCategory":"5"},"telematics":1,"mileage":"11140","mileageSyncDate":"20231228043809","exteriorColor":"EVERLASTING SILVER","exteriorColorCode":"ERG","fuelType":1,"invDealerCode":"SC033","testVehicle":"0","supportedApps":[{"appType":"0"},{"appType":"5","appImage":{"imageName":"uvo-app.png","imagePath":"/content/dam/kia/us/owners/image/common/app/access/","imageType":"2","imageSize":{"length":"100","width":"100","uom":0}}}],"activationType":2},"images":[{"imageName":"2023-k5-ex-erg.png","imagePath":"/content/dam/kia/us/owners/image/vehicle-app/2023/k5/ex/","imageType":"1","imageSize":{"length":"100","width":"100","uom":0}}],"device":{"launchType":"0","swVersion":"DL322.USA.S5W_M.V008.001.220504","telematics":{"generation":"3","platform":"1","tmsCenter":"1","billing":true,"genType":"2"},"versionNum":"GASOLINE","headUnitType":"0","hdRadio":"X40HAF","ampType":"NA","headUnitName":"avn5w","bluetoothRef":"20","headUnitDesc":"AVN5.0W"}},"maintenance":{"nextServiceMile":4859.9004,"maintenanceSchedule":[8000,16000,24000,32000,40000,48000,56000,64000,72000,80000,88000,96000,104000]},"billingPeriod":{"freeTrial":{"value":12,"unit":0},"freeTrialExtension":{"value":12,"unit":1},"servicePeriod":{"value":60,"unit":1}}},"lastVehicleInfo":{"vehicleNickName":"My K5","preferredDealer":"GA055","licensePlate":"","psi":"","customerType":0,"enrollment":{"provStatus":"4","enrollmentStatus":"1","enrollmentType":"0","registrationDate":"20221113","expirationDate":"20231113","expirationMileage":"100000","freeServiceDate":{"startDate":"20221113","endDate":"20231113"}},"activeDTC":{"dtcActiveCount":"0"},"vehicleStatusRpt":{"statusType":"2","reportDate":{"utc":"20231228195042","offset":-8},"vehicleStatus":{"climate":{"airCtrl":false,"defrost":false,"airTemp":{"value":"72","unit":1},"heatingAccessory":{"steeringWheel":0,"sideMirror":0,"rearWindow":0},"heatVentSeat":{"driverSeat":{"heatVentType":0,"heatVentLevel":1},"passengerSeat":{"heatVentType":0,"heatVentLevel":1},"rearLeftSeat":{"heatVentType":0,"heatVentLevel":1},"rearRightSeat":{"heatVentType":0,"heatVentLevel":1}}},"engine":false,"doorLock":true,"doorStatus":{"frontLeft":0,"frontRight":0,"backLeft":0,"backRight":0,"trunk":0,"hood":0},"lowFuelLight":false,"ign3":false,"transCond":true,"distanceToEmpty":{"value":39,"unit":3},"tirePressure":{"all":0},"dateTime":{"utc":"20231228195042","offset":-8},"syncDate":{"utc":"20231228193809","offset":-8},"batteryStatus":{"stateOfCharge":61,"deliveryMode":1,"warning":65,"powerAutoCutMode":2},"sleepMode":false,"lampWireStatus":{"headLamp":{"headLampStatus":false,"lampLL":false,"lampRL":false,"lampLH":false,"lampRH":false,"lampLB":false,"lampRB":false},"stopLamp":{"leftLamp":false,"rightLamp":false},"turnSignalLamp":{"lampLF":false,"lampRF":false,"lampLR":false,"lampRR":false}},"windowStatus":{"windowFL":0,"windowFR":0,"windowRL":0,"windowRR":0},"smartKeyBatteryWarning":false,"fuelLevel":8,"washerFluidStatus":true,"brakeOilStatus":false,"engineOilStatus":false,"engineRuntime":{},"remoteControlAvailable":1,"valetParkingMode":0,"rsaStatus":0}},"location":{"coord":{"lat":32.010025,"lon":-82.0637027778,"alt":43,"type":0,"altdo":0},"head":322,"speed":{"value":0,"unit":1},"accuracy":{"hdop":8,"pdop":13},"syncDate":{"utc":"20231228193809","offset":-8}},"financed":true,"financeRegistered":false,"linkStatus":0,"rsaStatus":0}}]}}
2023-12-28 14:50:42.759 DEBUG (SyncWorker_3) [hyundai_kia_connect_api.KiaUvoAPIUSA] hyundai_kia_connect_api - last_updated_at - before<PHONE_NUMBER>3809
2023-12-28 14:50:42.759 DEBUG (SyncWorker_3) [hyundai_kia_connect_api.KiaUvoAPIUSA] hyundai_kia_connect_api - last_updated_at - after 2023-12-28 19:38:09+00:00
2023-12-28 14:50:42.759 DEBUG (SyncWorker_3) [hyundai_kia_connect_api.KiaUvoAPIUSA] hyundai_kia_connect_api - SOC Levels couldn't be found. May not be an EV.
2023-12-28 14:50:42.759 DEBUG (SyncWorker_3) [hyundai_kia_connect_api.KiaUvoAPIUSA] hyundai_kia_connect_api - last_updated_at - before<PHONE_NUMBER>3809
2023-12-28 14:50:42.759 DEBUG (SyncWorker_3) [hyundai_kia_connect_api.KiaUvoAPIUSA] hyundai_kia_connect_api - last_updated_at - after 2023-12-28 19:38:09+00:00
2023-12-28 14:50:42.759 DEBUG (MainThread) [custom_components.kia_uvo.coordinator] Finished fetching kia_uvo data in 2.666 seconds (success: True)
2023-12-28 14:51:33.243 DEBUG (SyncWorker_0) [hyundai_kia_connect_api.KiaUvoAPIUSA] hyundai_kia_connect_api - Planned start_climate payload: {'remoteClimate': {'airCtrl': True, 'airTemp': {'unit': 1, 'value': '74'}, 'defrost': False, 'heatingAccessory': {'rearWindow': 1, 'sideMirror': 1, 'steeringWheel': 1}, 'ignitionOnDuration': {'unit': 4, 'value': 10}, 'heatVentSeat': {'driverSeat': {'heatVentType': 0, 'heatVentLevel': 0, 'heatVentStep': 1}, 'passengerSeat': {'heatVentType': 0, 'heatVentLevel': 0, 'heatVentStep': 1}, 'rearLeftSeat': {'heatVentType': 0, 'heatVentLevel': 0, 'heatVentStep': 1}, 'rearRightSeat': {'heatVentType': 0, 'heatVentLevel': 0, 'heatVentStep': 1}}}}
2023-12-28 14:51:33.243 DEBUG (SyncWorker_0) [hyundai_kia_connect_api.KiaUvoAPIUSA] hyundai_kia_connect_api - sending https://api.owners.kia.com/apigw/v1/rems/start request with {'remoteClimate': {'airCtrl': True, 'airTemp': {'unit': 1, 'value': '74'}, 'defrost': False, 'heatingAccessory': {'rearWindow': 1, 'sideMirror': 1, 'steeringWheel': 1}, 'ignitionOnDuration': {'unit': 4, 'value': 10}, 'heatVentSeat': {'driverSeat': {'heatVentType': 0, 'heatVentLevel': 0, 'heatVentStep': 1}, 'passengerSeat': {'heatVentType': 0, 'heatVentLevel': 0, 'heatVentStep': 1}, 'rearLeftSeat': {'heatVentType': 0, 'heatVentLevel': 0, 'heatVentStep': 1}, 'rearRightSeat': {'heatVentType': 0, 'heatVentLevel': 0, 'heatVentStep': 1}}}}
2023-12-28 14:51:34.198 DEBUG (SyncWorker_0) [hyundai_kia_connect_api.KiaUvoAPIUSA] hyundai_kia_connect_api got response {"status":{"statusCode":0,"errorType":0,"errorCode":0,"errorMessage":"Success with response body"}}
2023-12-28 14:51:34.199 DEBUG (SyncWorker_4) [hyundai_kia_connect_api.VehicleManager] hyundai_kia_connect_api - Time differential in seconds: 805.19924
2023-12-28 14:51:34.199 DEBUG (SyncWorker_4) [hyundai_kia_connect_api.KiaUvoAPIUSA] hyundai_kia_connect_api - sending https://api.owners.kia.com/apigw/v1/cmm/gvi request with {'vehicleConfigReq': {'airTempRange': '0', 'maintenance': '1', 'seatHeatCoolOption': '0', 'vehicle': '1', 'vehicleFeature': '0'}, 'vehicleInfoReq': {'drivingActivty': '0', 'dtc': '1', 'enrollment': '1', 'functionalCards': '0', 'location': '1', 'vehicleStatus': '1', 'weather': '0'}, 'vinKey': ['d97ba5d3-0930-46c5-9677-ee602da60235']}
2023-12-28 14:51:35.067 DEBUG (SyncWorker_4) [hyundai_kia_connect_api.KiaUvoAPIUSA] hyundai_kia_connect_api got response {"status":{"statusCode":0,"errorType":0,"errorCode":0,"errorMessage":"Success with response body"},"payload":{"vehicleInfoList":[{"vinKey":"d97ba5d3-0930-46c5-9677-ee602da60235","vehicleConfig":{"vehicleDetail":{"vehicle":{"vin":"5XXG34J25PG185846","trim":{"modelYear":"2023","salesModelCode":"L4262","optionGroupCode":"017","modelName":"K5","factoryCode":"EX","projectCode":"DL3","trimName":"EX","driveType":"0","transmissionType":"1","ivrCategory":"5"},"telematics":1,"mileage":"11140","mileageSyncDate":"20231228043809","exteriorColor":"EVERLASTING SILVER","exteriorColorCode":"ERG","fuelType":1,"invDealerCode":"SC033","testVehicle":"0","supportedApps":[{"appType":"0"},{"appType":"5","appImage":{"imageName":"uvo-app.png","imagePath":"/content/dam/kia/us/owners/image/common/app/access/","imageType":"2","imageSize":{"length":"100","width":"100","uom":0}}}],"activationType":2},"images":[{"imageName":"2023-k5-ex-erg.png","imagePath":"/content/dam/kia/us/owners/image/vehicle-app/2023/k5/ex/","imageType":"1","imageSize":{"length":"100","width":"100","uom":0}}],"device":{"launchType":"0","swVersion":"DL322.USA.S5W_M.V008.001.220504","telematics":{"generation":"3","platform":"1","tmsCenter":"1","billing":true,"genType":"2"},"versionNum":"GASOLINE","headUnitType":"0","hdRadio":"X40HAF","ampType":"NA","headUnitName":"avn5w","bluetoothRef":"20","headUnitDesc":"AVN5.0W"}},"maintenance":{"nextServiceMile":4859.9004,"maintenanceSchedule":[8000,16000,24000,32000,40000,48000,56000,64000,72000,80000,88000,96000,104000]},"billingPeriod":{"freeTrial":{"value":12,"unit":0},"freeTrialExtension":{"value":12,"unit":1},"servicePeriod":{"value":60,"unit":1}}},"lastVehicleInfo":{"vehicleNickName":"My K5","preferredDealer":"GA055","licensePlate":"","psi":"","customerType":0,"enrollment":{"provStatus":"4","enrollmentStatus":"1","enrollmentType":"0","registrationDate":"20221113","expirationDate":"20231113","expirationMileage":"100000","freeServiceDate":{"startDate":"20221113","endDate":"20231113"}},"activeDTC":{"dtcActiveCount":"0"},"vehicleStatusRpt":{"statusType":"2","reportDate":{"utc":"20231228195134","offset":-8},"vehicleStatus":{"climate":{"airCtrl":false,"defrost":false,"airTemp":{"value":"72","unit":1},"heatingAccessory":{"steeringWheel":0,"sideMirror":0,"rearWindow":0},"heatVentSeat":{"driverSeat":{"heatVentType":0,"heatVentLevel":1},"passengerSeat":{"heatVentType":0,"heatVentLevel":1},"rearLeftSeat":{"heatVentType":0,"heatVentLevel":1},"rearRightSeat":{"heatVentType":0,"heatVentLevel":1}}},"engine":false,"doorLock":true,"doorStatus":{"frontLeft":0,"frontRight":0,"backLeft":0,"backRight":0,"trunk":0,"hood":0},"lowFuelLight":false,"ign3":false,"transCond":true,"distanceToEmpty":{"value":39,"unit":3},"tirePressure":{"all":0},"dateTime":{"utc":"20231228195134","offset":-8},"syncDate":{"utc":"20231228193809","offset":-8},"batteryStatus":{"stateOfCharge":61,"deliveryMode":1,"warning":65,"powerAutoCutMode":2},"sleepMode":false,"lampWireStatus":{"headLamp":{"headLampStatus":false,"lampLL":false,"lampRL":false,"lampLH":false,"lampRH":false,"lampLB":false,"lampRB":false},"stopLamp":{"leftLamp":false,"rightLamp":false},"turnSignalLamp":{"lampLF":false,"lampRF":false,"lampLR":false,"lampRR":false}},"windowStatus":{"windowFL":0,"windowFR":0,"windowRL":0,"windowRR":0},"smartKeyBatteryWarning":false,"fuelLevel":8,"washerFluidStatus":true,"brakeOilStatus":false,"engineOilStatus":false,"engineRuntime":{},"remoteControlAvailable":1,"valetParkingMode":0,"rsaStatus":0}},"location":{"coord":{"lat":32.010025,"lon":-82.0637027778,"alt":43,"type":0,"altdo":0},"head":322,"speed":{"value":0,"unit":1},"accuracy":{"hdop":8,"pdop":13},"syncDate":{"utc":"20231228193809","offset":-8}},"financed":true,"financeRegistered":false,"linkStatus":0,"rsaStatus":0}}]}}
2023-12-28 14:51:35.067 DEBUG (SyncWorker_4) [hyundai_kia_connect_api.KiaUvoAPIUSA] hyundai_kia_connect_api - last_updated_at - before<PHONE_NUMBER>3809
2023-12-28 14:51:35.067 DEBUG (SyncWorker_4) [hyundai_kia_connect_api.KiaUvoAPIUSA] hyundai_kia_connect_api - last_updated_at - after 2023-12-28 19:38:09+00:00
2023-12-28 14:51:35.067 DEBUG (SyncWorker_4) [hyundai_kia_connect_api.KiaUvoAPIUSA] hyundai_kia_connect_api - SOC Levels couldn't be found. May not be an EV.
2023-12-28 14:51:35.068 DEBUG (SyncWorker_4) [hyundai_kia_connect_api.KiaUvoAPIUSA] hyundai_kia_connect_api - last_updated_at - before<PHONE_NUMBER>3809
2023-12-28 14:51:35.068 DEBUG (SyncWorker_4) [hyundai_kia_connect_api.KiaUvoAPIUSA] hyundai_kia_connect_api - last_updated_at - after 2023-12-28 19:38:09+00:00
2023-12-28 14:51:35.068 DEBUG (MainThread) [custom_components.kia_uvo.coordinator] Finished fetching kia_uvo data in 0.870 seconds (success: True)

This is the script
alias: Warm Up
sequence:
  - service: kia_uvo.start_climate
    data:
      duration: 10
      climate: true
      temperature: 74
      heating: "1"
      device_id: cf054bd276f7e10643c99f56b5984ef8
      flseat: "8"
      defrost: false
mode: single
icon: mdi:car

Maybe try send the front left seat without the quotes.

That worked!  Thank you so much for taking the time to help me figure this out.

I've opened https://github.com/Hyundai-Kia-Connect/hyundai_kia_connect_api/pull/699, which uses the original values that @poisonbl reported for each heat/cool setting and have confirmed that they work on my US 2024 Kia EV9.  I also refactored the code a little bit to treat the values more like constants/enum values and got rid of the math that seemed to be tripping people up (and which also confused me).  Hope this helps!

I have merged your item and I also updated manifest https://github.com/Hyundai-Kia-Connect/kia_uvo/commit/24321f97819642084389dd1ceddebd7f35a13db8

Let us know if this works now in latest.

This worked for me, although I noticed that the steering wheel didn't turn on -- separate issue.  I think I know why though and will submit another PR for that once I've verified things.  Thank you!


[WIP] UCF101 prototype with utilities for video loading

A simple pyav based set of utilities with a POC implementation for UCF101 dataset
cc @pmeier @bjuncek

Ok, so I've tried doing a pass on this, trying to fix the decoder inconsistency we've been talking about offline.
I don't understand datapipes well enough to understand why pop from a dict would fail or why I'd need to annotate variables in a datapipe. Everything since 8f57ee6 has nothing to do with the functionality of the UCF101 dataset and can be reverted if you want to do a clean pass and then merge into this.

@bjuncek I've cleaned up the PR with recent changes and also removed all the decoder changes. We will handle this separate from this PR following #5075.