Victron SolarCharge unavailable after HA update or just randomly

Victron SolarCharge unavailable after HA update or just randomly. Reinstall of Victron integration solved it but reload did not. I am tired of reinstalling Victron every time, so i report it here

Logger: homeassistant.helpers.entity
Source: helpers/entity.py:885
First occurred: 21:17:07 (1 occurrences)
Last logged: 21:17:07

Updating state for sensor.victron_solarcharger_maxpower_today_223 (<class 'custom_components.victron.sensor.VictronSensor'>) took 1.105 seconds. Please create a bug report at https://github.com/sfstar/hass-victron/issues

This error originated from a custom integration.

Logger: homeassistant
Source: custom_components/victron/sensor.py:157
Integration: victron (documentation, issues)
First occurred: October 30, 2023 at 05:18:40 (8 occurrences)
Last logged: 05:12:13

Error doing job: Task exception was never retrieved
Traceback (most recent call last):
  File "/usr/src/homeassistant/homeassistant/helpers/update_coordinator.py", line 233, in _handle_refresh_interval
    await self._async_refresh(log_failures=True, scheduled=True)
  File "/usr/src/homeassistant/homeassistant/helpers/update_coordinator.py", line 389, in _async_refresh
    self.async_update_listeners()
  File "/usr/src/homeassistant/homeassistant/helpers/update_coordinator.py", line 172, in async_update_listeners
    update_callback()
  File "/config/custom_components/victron/sensor.py", line 157, in _handle_coordinator_update
    self._attr_native_value = self.entity_type.decodeEnum(data).name.split("_DUPLICATE")[0]
                              ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.11/enum.py", line 712, in __call__
    return cls.__new__(cls, value)
           ^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.11/enum.py", line 1128, in __new__
    raise ve_exc
ValueError: 245.0 is not a valid solarcharger_state

i updated the HA to latest and also reinstalled victron integration and it worked that time. However after a few hours i noticed that the solarcharge went "unavailable".

If it is a VE.Can charge controller, it might have changed ID from 0 to 100 - check if there's a new charge controller with the new ID.

Yes it is VE.Can charge controller and it shows Model 0 when it is unavailable and when i reinstall Victron integration and the stats are back this page still showing model 0 for the solarcharger. Anyways thanks for the idea

any updates ? it is happening to me as well

What I used to do is to just reboot HA once. The ID would change to 100, and stay there, unless the integration was re-installed and did a rescan. Then I changed all my automations and monitors to use this value, and not 0. Worked quite well for me.
Eventually I decided to change from VE.Can to VE.Direct, for this and other reasons. I only have 2 charge controllers in total.

still the same issue with the latest HA. Note that the solarcharger ID is always zero, if you restart HA the solarcharger reporting stops working and as i wrote if i delete and reinstall Victron integration then it works again. The ID of solarcharger is still zero. VE.Can is modern and easy to use solution, i would not switch to VE.Direct.

Try this instead:

Restart HA, but do NOT re-install the HASS components
Check your devices. There will be 2 devices with ID 100, one showing with a lot of errors, the other working fine

The working one should contain all the entities for your solar charge controller, and you can use those without issues - they will stay at ID 100 after a reboot. Don't try to force it back to 0, rather just use the new value.
The issue is that ID 0 and ID 100 is the same for the GX device. This is because some modbus servers cannot access ID 0, so the CCGX also responds to ID 100 for these, this is documented in the modbus docs for Victron. But ID 100 is also used for the system values, so ID 100 causes a conflict that the integration can't handle properly.
Before I switched to VE.Direct I did it this way, and all my integrations and entities worked fine. I would have continued to use it this way, not switching to VE.Direct, but I found that the Cerbo GX history for the charge controllers only covers 1 day with VE.Can and 30 days with VE.Direct. Since I like having the history on the Cerbo, I switched to VE.Direct.

this does not happen to me as you wrote. What happens are:

Restart HA, but do NOT re-install the HASS components
Check your devices. The solarcharger still have ID 0 just like before reboot and the Victron settings is ID 100 just like before reboot.

This is nothing to do with ID change because there is no ID change before or after, but i need to reinstall the Victron integration to make solarcharger reporting again

this does not happen to me as you wrote. What happens are:
1. Restart HA, but do NOT re-install the HASS components

2. Check your devices. The solarcharger still have ID 0 just like before reboot and the Victron settings is ID 100 just like before reboot.

This is nothing to do with ID change because there is no ID change before or after, but i need to reinstall the Victron integration to make solarcharger reporting again
small good news: with the latest HA and latest Victron integration, i dont need to reinstall the integration, just "configure" > "rescan" which is 3 second job, i just need to keep in mind doing it after every HA restart. For me 30 day history is not important, I keep VE.Can. This Victron integration should do a rescan automatically after every HA reboot, not hard to implement and we could close this ticket. For some reason if i check/enable rescan, this settings does not survive the reboot.

Hello,
I have 2 solar charge controllers in my system and these are connected to the Cerbo via CAN. After each restart of HA, you have to perform a manual rescan, as the solar charge controller with ID 0 is assigned ID 100 after the restart.This is very annoying and is often only noticed later!
An automatic rescan after the restart would be very desirable. Perhaps this can also be implemented as an HA service. Then you can build your own automation?

Having the same issue, an automatic rescan would indeed help a lot.

lets keep this open until there will be better solution but at least this workaround does not take much time, we just need to remember to do after every restart

I have the same issue with MPPT 250/100 - after every restart of HA the MPPT becomes unavailable, I have to go to rescan manually and then it works again. Would be great to have this automatically done during the startup of the integration, perhaps.

Имайки същия проблем, автоматичното повторно сканиране наистина би помогнало много.

+1

The issue has been shipped in the latest release (v0.3.0) closing issue as resolved.
Feel free to re-open if the issue persists with the v0.3.0 release


Support for Python 3.7

Check what works and what doesn't work in Python 3.7:

Code refactoring
Sorting of imports
Intellisense, code navigation, etc
Unit tests (all three test frameworks)
Linting
Support in new language server
Support in experimental debugger

We need to be proactive in identifying these before users start reporting issues.
/cc @brettcannon

Lol, duplicate #962


replace CombinedFilterOperator with AndFilterOperator

~This operator is just an AndFilterOperator with two arguments and can be generalised (which reduces the amount of code which needs to be maintained).~ I noticed it actually calls getNonScanFilterBLockDocIdSet which does make it different to AndFilterOperator though no tests in pinot-core fail as a result of removing it (running the tests here just to figure out which tests will break).

Codecov Report

Merging #8428 (97329e6) into master (ebd20a4) will decrease coverage by 2.89%.
The diff coverage is 100.00%.

:exclamation: Current head 97329e6 differs from pull request most recent head fd250bf. Consider uploading reports for the commit fd250bf to get more accurate results

@@             Coverage Diff              @@
##             master    #8428      +/-   ##
============================================
- Coverage     69.89%   66.99%   -2.90%
+ Complexity     4282     4195      -87
============================================
  Files          1661     1258     -403
  Lines         87046    63519   -23527
  Branches      13134     9935    -3199
============================================
- Hits          60838    42555   -18283
+ Misses        21963    17920    -4043
+ Partials       4245     3044    -1201

Flag
Coverage Δ

integration1
?

unittests1
66.99% <100.00%> (-0.08%)
:arrow_down:

unittests2
?

Flags with carried forward coverage won't be shown. Click here to find out more.

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

All checks passed? Is this redundant or do we have a testing gap?

This operator only applies to the aggregation FILTER, where we don't need to scan the main filter multiple times


Templates

Hey! Work's perfectly on Manjaro.
Any way to create/modify pages?

try this one.... https://github.com/An0nUD4Y/SocialFish

Yes, Coming soon with the new version :D


dependabot failure: build(deps): bump library/golang from 1.18.3 to 1.20.1

PR: https://github.com/cilium/tetragon/pull/731

I’ll fix this.


added custom timestamp in case of namemc block

bad code but It Works :DDDDDDDDDDDDDDDDD
Wpow

Can't merge this because of conflicts. I'll work on this in the recode.

Can't merge this because of conflicts. I'll work on this in the recode.


Implement license expressions

Currently, the library uses strings as license expressions. Implement proper handling of license expressions instead.

This would indeed by great addition, esp. since the (only?) alternative at https://github.com/jslicense/spdx-expression-parse.js was updated 3 year ago...

clearlydefined maintains a fork: https://github.com/clearlydefined/spdx-expression-parse.js

clearlydefined maintains a fork: https://github.com/clearlydefined/spdx-expression-parse.js

So do the people at https://github.com/onebeyond/spdx-license-satisfies.


Use of multiple embedding model in one quarkus application

In one quarkus application i want to use 2 features:

an EmbeddingModelTextClassifier that use AllMiniLmL6V2EmbeddingModel
a chat that use ollama chat model and embedding model.

when i add quarkus-langchain4j-ollama and langchain4j-embeddings-all-minilm-l6-v2 dependecy in my gradle file , it produces an error during intialization: 2 synthetic beans are deploy for  EmbeddingModel type:
[3] Ambiguous dependencies for type dev.langchain4j.model.embedding.EmbeddingModel and qualifiers [@Default]
	- injection target: com.cqc.syndifun.celia.ai.ingestor.DataIngestor#embeddingModel
	- declared on CLASS bean [types=[com.cqc.syndifun.celia.ai.ingestor.DataIngestor, java.lang.Object], qualifiers=[@Default, @Any], target=com.cqc.syndifun.celia.ai.ingestor.DataIngestor]
	- available beans:
		- SYNTHETIC bean [types=[dev.langchain4j.model.embedding.EmbeddingModel, dev.langchain4j.model.embedding.AllMiniLmL6V2EmbeddingModel, java.lang.Object], qualifiers=[@Default, @Any], target=n/a]
		- SYNTHETIC bean [types=[dev.langchain4j.model.embedding.EmbeddingModel, java.lang.Object], qualifiers=[@Default, @Any], target=n/a]

Is there a way to avoid the automatic deployment of langchain4j-embeddings-all-minilm-l6-v2 EmbeddingModel bean ?

And you want to inject the Ollama or the AllMiniLmL6V2EmbeddingModel here? If the latter, you could just change the injection point to request AllMiniLmL6V2EmbeddingModel instead of the generic EmbeddingModel
I think it's a bug that the Ollama embedding model bean is registered only with types=[dev.langchain4j.model.embedding.EmbeddingModel, java.lang.Object] so you can't qualify it in that case, it should also be registered as io.quarkiverse.langchain4j.ollama.OllamaEmbeddingModel

@geoand TBH I'm not sure having a quarkus.langchain4j.embedding-model.provider property (and same for other model types)  and filtering models through that is such a good thing, why shouldn't we simply register everything and let users qualify the provider by declaring the type on the injection point...? This makes it very hard to use multiple providers in a single app, which it seems, might be more common than we thought.

I want to inject ollama models , and just use the constructor of AllMiniLmL6V2EmbeddingModel as parameter of my EmbeddingModelTextClassifier. But there will be certainly use case where we would like to use multi providers.
But certainlyI think it's link to the fact quarkus-langchain register automaticaly beans with the corresponding factory

Yeah I think we will have to rework the CDI integration somewhat, register the Ollama model with the concrete type as well, and probably get rid of the *.provider properties, because injecting a particular model class seems to mess with that quite badly too :/

Could it be link to: https://github.com/quarkiverse/quarkus-langchain4j/blob/main/core/deployment/src/main/java/io/quarkiverse/langchain4j/deployment/BeansProcessor.java#L169
I'm not sure I had this behavior before I upgrade recently.

Unless you depend on the Easy RAG extension this branch shouldn't execute

If you're looking for a workaround that works now, I'd suggest to use a builder instead of injecting via CDI

I'm trying to understand what is deploying a synthetic bean when i add the langchain4j-embeddings-all-minilm-l6-v2. because multi embedding providers seems to work when looking at MultipleEmbeddingModelsTest.
But when I just add the langchain4j-embeddings-all-minilm-l6-v2 dependency in this test, all tests are failing with the issue.

Ahaaa, so it's a bit different than I thought - we do support multiple providers if you create separate named configurations to distinguish them (I wrongly thought the model names were to distinguish multiple configs of one provider) - try looking at https://github.com/quarkiverse/quarkus-langchain4j/blob/main/integration-tests/multiple-providers/src/main/resources/application.properties and do something similar in your app?

In progress, it seems something is different for AllMiniLmL6V2EmbeddingModel. it should be used as default provider because it is not deployed with correct qualifier.
I tried with a modename e3 : quarkus.langchain4j.e3.embedding-model.provider=dev.langchain4j.model.embedding.AllMiniLmL6V2EmbeddingModel but did not work.
And with default using quarkus.langchain4j.embedding-model.provider=dev.langchain4j.model.embedding.AllMiniLmL6V2EmbeddingModel it worked.
Seems some qualifier management is not done for AllMiniLmL6V2EmbeddingModel bean deployment

That is in https://github.com/quarkiverse/quarkus-langchain4j/blob/main/core/deployment/src/main/java/io/quarkiverse/langchain4j/deployment/InProcessEmbeddingProcessor.java#L121, we probably need to attach the model name qualifier here

ok , i have a fix, but I already have a fork for another PR, will do a PR after it.
Do you know if I  can do  a PR without fork , just by creating a branch or it's not allowed in this project ?

Hi @geoand , I have a fix, but I already have a PR for PG Vector. Do you know how I can do 2 PR at same time for this repo ?

Do you know how I can do 2 PR at same time for this repo ?

You certainly can :)

@geoand you're right :) https://github.com/quarkiverse/quarkus-langchain4j/pull/481


Win Condition Issue

Once player 1 gets killed it shows "Tie" not "Player 2 Wins". However, when player 2 dies it does show "Player 1 Wins" and if its a tie then it does show "Tie".

The win condition issue was related to two things.

In the classes.js file under takehit() class I forgot to update the player1.health -=20 to this.health -=20. Which meant that the HP bar kept stopping at 20% and player 2.
The second issue was in index.js under  playerCollision() for player. I forgot to remove the player2.health -=20 which meant that the player 2 was actually doing -40 dmg.

These have been resolved and the win conditions work perfectly now


arch: riscv: add an option for empty spurious interrupt handler

Add the possibility to disable fault handling in spurious interrupt handler on RISCs and replacce it with an infinite loop.

@ycsin It reduces code size in some cases, for example, when multithreading and timers (CONFIG_SYS_CLOCK_EXISTS) are disabled.

Just a thought - if we're adding such functionality here, maybe we should expand it to cover all architectures?

Just a thought - if we're adding such functionality here, maybe we should expand it to cover all architectures? This way we'd have a common kernel configuration mechanism for this.

@fkokosinski Sure, I think this is a good idea, but maybe it could be done in a separate PR? Alternatively, I could modify this PR to make the Kconfig option global and leave implementation only for RISC-V. What do you think?

Just a thought - if we're adding such functionality here, maybe we should expand it to cover all architectures? This way we'd have a common kernel configuration mechanism for this.

@fkokosinski Sure, I think this is a good idea, but maybe it could be done in a separate PR? Alternatively, I could modify this PR to make the Kconfig option global and leave implementation only for RISC-V.

From my standpoint the latter sounds better to me. This would probably have to have a pair of Kconfig options like CONFIG_ARCH_SUPPORTS_EMPTY_IRQ_SPURIOUS selected by CONFIG_RISCV, and CONFIG_EMPTY_IRQ_SPURIOUS which would be exposed to the user. But this of course will need a broader discussion here :)

From my standpoint the latter sounds better to me. This would probably have to have a pair of Kconfig options like CONFIG_ARCH_SUPPORTS_EMPTY_IRQ_SPURIOUS selected by CONFIG_RISCV, and CONFIG_EMPTY_IRQ_SPURIOUS which would be exposed to the user.

Sounds good to me.

But this of course will need a broader discussion here :)

@fkokosinski What do you mean by broader discussion? Should I involve someone else in the discussion? If so, who should I ping?
Sorry for responding after such a long time, I was on vacation ☺

What do you mean by broader discussion? Should I involve someone else in the discussion? If so, who should I ping?

I just meant a broader discussion will happen here in the PR when you modify some general kernel Kconfig options :) People will be pinged automatically when you push such changes, so you don't have to ping anyone manually


chore(deps): update docker/login-action digest to d910b14

This PR contains the following updates:

Package
Type
Update
Change

docker/login-action
action
digest
5f4866a -> d910b14

Configuration
📅 Schedule: Branch creation - At any time (no schedule defined), Automerge - At any time (no schedule defined).
🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.
♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.
🔕 Ignore: Close this PR and you won't be reminded about this update again.

[ ] If you want to rebase/retry this PR, check this box

This PR has been generated by Renovate Bot.

Edited/Blocked Notification
Renovate will not automatically rebase this PR, because it does not recognize the last commit author and assumes somebody else may have edited the PR.
You can manually request rebase by checking the rebase/retry box above.
⚠ Warning: custom changes will be lost.


Fix typo in openssl-pkeyutl(1)

Changed "than" to "then" for improved clarity and correctness.
CLA: trivial
Fixes #21543

This pull request is ready to merge

Merged to master. Thank you.


fix network creation behavior

Nerdctl default network should be considered like other networks, that means we should be able to CRUD the default network.
in this PR I am eliminating the confusion during a default network CRUD by disabling automatic creation during CRUD.
The default network still be automatically created by a container runtime
fixing https://github.com/containerd/nerdctl/issues/1490
Signed-off-by: fahed dorgaa<EMAIL_ADDRESS>

Like I have saied in https://github.com/containerd/nerdctl/issues/1490#issuecomment-1312680880, I think we need extra validate step before we CRUD the network

Like I have saied in #1490 (comment), I think we need extra validate step before we CRUD the network

this PR do modify the actual network CRUD but it fix default network creation behavior which is one of the prerequisite of networks CRUD

LGTM (though still need other reviewer's approval 😛 )


Datatabase schema is not set

Database schema is required by this script:
https://github.com/microsoft/aerial_wildlife_detection/blob/de150d03e267676876554f62188689cf4196f4bb/projectCreation/import_images.py#L50
Missing from:
https://github.com/microsoft/aerial_wildlife_detection/blob/de150d03e267676876554f62188689cf4196f4bb/config/settings.ini#L127-L140
I would also suggest raising an error if the parameter is mandatory but missing.
schema should be equal to the user name.

Thank you very much for this issue.
This is a legacy script that originates to AIDE version 1.0 where only one "project" could be supported at a time (and had to be speciﬁed in the settings.ini ﬁle, precisely through the schema keyword). With AIDE version 2.0, this keyword has become obsolete as an arbitrary number of projects can now be created.
I have resolved the issue in the latest commit (and also removed the SQL injection vulnerability mentioned in the respective issue). The same holds for the ﬁle in the latest development branch.


setting value on city s

This is the cause of https://github.com/donejs/place-my-order/issues/136.

Coverage remained the same at 96.396% when pulling 514cb2f3b4d830056dc262f0db7debca9dcd1641 on city-option into ccce51c4af826e8cdde66b119010107231f9702d on major.


Have better template checkpoints

Have a "hints" folder for each course that can be used if students struggle with one part. This would allow students to either peek at a solution, or to start from a known-good starting point when moving forward.

I provided hints and and a solution for the knight rider animation.


Adds Update API action to Conference resource.

You may update the properties of a Conference via POSTing the following parameter:
Parameter: Status
Description: Specifying completed will end the conference and kick all participants
https://www.twilio.com/docs/api/rest/conference#instance-post

Thanks! :star: :star: :star:


Consult about before / after hooks with features files

Current behavior
before() and after() hooks are executed before each feature
Desired behavior

before() and after() hooks should be executed before / after all test

beforeFeature() and afterFeature() hooks should be executed before / after each feature

Test code to reproduce
I have this hook on my repository to clean artifacts folder before the execution
before(function () {   if (executionConfig.clean_artifacts) {     cy.task("deleteArtifactsFolder");   } });
When I run all test, this hook is executed before each feature.
Versions

Cypress version: 12.14.0
Preprocessor version: 17.2.0
Node version: 16

Hey, and thanks for reporting this issue. You need to provide a minimal, reproducible example issues that illustrates the issue.

If I'm understanding correctly we had a similar requirement.
you could create your own beforeFeature() hook like this:
import { Before } from '@badeball/cypress-cucumber-preprocessor';

/**
 * Is similar to Cypress' `before()` hook, but is re-run when a test is retried (e.g. `@retries(runMode=1)`)
 *
 * Utilises the cucumber plugin `Before()` hook for consistency (mixing mocha and cucumber hooks seems to cause
 * issues in execution order, reporting and especially during retries)
 *
 * Additionally runs within the context of a test instead of before the test has been created and therefore failures
 * in this hook will still get reported in cucumber based json reports
 * e.g. `  Hook failures can't be represented in JSON reports, thus none is created for ${spec.relative}.`
 *
 * Because we use `before()` as a place to setup test state this can be the cause of assertion failures.
 * Therefore it's important to support cypress' retry functionality to make our suites more reliable.
 *
 * Inspired by:
 * https://github.com/cypress-io/cypress/issues/19458
 * https://stackoverflow.com/questions/71285827/cypress-e2e-before-hook-not-working-on-retries
 */
export const retryableBeforeFeature = (fn: () => void) => {
  let shouldRun = true;
  let beforeHookResult = false;

  // we use Before from cucumber pre-processor as cypress will run this on retry attempt
  // we just abort early if we detected that it's already run to ensure this is only run once
  // i.e. replicating Cypress' `before()` rather than `beforeEach()`
  Before(function () {
    // console.log({ step: 1, shouldRun, beforeHookResult });

    if (!shouldRun) {
      if (!beforeHookResult) {
        this.skip();
      }
    }
    if (shouldRun) {
      shouldRun = false;

      fn();
    }
  });

  /**
   * This Hook will only run if the previous one passed so is a simple way of determining if the passed `fn()` was successful or not.
   * Due to Cypress's method of semi-asynchrnous comand chaining we can't await or rely on a return value
   */
  Before(function () {
    // console.log({ step: 2, shouldRun, beforeHookResult });
    beforeHookResult = true;
  });

  // When a test fails we flip the `shouldRun` flag back to true
  // so when cypress retries and runs the `Before()` before
  // the test that failed, we'll run the `fn()` logic once more.
  Cypress.on('test:after:run', (result) => {
    if (result.state === 'failed') {
      if (result.currentRetry < result.retries) {
        shouldRun = true;
      }
    }
  });
};

Closing due to lack of a reproducible example. I have little to no desire to speculate as to what you mean here.


Would like to edit categories from the desktop calendar

I would really like to edit the categories from the desktop calendar. At the moment, when I right click the feature, it is greyed out. I normally change my tasks to green once I have completed them, and right now, I have to open Outlook every time I want to mark a task completed. It would really help if "Categories" could be available from the desktop calendar. Thanks!

I found the solution! Just had to double click on the entry itself and change it from there!


Update min rust version to v1.71.0

What type of PR is this?
/kind ci
What this PR does / why we need it:
This should be good to go, we have rust v1.71.0 in EL8/9.
Which issue(s) this PR fixes:

None
Special notes for your reviewer:
None
Does this PR introduce a user-facing change?

None

@rphillips @haircommander PTAL

/lgtm


Add support for s8s8 dynamic quant

This will be used in PyTorch for accelerating dynamic quantization by using s8s8 matmul accelerated by ACL (see
https://github.com/oneapi-src/oneDNN/pull/1885). This can go in without oneDNN 3.5, but will only offer performance benefits after it does.
Also, do you have a policy on copyright headers? I noticed that on this branch at least, most of the copyright headers were removed a few years ago. However, Arm's usual policy when contributing to open source projects is to include a copyright header on any file which is modified. Would this be acceptable? If not, is there somewhere else suitable to note copyright?

Thanks @jgong5. Given that this file doesn't have an existing copyright notice, would it be acceptable to add an Arm copyright line in the top level header file? This seems to be one of the only references to copyright on the pytorch_ideep branch https://github.com/intel/ideep/blob/a9e5602a1a5c93e270479e88b38c81e223b19fa9/include/ideep.hpp#L2

I'm happy to get this in without the copyright notices, and work it out later. What's the process for getting this merged?

Do you include this change in PyTorch CI? If so, I can merge directly.
cc @Xia-Weiwen to review more.

Do you include this change in PyTorch CI? If so, I can merge directly. cc @Xia-Weiwen to review more.

LGTM


Collection of CSV/TAB sample files for testing

@firecat53, @scls19fr
Random issue here: on a related project I'm working at work™ I've got the chance to adapt some existing code I wrote to parse large text files. In fact, the API I designed relied on a dumb/simple streaming approach which never actually loads any part of the file in memory (not even cell contents).
It allows, for example, to seek in a random portion of a text file, align to line/cell boundaries and start reading both forward and reverse from there. I'm using it mostly to preview large genetic data files (10+gb in size nowdays), as an "enhanced od(1)". The tool I'm using on top of it though is crap: done in a rush in less than a day, so nothing worth saving.
My idea is as follows: clean up the csv reading code a bit, and make it part of the tabview-common series of projects. Build a cython module for it, exposing an API ideally identical to the "csv" module, so that I can be swapped under the hood (for those who need the extra speed) without creating additional dependencies. For instance, the separator/format detection is actually much more robust CSV_sniffer and doesn't suffer from the python2/3 universal newlines issues.
The main issue is that the existing code doesn't handle all the possible CSV escaping/quoting/crappy-format issues. I'd like to build a small set of tabular text files (10x10 cells at most), which exercise all the possible text format issues, including the broken outputs coming from Excel, mysql, and whatnot, different line endings, files with/without the UTF8 BOM, several encodings, different header styles, etc.
I couldn't find any project that has something similar. For instance, I expected to find some demo files in libcsv, fccp, xsv, or python's csv library code, but nothing.
It would be nice if you could help: if you see a different text file format, just save a chunk of it somewhere so we can build a proper test suite for all the tabview projects.

Sorry @wavexx I have no such set of files

I'll pass them on as I find them. Sounds like a great idea...we can use those for testing tabview as well. Seems like the best way to get new broken files is by increasing our userbase....people have been good so far about submitting issues when unsuccessfully trying to view a file.
Perhaps looking around on any Excel forums would surely generate a number of interesting files!
Scott

On 07/09/15 23:51, Scott Hansen wrote:

I'll pass them on as I find them. Sounds like a great idea...we can use
those for testing tabview as well. Seems like the best way to get new
broken files is by increasing our userbase....people have been good so
far about submitting issues when unsuccessfully trying to view a file.
Perhaps looking around on any Excel forums would surely generate a
number of interesting files!

I have a few cornercases that are easy to generate by hand and probably
do so.
Ideally, you would test 1 specific feature in each file, so that it
helps testing quicker.
But yeah, it's otherwise a boring job to do by hand.


Deprecate the 'auto' type name

The auto type name can either be replaced with the var keyword in local variable declarations or should be omitted in favor of a concrete type in member declarations. Thus, it doesn't provide any real value and can be removed (in the next release)

The auto type name is no longer available as of release v0.32.0.


scc: 3.3.0 -> 3.3.3

Automatic update generated by nixpkgs-update tools. This update was made based on information from https://github.com/boyter/scc/releases.
meta.description for scc is: A very fast accurate code counter with complexity calculations and COCOMO estimates written in pure Go
meta.homepage for scc is: https://github.com/boyter/scc
Updates performed

Golang update

To inspect upstream changes

Release on GitHub

Compare changes on GitHub

Impact
Checks done

built on NixOS
The tests defined in passthru.tests, if any, passed
found 3.3.3 with grep in /nix/store/a74z6qkqjc45py5aj3d10phgljzbkwdd-scc-3.3.3
found 3.3.3 in filename of file in /nix/store/a74z6qkqjc45py5aj3d10phgljzbkwdd-scc-3.3.3

Rebuild report (if merged into master) (click to expand)

2 total rebuild path(s)

2 package rebuild(s)

First fifty rebuilds by attrpath

scc

Instructions to test this update (click to expand)

Either download from Cachix:
nix-store -r /nix/store/a74z6qkqjc45py5aj3d10phgljzbkwdd-scc-3.3.3 \
  --option binary-caches 'https://cache.nixos.org/ https://nix-community.cachix.org/' \
  --option trusted-public-keys '
  nix-community.cachix.org-1:mB9FSh9qf2dCimDSUo8Zy7bkq5CX+/rkCWyvRCYg3Fs=
  cache.nixos.org-1:6NCHdD59X431o0gWypbMrAURkbJ16ZPMQFGspcDShjY=
  '

(The Cachix cache is only trusted for this store-path realization.)
For the Cachix download to work, your user must be in the trusted-users list or you can use sudo since root is effectively trusted.
Or, build yourself:
nix-build -A scc https://github.com/r-ryantm/nixpkgs/archive/6b7127232a63ec84b44cfc085420aeb5f26a23ce.tar.gz

Or:
nix build github:r-ryantm/nixpkgs/6b7127232a63ec84b44cfc085420aeb5f26a23ce#scc

After you've downloaded or built it, look at the files and if there are any, run the binaries:
ls -la /nix/store/a74z6qkqjc45py5aj3d10phgljzbkwdd-scc-3.3.3
ls -la /nix/store/a74z6qkqjc45py5aj3d10phgljzbkwdd-scc-3.3.3/bin

Pre-merge build results
We have automatically built all packages that will get rebuilt due to
this change.
This gives evidence on whether the upgrade will break dependent packages.
Note sometimes packages show up as failed to build independent of the
change, simply because they are already broken on the target branch.
Result of nixpkgs-review --extra-nixpkgs-config '{ allowInsecurePredicate = x: true; }' run on x86_64-linux 1

1 package built:

scc

Maintainer pings
cc @sigma @Br1ght0ne for testing.

Result of nixpkgs-review pr 310233 run on aarch64-darwin 1

1 package built:

scc


Add option to rename symbols in Nature DSP library

BUG=b/327609938

@rascani can you please re-approve and merge.


Swap to python -m build instead of python setup.py <format>

As warned in our CI, we really needed to modernize how we produce our wheels/sdists.
Unfortunately, it looks like I'm going to need to add a post-step that unzips the tar.gz and rezips it if we want to continue publishing our sdists as zip. Unfortunately, unlike python setup.py, it doesn't look like build honors --format=sdist.
EDIT: found the official docs referencing the new requirement: https://packaging.python.org/en/latest/key_projects/#build, for anyone concerned about introducing a random build package 👍

[x] Check all tox environments
[x] This PR somehow destroys all the logging cleanup that I had finished with python setup.py. Need to resolve this before merging. python -m build is loud.
[x] Ensure that integration and pypi publishing still works
[x] Ensure that github.io and docs.ms productions still work

I'm not super familiar with packaging -- though I'd like to learn -- but I do remember having read that setup.py was out of date. Are the failures in the current pipeline run expected from this change?

/azp run python - core

/azp run python - template

I am going to wait to merge this until after the release week. Effectively, this means next week.

Due to the fact that we will be using python setup.py until we migrate to pyproject.toml, I am closing this PR. It is ready to go.


Prefetch Meteor and Fix permissions

Description
This change prefetches recent meteor releases for the past 2 years and copies the meteor folder to the "All Users" folders.

Duplicate of #2 functionality.


Ran into an issue when I was using ip whitelisting.

Ran into an issue where the signature wasn't required since I used IP whitelisting. Talked with a tech at expedia and they mentioned a change on their end that if a signature is provided the ip whitelisting is ignored. This change will allow users to disable passing along the signature.

Thanks! I'll look into it today...


Include debug code to staging build?

Some logic should be available from both "debug" and "staging" build types (debug panel as an example).
It is too expensive to create flavors for this purpose because flavors multiply the number of possible build variants and add variants we will never use.
Solutions that I see:

Write a common code in a separate module and include it with [buildType]Implementation configuration. In this case, we still need to write similar initializing code in build types source sets or create a stub implementation of common module.
Append debug source sets to staging source sets. In this case, we don't need to create a separate module.

Now you can do it with mergeSourceSets
android {
    mergeSourceSets(BUILD_TYPE_DEBUG to BUILD_TYPE_STAGING)
}


Slightly updated packages versions

relpaced rollup-plugin-typescript with rollup-plugin-typescript2, which is more actively maintained - so it now builds again
removed rollup-plugin-babel which was not used
added tslint dev dependency, so npm run lint works without globally installing tslint
updated versions

It appears the andrienko:updated-version branch has also fallen behind, in 2021. To get this building again, try something like:
"devDependencies": {
    "rollup": "^2.38.0",
    "rollup-plugin-babel": "^4.4.0",
    "rollup-plugin-typescript": "^1.0.1",
    "tslib": "^2.1.0",
    "typescript": "^4.1.3"
},

It appears the andrienko:updated-version branch has also fallen behind, in 2021. To get this building again, try something like:
"devDependencies": {
    "rollup": "^2.38.0",
    "rollup-plugin-babel": "^4.4.0",
    "rollup-plugin-typescript": "^1.0.1",
    "tslib": "^2.1.0",
    "typescript": "^4.1.3"
},

+1


feat: add sponsor showcase section and silent release preparations

Resolves #20
Resolves #65

So this is weird, I noticed it before, but I wasn't sure because I thought it was still a work in progress.
It seems like AdGuard extension is blocking this section (It shows after I disable it).
The request URL that was blocked is https://www.googletagmanager.com/gtag/js?l=dataLayer.
Do you have any idea why? Do you use an ad blocker? I believe it's quite common for someone to use an ad blocker these days.

So this is weird, I noticed it before, but I wasn't sure because I thought it was still a work in progress.
It seems like AdGuard extension is blocking this section (It shows after I disable it).
The request URL that was blocked is https://www.googletagmanager.com/gtag/js?l=dataLayer.
Do you have any idea why? Do you use an ad blocker? I believe it's quite common for someone to use an ad blocker these days.

Yikes, thanks for catching it bcs it would've been so bad if it went out like that!!
I use uBlock Origin (on Firefox) and it shows up ok for me. What do you use?
As for the images, I have no idea why they're being blocked. I believe https://www.googletagmanager.com/gtag/js?l=dataLayer is from the Google Analytics it tries to run, which shouldn't affect the rest of the site when it gets blocked.
Also, what happens if you try to load the images directly from the /images/ path, for example https://cusec-2021-staging--pr66-feat-sponsor-showcas-p9ixcvvi.web.app/images/Royal_Bank_of_Canada-Logo.wine.svg or https://cusec-2021-staging--pr66-feat-sponsor-showcas-p9ixcvvi.web.app/images/voiceflow-Logo.png

I install AdGuard, checked all the boxes in configuration to block as much as possible, disabled my previous ad blocker, and hard refreshed the page, but the images are still showing for me.

I'm not sure what's going on

In your AdGuard filtering log, does it say that Google Tag Manager is blocked by "Pete's Blocklist"?

Okay, so there is a setting in AdGuard to let the extension turn on filters automatically and I had the AdGuard Russian filter on for some reason. (Don't ask me, I don't know why) 😂
So maybe our Russian AdGuard users might not see the sponsor section?

Okay, so there is a setting in AdGuard to let the extension turn on filters automatically and I had the AdGuard Russian filter on for some reason. (Don't ask me, I don't know why) joy
So maybe our Russian AdGuard users might not see the sponsor section?

The above screenshot is the filtering rule that comes from the Russian filter LOL

LMAO :joy:
That filter wasn't on for me automatically but it started blocking it too once I turned it on.
It's weird that it's not just blocking the images, but the whole sponsor section (just because it had an id of 'sponsor'?)

The only thing that comes to mind is to change the div id, but at the same time it seems much less likely that someone is use the AdGuard extensions with the AdGuard Russian filter?
People usually use those mainstream ad blockers right?

The only thing that comes to mind is to change the div id, but at the same time it seems much less likely that someone is use the AdGuard extensions with the AdGuard Russian filter?
People usually use those mainstream ad blockers right?
backers, benefactors, supporters, promoters are synonyms of sponsors joy

Better safe than sorry! I tried "backers" out and it seems to work with AdGuard with the Russian filter. I'll update it and we'll see if there are any more issues :sweat_smile:


Strip -rcX suffix from version number properly

Previously the digit of the rc as well as the dash would remain
E.g.: -rc2 -> -2
This resulted in it being subtracted from the patch version digit
E.g.: v1.7.0-rc1 turns into 1,7,0-1.
This PR strips the whole -rcX part of the version number in CI
Closes #265

Worked when cherry-picking to 1.7.X branch and running release candidate build:
https://github.com/R2Northstar/Northstar/actions/runs/2249772576


[gardening] Test ffi/function_stress_test/1 is timing out.

Marking the test as Slow did not help as expected.
Cl https://dart-review.googlesource.com/c/sdk/+/100284 was reverted.

Uploaded https://dart-review.googlesource.com/c/sdk/+/103801 to stabilize the test.


WebGL question

Hi, could I have a question?
I stumbled upon your site while trying to solve a problem in Unity Engine WebGL build.
What I want to do, is to simply get and parse text on other site (specifically load current user's stats based on their username).
I use the Unity's version of XMLHttpRequest, UnityWebRequest (documentation) and its Get method. Essentially this code:
string url = "http://cors-anywhere.herokuapp.com/http://[[username]].newgrounds.com/stats";
UnityWebRequest userpage = UnityWebRequest.Get(url); // "GET"
yield return userpage.Send(); // wait until the download is finished
if (userpage.isError) {
    Debug.LogError(userpage.error);
} else {
    // displays data on screen or logs the whole text in case of problems
    ParsePageAndOutputStats(userpage.downloadHandler.text);
}

Unfortunately the browser won't allow me to access the other page:

XMLHttpRequest cannot load http://tomfulp.newgrounds.com/stats. The 'Access-Control-Allow-Origin' header contains the invalid value 'none'. Origin 'http://uploads.ungrounded.net' is therefore not allowed access.

And when I try to prefix the url with your proxy, it works all right on your demo page, but not when I try it in the web build later.

http://cors-anywhere.herokuapp.com/http://tomfulp.newgrounds.com/stats
❌　Failed to load resource: the server responded with a status of 404 (Not Found)
⚠　Not found because of proxy error: Error: getaddrinfo ENOTFOUND http http:80

The demo page I'm trying to get to work can be found here. It outputs the logs and warnings to the browser's console.
Do you have any idea what might be causing the proxy error or a possible solution?
Thank you.

Solved it.
I tried several variants of the url and it works like this, without http://.
http://cors-anywhere.herokuapp.com/www.tomfulp.newgrounds.com/stats


Fix resize of lines

@Lexan reported a bug in #support on discord. I thought this would be an easy fix but it turned out more complicated than expected.
This PR does the following:

Adds support for mil units to SVGElements. I will submit this as a PR to the SVGelements repo in a few minutes. It also fixes a bug where "inchx" would be recognised as "inch" by tweaking the regex.
Simplifies repeated code in PositionPanel.
Fixes "resize" command so that it doesn't treat horiz/vertical lines as dots.

Good to go

Summary - yes, I went down a rabbit hole and lost sight of the need to be precise about supporting the SVG spec and no more in SVGelements. I will rework both this and the SVGelements PR.


human readable ids

So many broken tests!
I suspect we will need to mock the id library in testing because randomness is very upsetting.

Codecov Report

Merging #56 into master will decrease coverage by 0.25%.
The diff coverage is 100%.

@@            Coverage Diff             @@
##           master      #56      +/-   ##
==========================================
- Coverage   84.14%   83.89%   -0.26%
==========================================
  Files          30       30
  Lines         656      652       -4
  Branches      108      108
==========================================
- Hits          552      547       -5
- Misses         96       97       +1
  Partials        8        8

Impacted Files
Coverage Δ

packages/cli/src/commands/add/writeChangeset.js
92.85% <100%> (-7.15%)
:arrow_down:

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 8d2e700...e386c91. Read the comment docs.


Django cache: replace Memcached with Redis

This trims Zulip runtime by removing dependency on an extra remote
cache, and also trims Zulip installation dependency.
Based on @jros2300's #378 and @007's
https://github.com/007/zulip/commits/redis-only, updated to the current
codebase.
Pending: :microscope: the RAM+CPU load in before/after.
Fixes #16

Automated message from Dropbox CLA bot
@rht, it looks like you've already signed the Dropbox CLA. Thanks!

Usage on fresh install: down from ~989M to ~901M. CPU load average remains without noticeable change. brb compiling a graph/chart of the memory consumption breakdown, but a quick eyeball on the current master: 10.0% on manage.py process_queue --all, 4.7% on ./manage.py runtornado , 4.6% on postgres, 4.5% on erlang rabbitmq, 3.4% on webpack-dev-server, 1.9% puppet.

I'm hugely in favor of this as I already have postgres+redis running on all my servers, and it would greatly simplify installing Zulip (sans Docker) for a lot of people.

As I think I've mentioned before, I'm much more interested in an implementation that makes this an option (so we can offer a sane migration path) than something that just flips this over.


Add a way to attach a github issue to feedback

On the uProxy website feedback viewer, there should be a way to attach a github issue to a feedback item

@lucyhe already added the submission date, updating issue to be limited to github issue

Fixed on beta website


BOT 'role' is a required property - 'messages.1'  ...

Oh, I have not seen this error before.
Let me see if I can reproduce it on my end.
Have you tried clearing the message history (Type /c in chat) and trying again?


[core-http] Remove need for lib: ['dom'] in packages that consume core-http

As part of building the samples for appconfig we were forced to add in the lib: ['dom'] in order to get the samples package to compile.
As mentioned by @bterlson:

We should not need the lib entry for dom, if
it's needed it's probably something we can fix
in core-http by stubbing the appropriate types out.

Originally posted by @bterlson in https://github.com/Azure/azure-sdk-for-js/pull/6817

This was fixed in core-http in #7500, and ai-text-analytics and the template were able to remove dom dependencies.
Still-outstanding work is:

Remove lib:dom from keyvault
Remove lib:dom from storage
Remove lib:dom from all sample packages

Keyvault and Storage actually do use dom types in some places, so they will have to mimic the pattern from core-http of importing dom in a d.ts file and then exporting only types that can be shimmed.

(CC @jeremymeng let's track this work here rather than a new issue)

Does this mean any downstream packages that depends on, for example, our storage libraries and using dom types would have to do similar changes as well?

There were some snags in implementing the changes in KeyVault. We can implement the changes by stubbing out any dom types used in the public API surface using the same shimming pattern we use in core-http, but there are some implications for .d.ts rollup when we do. Ultimately, we need support for file references in .d.ts rollup one way or another, but it's not clear how that should be implemented (work would have to be done upstream in Rush for best support).
If DOM types are not used in the public API surface, then the dependency on lib:dom can be freely removed. Marking this up for grabs.

It's been a while since we've seen any real issues with lib: dom. IMO, it's benign for packages to use it with the exception of forgetting to shim DOM types. Package owners can follow the shimming pattern established in core-rest-pipeline if they require shims, but the vast majority of packages should not require this, as they'll get definitions of isomorphic input types from core-rest-pipeline or core-client, which avoid creating any implication on customers to use lib: dom.
Closing this.


Undefined behavior: do_in_place_scope tries to drop scope when scope reference passed to user is still alive

As my project is a bit complex, I have not been successful in creating a minimal reproducing example yet, but an unstripped example run can be found below.
GitHub CI run: https://github.com/SOF3/dynec/actions/runs/3861470087/jobs/6582464784#step:4:487
Source: https://github.com/SOF3/dynec/blob/2e83e3433b54977277a7ba340ac216a60b7da526/src/scheduler/executor.rs#L80-L121
Miri output:
error: Undefined Behavior: not granting access to tag <18216744> because that would remove [SharedReadOnly for <18182613>] which is protected because it is an argument of call 4729027
    --> /home/runner/.rustup/toolchains/nightly-2022-11-22-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/alloc/src/sync.rs:1706:13
     |
1706 |     fn drop(&mut self) {
     |             ^^^^^^^^^ not granting access to tag <18216744> because that would remove [SharedReadOnly for <18182613>] which is protected because it is an argument of call 4729027
     |
     = help: this indicates a potential bug in the program: it performed an invalid operation, but the Stacked Borrows rules it violated are still experimental
     = help: see https://github.com/rust-lang/unsafe-code-guidelines/blob/master/wip/stacked-borrows.md for further information
help: <18216744> was created by a SharedReadWrite retag at offsets [0x0..0x8]
    --> src/scheduler/executor.rs:80:13
     |
80   | /             pool.in_place_scope(|scope| {
81   | |                 let (main_ealloc_shard, worker_ealloc_shards) = ealloc_shards
82   | |                     .split_last_mut()
83   | |                     .expect("ealloc_shards.len() == self.concurrency + 1");
...    |
120  | |                 )
121  | |             });
     | |______________^
help: <18182613> is this argument
    --> /home/runner/.rustup/toolchains/nightly-2022-11-22-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/sys/unix/thread.rs:108:17
     |
108  |                 Box::from_raw(main as *mut Box<dyn FnOnce()>)();
     |                 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
     = note: BACKTRACE:
     = note: inside `<std::sync::Arc<rayon_core::registry::Registry> as std::ops::Drop>::drop` at /home/runner/.rustup/toolchains/nightly-2022-11-22-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/alloc/src/sync.rs:1706:13
     = note: inside `std::ptr::drop_in_place::<std::sync::Arc<rayon_core::registry::Registry>> - shim(Some(std::sync::Arc<rayon_core::registry::Registry>))` at /home/runner/.rustup/toolchains/nightly-2022-11-22-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/ptr/mod.rs:490:1
     = note: inside `std::ptr::drop_in_place::<rayon_core::scope::ScopeBase<'_>> - shim(Some(rayon_core::scope::ScopeBase<'_>))` at /home/runner/.rustup/toolchains/nightly-2022-11-22-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/ptr/mod.rs:490:1
     = note: inside `std::ptr::drop_in_place::<rayon::Scope<'_>> - shim(Some(rayon::Scope<'_>))` at /home/runner/.rustup/toolchains/nightly-2022-11-22-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/ptr/mod.rs:490:1
     = note: inside `rayon_core::scope::do_in_place_scope::<'_, [closure@src/scheduler/executor.rs:80:33: 80:40], ()>` at /home/runner/.cargo/registry/src/github.com-1ecc6299db9ec823/rayon-core-1.10.1/src/scope/mod.rs:441:1
     = note: inside `rayon::ThreadPool::in_place_scope::<'_, [closure@src/scheduler/executor.rs:80:33: 80:40], ()>` at /home/runner/.cargo/registry/src/github.com-1ecc6299db9ec823/rayon-core-1.10.1/src/thread_pool/mod.rs:284:9
note: inside `scheduler::executor::Executor::execute_full_cycle::<tracer::Aggregate<(tracer::Log, scheduler::tests::RunCounterTracer, tracer::Aggregate<(scheduler::tests::UnmarkCounterTracer, scheduler::tests::MaxConcurrencyTracer)>)>>` at src/scheduler/executor.rs:80:13
    --> src/scheduler/executor.rs:80:13
     |
80   | /             pool.in_place_scope(|scope| {
81   | |                 let (main_ealloc_shard, worker_ealloc_shards) = ealloc_shards
82   | |                     .split_last_mut()
83   | |                     .expect("ealloc_shards.len() == self.concurrency + 1");
...    |
120  | |                 )
121  | |             });
     | |______________^

I have a bit of unsafe code in the linked project, but I believe none of those unsafe code are triggered in the unit test that triggers this UB. The error seems to suggest that scope was leaked, but I didn't do anything about it other than calling scope.spawn like normal.

I believe this is a variant of #938 and #952, especially https://github.com/rayon-rs/rayon/issues/952#issuecomment-1170428671. Basically, when we call any Latch::set(&self), its actions cause the thread that owns the latch to unblock and proceed to drop it. If we're unlucky though, we'll still be in set with a now-dangling reference on our hands.
This should be ok in practice since rust-lang/rust#98017 stopped marking references to !Freeze types (containing any UnsafeCell) as LLVM dereferenceable. However, IIRC current miri rules for Stacked Borrows are only allowing that dangling for the part of the struct that is within UnsafeCell, so dropping other fields is flagged as UB. But do note that the message itself states that these rules are still experimental!

I hope that #1011 will fix this, but it would be great if you could test that with your minimal example, or even with your complete project.

It seems miri no longer complains about the UB after using the commit in #1011 indeed


add more static typing to cython to speedup

Should be a little bit faster using this.

Can confirm that python is able to use mutlcore. thank you code space

Great stuff @synodriver ! I'm enjoying learning from your commits = )


Fix OPAL_REINIT_CPUS with HILE_LE on Mambo systemsim

PVR_VERS_MAJ(mfspr(SPR_PVR)) for Mambo systemsim with processor/type P8
has major version 1, yet core/cpu.c sets hile_supported is set for version 2.
However, HID0.HILE does work correctly in P8 systemsim. I've verified that setting the bit causes exception code with MSR.HV=1 to be treated as little-endian. Thus, the following patch introduces another chip quirk (QUIRK_HAVE_HILE).
Before:
[19244603,3] OPAL: Trying a CPU re-init with flags: 0x2
[19250136,3] SLW: Not found on chip 0
[19257911,3] ELOG: Error getting buffer to log error

(and LE exception handlers don't work)
After:
[19244603,3] OPAL: Trying a CPU re-init with flags: 0x2

(and LE exception handlers do work)
Patch:
From 3996b2f40efadfd53d9bdf9a77638ed36aaed40b Mon Sep 17 00:00:00 2001
From: Andrei Warkentin<EMAIL_ADDRESS>Date: Sun, 17 May 2015 01:49:53 -0400
Subject: [PATCH] OPAL: enable opal_reinit_cpus(OPAL_REINIT_CPUS_HILE_LE) to
 work on Mambo systemsim

PVR_VERS_MAJ(mfspr(SPR_PVR)) for Mambo systemsim with processor/type P8
has major version 1, however HID0.HILE does seem to work correctly,
so add a chip quirk for Mambo.

Signed-off-by: Andrei Warkentin<EMAIL_ADDRESS>---
 core/chip.c    | 2 +-
 core/cpu.c     | 2 +-
 include/chip.h | 1 +
 3 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/core/chip.c b/core/chip.c
index 2ba7b6e..09ea825 100644
--- a/core/chip.c
+++ b/core/chip.c
@@ -71,7 +71,7 @@ void init_chips(void)
 	if (dt_find_by_path(dt_root, "/mambo")) {
 		proc_chip_quirks |= QUIRK_NO_CHIPTOD | QUIRK_MAMBO_CALLOUTS
 			| QUIRK_NO_F000F | QUIRK_NO_PBA | QUIRK_NO_OCC_IRQ
-			| QUIRK_DISABLE_NAP;
+			| QUIRK_DISABLE_NAP | QUIRK_HAVE_HILE;
 		prlog(PR_NOTICE, "CHIP: Detected Mambo simulator\n");
 	}
 	if (dt_node_is_compatible(dt_root, "qemu,powernv")) {
diff --git a/core/cpu.c b/core/cpu.c
index 4775883..670d7e9 100644
--- a/core/cpu.c
+++ b/core/cpu.c
@@ -742,7 +742,7 @@ static int64_t opal_reinit_cpus(uint64_t flags)
 	 * use the HID bit. We use the PVR (we could use the EC level in
 	 * the chip but the PVR is more readily available).
 	 */
-	if (hile_supported &&
+	if ((hile_supported || chip_quirk(QUIRK_HAVE_HILE)) &&
 	    (flags & (OPAL_REINIT_CPUS_HILE_BE | OPAL_REINIT_CPUS_HILE_LE))) {
 		bool hile = !!(flags & OPAL_REINIT_CPUS_HILE_LE);

diff --git a/include/chip.h b/include/chip.h
index 0547902..2288d29 100644
--- a/include/chip.h
+++ b/include/chip.h
@@ -98,6 +98,7 @@ enum proc_chip_quirks {
 	QUIRK_NO_PBA		= 0x00000008,
 	QUIRK_NO_OCC_IRQ       	= 0x00000010,
 	QUIRK_DISABLE_NAP	= 0x00000020,
+	QUIRK_HAVE_HILE		= 0x00000040,
 } proc_chip_quirks;

 static inline bool chip_quirk(unsigned int q)
--
1.9.1

On Sun, 2015-05-17 at 00:41 -0700, Andrei Warkentin wrote:

PVR_VERS_MAJ(mfspr(SPR_PVR)) for Mambo systemsim with processor/type
P8
has major version 1, yet core/cpu.c sets hile_supported is set for
version 2.
However, HID0.HILE does work correctly in P8 systemsim. I've verified
that setting the bit causes exception code with MSR.HV=1 to be treated
as little-endian. Thus, the following patch introduces another chip
quirk (QUIRK_HAVE_HILE).

I'd rather we fix Mambo :-) I'll ask internally.
Ben.

Before:
[19244603,3] OPAL: Trying a CPU re-init with flags: 0x2
[19250136,3] SLW: Not found on chip 0
[19257911,3] ELOG: Error getting buffer to log error
(and LE exception handlers don't work)
After:
[19244603,3] OPAL: Trying a CPU re-init with flags: 0x2
(and LE exception handlers do work)
Patch:
From 3996b2f40efadfd53d9bdf9a77638ed36aaed40b Mon Sep 17 00:00:00 2001
From: Andrei Warkentin<EMAIL_ADDRESS>Date: Sun, 17 May 2015 01:49:53 -0400
Subject: [PATCH] OPAL: enable opal_reinit_cpus(OPAL_REINIT_CPUS_HILE_LE) to
work on Mambo systemsim
PVR_VERS_MAJ(mfspr(SPR_PVR)) for Mambo systemsim with processor/type P8
has major version 1, however HID0.HILE does seem to work correctly,
so add a chip quirk for Mambo.
Signed-off-by: Andrei Warkentin<EMAIL_ADDRESS>core/chip.c    | 2 +-
core/cpu.c     | 2 +-
include/chip.h | 1 +
3 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/core/chip.c b/core/chip.c
index 2ba7b6e..09ea825 100644
--- a/core/chip.c
+++ b/core/chip.c
@@ -71,7 +71,7 @@ void init_chips(void)
if (dt_find_by_path(dt_root, "/mambo")) {
proc_chip_quirks |= QUIRK_NO_CHIPTOD | QUIRK_MAMBO_CALLOUTS
| QUIRK_NO_F000F | QUIRK_NO_PBA | QUIRK_NO_OCC_IRQ

      | QUIRK_DISABLE_NAP;

      | QUIRK_DISABLE_NAP | QUIRK_HAVE_HILE;
  prlog(PR_NOTICE, "CHIP: Detected Mambo simulator\n");

}
if (dt_node_is_compatible(dt_root, "qemu,powernv")) {
diff --git a/core/cpu.c b/core/cpu.c
index 4775883..670d7e9 100644
--- a/core/cpu.c
+++ b/core/cpu.c
@@ -742,7 +742,7 @@ static int64_t opal_reinit_cpus(uint64_t flags)

use the HID bit. We use the PVR (we could use the EC level in
the chip but the PVR is more readily available).
*/

if (hile_supported &&

if ((hile_supported || chip_quirk(QUIRK_HAVE_HILE)) &&
(flags & (OPAL_REINIT_CPUS_HILE_BE | OPAL_REINIT_CPUS_HILE_LE))) {
bool hile = !!(flags & OPAL_REINIT_CPUS_HILE_LE);

diff --git a/include/chip.h b/include/chip.h
index 0547902..2288d29 100644
--- a/include/chip.h
+++ b/include/chip.h
@@ -98,6 +98,7 @@ enum proc_chip_quirks {
QUIRK_NO_PBA        = 0x00000008,
QUIRK_NO_OCC_IRQ        = 0x00000010,
QUIRK_DISABLE_NAP   = 0x00000020,

QUIRK_HAVE_HILE     = 0x00000040,
} proc_chip_quirks;

static inline bool chip_quirk(unsigned int q)

Should be fixed as of dd3c3ec045ff47adb5531a49bda50e4c86cd38fa which changes the PVR we give Mambo to 0x4b0201 (in external/mambo/skiboot.tcl) - so hopefully this should be all fixed now


Update index.md

opt out Resivenation # aprox trivib ligit Poc

Why:
Closes [issue link]

What's being changed:

Check off the following:

[x] I have reviewed my changes in staging (look for "Automatically generated comment" and click Modified to view your latest changes).
[x] For content changes, I have completed the self-review checklist.

Writer impact (This section is for GitHub staff members only):

[x] This pull request impacts the contribution experience

[x] I have added the 'writer impact' label
[x] I have added a description and/or a video demo of the changes below (e.g. a "before and after video")

house  hotel Feirnature

.


RFC: Update, view and remove the correlation id

Key information

RFC PR: 516
Related issue(s), if known:
Area: Logger
Meet tenets: Yes
Approved by: @heitorlessa
Reviewed by: @pankajagrawal16 @saragerion

Summary
When using the correlation feature in conjunction with the SQS you may want to update the correlation id for each message in the incoming batch. This allows you to correlate log lines that are being processed in a batch with the lines in an other log group using the CloudWatch Logs Insights.
Further more next to lines that are related to the message there are also lines that are related to the processing of the batch itself. So an easy way to remove the correlation id would be beneficial to have.
Optionally, it might be useful to fetch the current correlation id for displaying purposes.
Motivation
The following code "works" but it breaks the typing as logger.set_correlation_id expects a str and not a Optional[str]:
from aws_lambda_powertools import Logger
from aws_lambda_powertools.utilities.typing import LambdaContext
from aws_lambda_powertools.utilities.batch import sqs_batch_processor
from aws_lambda_powertools.utilities.data_classes.sqs_event import SQSRecord
logger = Logger(service="callback")

def record_handler(record: dict) -> None:
    record = SQSRecord(record)
    # Get the correlation id from the message attributes
    correlation_id = record.message_attributes["correlation_id"].string_value
    logger.set_correlation_id(correlation_id)
    logger.info(f"Processing message with {correlation_id} as correlation_id")

@sqs_batch_processor(record_handler=record_handler)
def lambda_handler(event: dict, context: LambdaContext) -> None:
    logger.set_correlation_id(None)
    logger.info(f"Received a SQSEvent with {len(list(event.records))} records")

If you want to display the current correlation id you need to track it in your own logic, for example:
from aws_lambda_powertools import Logger
from aws_lambda_powertools.logging import correlation_paths
from aws_lambda_powertools.utilities.typing import LambdaContext
from aws_lambda_powertools.utilities.data_classes import (
    event_source,
    APIGatewayProxyEvent,
)
logger = Logger(service="api")

@event_source(data_class=APIGatewayProxyEvent)
@logger.inject_lambda_context(correlation_id_path=correlation_paths.API_GATEWAY_REST)
def lambda_handler(event: APIGatewayProxyEvent, context: LambdaContext) -> dict:
    logger.info(
        f"Received request using {event.request_context.request_id} as correlation id"
    )

Here you see that there are 2 things that you need to maintain the correlation_id_path=correlation_paths.API_GATEWAY_REST and the event.request_context.request_id both need to be updated if you want to change it.
Proposal
Adding Optional[str] typing or a logger.remove_correlation_id() method would solve the removal of the correlation id.
A logger.get_correlation_id() method would help but from the discussions on slack that might not be so straight forward. @heitorlessa could you add some context?
If this feature should be available in other runtimes (e.g. Java, Typescript), how would this look like to ensure consistency? The interface should be the same but tailored to the language standards.
User Experience
Get the current correlation id:
@event_source(data_class=APIGatewayProxyEvent)
@logger.inject_lambda_context(correlation_id_path=correlation_paths.API_GATEWAY_REST)
def lambda_handler(event: APIGatewayProxyEvent, _: LambdaContext) -> dict:
    logger.info(
        f"Received request using {logger.get_correlation_id()} as correlation id"
    )

Remove the correlation id:
logger.set_correlation_id(None)
# or
logger.remove_correlation_id()

Drawbacks
Not that we know of until now
Rationale and alternatives

What other designs have been considered? Why not them? TBD
What is the impact of not doing this? It breaks the typing interface, python will not break on it but it's not nice

Unresolved questions

Optional, stash area for topics that need further development e.g. TBD

Released in 1.18.0


Mouse zooming

Does this PR include the contents of the previous two PRs? If so, should we consolidate everything into this PR?

Does this PR include the contents of the previous two PRs?

Apparently so, the first commit can be taken out, but the 3rd builds on top of the second. If you see an interest in taking them all eventually, we can use this PR and ignore the other two :)

I took the chance to fix the formatting/styling issues over https://github.com/SSShooter/mind-elixir-core/pull/277#event-14227445646

Thanks for your PRs 😆

Thanks for your PRs 😆

Thanks for merging them :)
For the record, your project came to my attention because a PR by @eliandoran recently got merged into https://github.com/TriliumNext/Notes/ , and as such, the next version of the TriliumNext Notes taking app/personal wiki will include a mind mapping feature thanks to mind-elixir!


All YouTube DLs start, then get [Errno 101] Network is unreachable

Checklist

[X] I'm reporting a broken site support
[X] I've verified that I'm running youtube-dl version 2019.11.22
[X] I've checked that all provided URLs are alive and playable in a browser
[X] I've checked that all URLs and arguments with special characters are properly quoted or escaped
[X] I've searched the bugtracker for similar issues including closed ones

Verbose log
youtube-dl -v 'https://youtube.com/watch?v=J1Efz6E3_-0'
[debug] System config: []
[debug] User config: []
[debug] Custom config: []
[debug] Command-line args: ['-v', 'https://youtube.com/watch?v=J1Efz6E3_-0']
[debug] Encodings: locale UTF-8, fs utf-8, out UTF-8, pref UTF-8
[debug] youtube-dl version 2019.11.22
[debug] Python version 3.6.8 (CPython) - Linux-4.15.0-70-lowlatency-x86_64-with-Ubuntu-18.04-bionic
[debug] exe versions: ffmpeg 3.4.6, ffprobe 3.4.6, rtmpdump 2.4
[debug] Proxy map: {}
[youtube] J1Efz6E3_-0: Downloading webpage
[youtube] J1Efz6E3_-0: Downloading video info webpage
[debug] Default format spec: bestvideo+bestaudio/best
WARNING: Requested formats are incompatible for merge and will be merged into mkv.
[debug] Invoking downloader on 'https://r3---sn-p5qlsndr.googlevideo.com/videoplayback?expire=1574566190&ei=zqTZXdHCIo-Dir4P8OCEQA&ip=<IP_ADDRESS>&id=o-AF0mZKHkoqQp4qTm5yAnclIn-KZ8i4SzT0ApHUKuJbI5&itag=137&aitags=133%2C134%2C135%2C136%2C137%2C160%2C242%2C243%2C244%2C247%2C248%2C278&source=youtube&requiressl=yes&mm=31%2C26&mn=sn-p5qlsndr%2Csn-vgqskn76&ms=au%2Conr&mv=m&mvi=2&pl=19&initcwndbps=2086250&mime=video%2Fmp4&gir=yes&clen=2448898441&dur=16193.441&lmt=1574195288308061&mt=1574544495&fvip=6&keepalive=yes&fexp=23842630&c=WEB&txp=5535432&sparams=expire%2Cei%2Cip%2Cid%2Caitags%2Csource%2Crequiressl%2Cmime%2Cgir%2Cclen%2Cdur%2Clmt&sig=ALgxI2wwRgIhAIFGiv5qD9MVzh5WlZ7fSkbmTirw1eSCLOQTGhYoOWXqAiEA1So245WcyzZFjI6Zipmd5FM22VDrYA93ypSuo5XOs8U%3D&lsparams=mm%2Cmn%2Cms%2Cmv%2Cmvi%2Cpl%2Cinitcwndbps&lsig=AHylml4wRQIgHGCKXQvrB82QibRyeR-l4IA5pN6aR6Gr59pATPV4S4ICIQCdNgoNOH5lUZmSvyV4SPmzjlU2nhOuUutNq1q3WmvJ0A%3D%3D&ratebypass=yes'
[download] Destination: The Threads Converge _ Critical Role _ Campaign 2, Episode 85-J1Efz6E3_-0.f137.mp4
[download]   5.4% of 2.28GiB at 12.83MiB/s ETA 02:52ERROR: unable to download video data: <urlopen error [Errno 101] Network is unreachable>
Traceback (most recent call last):
  File "/usr/lib/python3.6/urllib/request.py", line 1318, in do_open
    encode_chunked=req.has_header('Transfer-encoding'))
  File "/usr/lib/python3.6/http/client.py", line 1254, in request
    self._send_request(method, url, body, headers, encode_chunked)
  File "/usr/lib/python3.6/http/client.py", line 1300, in _send_request
    self.endheaders(body, encode_chunked=encode_chunked)
  File "/usr/lib/python3.6/http/client.py", line 1249, in endheaders
    self._send_output(message_body, encode_chunked=encode_chunked)
  File "/usr/lib/python3.6/http/client.py", line 1036, in _send_output
    self.send(msg)
  File "/usr/lib/python3.6/http/client.py", line 974, in send
    self.connect()
  File "/usr/lib/python3.6/http/client.py", line 1407, in connect
    super().connect()
  File "/usr/lib/python3.6/http/client.py", line 946, in connect
    (self.host,self.port), self.timeout, self.source_address)
  File "/usr/lib/python3.6/socket.py", line 724, in create_connection
    raise err
  File "/usr/lib/python3.6/socket.py", line 713, in create_connection
    sock.connect(sa)
OSError: [Errno 101] Network is unreachable

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/usr/local/lib/python3.6/dist-packages/youtube_dl/YoutubeDL.py", line 1919, in process_info
    partial_success = dl(fname, new_info)
  File "/usr/local/lib/python3.6/dist-packages/youtube_dl/YoutubeDL.py", line 1864, in dl
    return fd.download(name, info)
  File "/usr/local/lib/python3.6/dist-packages/youtube_dl/downloader/common.py", line 366, in download
    return self.real_download(filename, info_dict)
  File "/usr/local/lib/python3.6/dist-packages/youtube_dl/downloader/http.py", line 341, in real_download
    establish_connection()
  File "/usr/local/lib/python3.6/dist-packages/youtube_dl/downloader/http.py", line 109, in establish_connection
    ctx.data = self.ydl.urlopen(request)
  File "/usr/local/lib/python3.6/dist-packages/youtube_dl/YoutubeDL.py", line 2237, in urlopen
    return self._opener.open(req, timeout=self._socket_timeout)
  File "/usr/lib/python3.6/urllib/request.py", line 526, in open
    response = self._open(req, data)
  File "/usr/lib/python3.6/urllib/request.py", line 544, in _open
    '_open', req)
  File "/usr/lib/python3.6/urllib/request.py", line 504, in _call_chain
    result = func(*args)
  File "/usr/local/lib/python3.6/dist-packages/youtube_dl/utils.py", line 2724, in https_open
    req, **kwargs)
  File "/usr/lib/python3.6/urllib/request.py", line 1320, in do_open
    raise URLError(err)
urllib.error.URLError: <urlopen error [Errno 101] Network is unreachable>

Description
All attempts to download videos from YouTube (I haven't tried other sites...I don't use this application for anything else) start for a few seconds and then stall out.  Previous similar issues are seemingly blamed on the users' internet connection, whereas I don't have any connectivity issues whatsoever.  This only started happening within the last 48 hours or so.
I previously had an older version of youtube-dl, but updated to 2019.11.22 this morning, and still have this issue.
Previous suggestions seem to be:

set up a Caching DNS Resolver.  (No idea what this is or how I would do such a thing - if it solves the issue, though, I'm more than happy to try if someone can explain it to me)
run youtube-dl in until loop (seems to get the job done....eventually - would like something that fixes the issue rather than a workaround that somewhat ignores the foundational problem)

I'm more than happy to provide any other troubleshooting information requested.  Thanks in advance for any help you can offer.  Love the project, and if I were in a position to donate/contribute to it, I certainly would, but unfortunately I'm not in that position :(

Most likely intermittent network issue on your side.

Most likely intermittent network issue on your side.

Well like I said, I don't seem to have any connectivity issues outside of this.  Do you have any suggestions on what I can do to troubleshoot or confirm this "intermittent" issue if it exists?
Appreciate your taking the time to respond :+1:

I don't seem to have any connectivity issues outside of this

How did you check that? Have you even run pings along with downloading to check there is no loss or Network is unreachable errors?

I've run a ping -c 20 youtube.com which didn't seem to show any loss:
--- youtube.com ping statistics ---
20 packets transmitted, 20 received, 0% packet loss, time 19027ms
rtt min/avg/max/mdev = 29.241/30.077/31.470/0.678 ms

Have you read my message at all?

run pings along with downloading

Have you read my message at all?

run pings along with downloading

I apologize if I misunderstood...If you mean trying to use youtube-dl while pinging in another terminal concurrently, yes, I have.  There still is no loss reported....the Network is unreachable error still occurs in youtube-dl, but not in the ping
If I'm still misunderstanding, again, I apologize.
ping youtube.com
PING youtube.com (<IP_ADDRESS>) 56(84) bytes of data.
64 bytes from ord30s26-in-f238.1e100.net (<IP_ADDRESS>): icmp_seq=1 ttl=51 time=45.5 ms
64 bytes from ord30s26-in-f238.1e100.net (<IP_ADDRESS>): icmp_seq=2 ttl=51 time=52.4 ms
64 bytes from ord30s26-in-f238.1e100.net (<IP_ADDRESS>): icmp_seq=3 ttl=51 time=43.8 ms
64 bytes from ord30s26-in-f238.1e100.net (<IP_ADDRESS>): icmp_seq=4 ttl=51 time=27.6 ms
64 bytes from ord30s26-in-f238.1e100.net (<IP_ADDRESS>): icmp_seq=5 ttl=51 time=33.0 ms
64 bytes from ord30s26-in-f238.1e100.net (<IP_ADDRESS>): icmp_seq=6 ttl=51 time=30.2 ms
64 bytes from ord30s26-in-f238.1e100.net (<IP_ADDRESS>): icmp_seq=7 ttl=51 time=68.3 ms
64 bytes from ord30s26-in-f238.1e100.net (<IP_ADDRESS>): icmp_seq=8 ttl=51 time=65.5 ms
64 bytes from ord30s26-in-f238.1e100.net (<IP_ADDRESS>): icmp_seq=9 ttl=51 time=29.6 ms
64 bytes from ord30s26-in-f238.1e100.net (<IP_ADDRESS>): icmp_seq=10 ttl=51 time=29.9 ms
64 bytes from ord30s26-in-f238.1e100.net (<IP_ADDRESS>): icmp_seq=11 ttl=51 time=29.3 ms
64 bytes from ord30s26-in-f238.1e100.net (<IP_ADDRESS>): icmp_seq=12 ttl=51 time=30.8 ms
64 bytes from ord30s26-in-f238.1e100.net (<IP_ADDRESS>): icmp_seq=13 ttl=51 time=29.3 ms
64 bytes from ord30s26-in-f238.1e100.net (<IP_ADDRESS>): icmp_seq=14 ttl=51 time=29.6 ms
64 bytes from ord30s26-in-f238.1e100.net (<IP_ADDRESS>): icmp_seq=15 ttl=51 time=29.7 ms
64 bytes from ord30s26-in-f238.1e100.net (<IP_ADDRESS>): icmp_seq=16 ttl=51 time=30.2 ms
64 bytes from ord30s26-in-f238.1e100.net (<IP_ADDRESS>): icmp_seq=17 ttl=51 time=30.9 ms
64 bytes from ord30s26-in-f238.1e100.net (<IP_ADDRESS>): icmp_seq=18 ttl=51 time=29.8 ms
64 bytes from ord30s26-in-f238.1e100.net (<IP_ADDRESS>): icmp_seq=19 ttl=51 time=30.0 ms
64 bytes from ord30s26-in-f238.1e100.net (<IP_ADDRESS>): icmp_seq=20 ttl=51 time=29.7 ms
64 bytes from ord30s26-in-f238.1e100.net (<IP_ADDRESS>): icmp_seq=21 ttl=51 time=29.9 ms
64 bytes from ord30s26-in-f238.1e100.net (<IP_ADDRESS>): icmp_seq=22 ttl=51 time=30.3 ms
64 bytes from ord30s26-in-f238.1e100.net (<IP_ADDRESS>): icmp_seq=23 ttl=51 time=30.5 ms
64 bytes from ord30s26-in-f238.1e100.net (<IP_ADDRESS>): icmp_seq=24 ttl=51 time=29.6 ms
64 bytes from ord30s26-in-f238.1e100.net (<IP_ADDRESS>): icmp_seq=25 ttl=51 time=29.4 ms
64 bytes from ord30s26-in-f238.1e100.net (<IP_ADDRESS>): icmp_seq=26 ttl=51 time=29.9 ms
64 bytes from ord30s26-in-f238.1e100.net (<IP_ADDRESS>): icmp_seq=27 ttl=51 time=29.9 ms
64 bytes from ord30s26-in-f238.1e100.net (<IP_ADDRESS>): icmp_seq=28 ttl=51 time=30.3 ms
64 bytes from ord30s26-in-f238.1e100.net (<IP_ADDRESS>): icmp_seq=29 ttl=51 time=28.8 ms
64 bytes from ord30s26-in-f238.1e100.net (<IP_ADDRESS>): icmp_seq=30 ttl=51 time=29.7 ms
64 bytes from ord30s26-in-f238.1e100.net (<IP_ADDRESS>): icmp_seq=31 ttl=51 time=29.7 ms
64 bytes from ord30s26-in-f238.1e100.net (<IP_ADDRESS>): icmp_seq=32 ttl=51 time=30.2 ms
64 bytes from ord30s26-in-f238.1e100.net (<IP_ADDRESS>): icmp_seq=33 ttl=51 time=39.7 ms
64 bytes from ord30s26-in-f238.1e100.net (<IP_ADDRESS>): icmp_seq=34 ttl=51 time=30.0 ms
64 bytes from ord30s26-in-f238.1e100.net (<IP_ADDRESS>): icmp_seq=35 ttl=51 time=29.1 ms
64 bytes from ord30s26-in-f238.1e100.net (<IP_ADDRESS>): icmp_seq=36 ttl=51 time=29.5 ms
64 bytes from ord30s26-in-f238.1e100.net (<IP_ADDRESS>): icmp_seq=37 ttl=51 time=29.6 ms
64 bytes from ord30s26-in-f238.1e100.net (<IP_ADDRESS>): icmp_seq=38 ttl=51 time=30.2 ms
64 bytes from ord30s26-in-f238.1e100.net (<IP_ADDRESS>): icmp_seq=39 ttl=51 time=29.3 ms
64 bytes from ord30s26-in-f238.1e100.net (<IP_ADDRESS>): icmp_seq=40 ttl=51 time=29.9 ms
64 bytes from ord30s26-in-f238.1e100.net (<IP_ADDRESS>): icmp_seq=41 ttl=51 time=29.8 ms
64 bytes from ord30s26-in-f238.1e100.net (<IP_ADDRESS>): icmp_seq=42 ttl=51 time=29.6 ms
64 bytes from ord30s26-in-f238.1e100.net (<IP_ADDRESS>): icmp_seq=43 ttl=51 time=29.5 ms
64 bytes from ord30s26-in-f238.1e100.net (<IP_ADDRESS>): icmp_seq=44 ttl=51 time=30.1 ms
64 bytes from ord30s26-in-f238.1e100.net (<IP_ADDRESS>): icmp_seq=45 ttl=51 time=29.5 ms
64 bytes from ord30s26-in-f238.1e100.net (<IP_ADDRESS>): icmp_seq=46 ttl=51 time=29.7 ms
64 bytes from ord30s26-in-f238.1e100.net (<IP_ADDRESS>): icmp_seq=47 ttl=51 time=29.9 ms
64 bytes from ord30s26-in-f238.1e100.net (<IP_ADDRESS>): icmp_seq=48 ttl=51 time=29.5 ms
64 bytes from ord30s26-in-f238.1e100.net (<IP_ADDRESS>): icmp_seq=49 ttl=51 time=30.1 ms
64 bytes from ord30s26-in-f238.1e100.net (<IP_ADDRESS>): icmp_seq=50 ttl=51 time=29.9 ms
64 bytes from ord30s26-in-f238.1e100.net (<IP_ADDRESS>): icmp_seq=51 ttl=51 time=32.0 ms
64 bytes from ord30s26-in-f238.1e100.net (<IP_ADDRESS>): icmp_seq=52 ttl=51 time=29.6 ms
64 bytes from ord30s26-in-f238.1e100.net (<IP_ADDRESS>): icmp_seq=53 ttl=51 time=29.8 ms
64 bytes from ord30s26-in-f238.1e100.net (<IP_ADDRESS>): icmp_seq=54 ttl=51 time=29.3 ms
64 bytes from ord30s26-in-f238.1e100.net (<IP_ADDRESS>): icmp_seq=55 ttl=51 time=29.4 ms
64 bytes from ord30s26-in-f238.1e100.net (<IP_ADDRESS>): icmp_seq=56 ttl=51 time=28.8 ms
64 bytes from ord30s26-in-f238.1e100.net (<IP_ADDRESS>): icmp_seq=57 ttl=51 time=28.5 ms
64 bytes from ord30s26-in-f238.1e100.net (<IP_ADDRESS>): icmp_seq=58 ttl=51 time=29.1 ms
64 bytes from ord30s26-in-f238.1e100.net (<IP_ADDRESS>): icmp_seq=59 ttl=51 time=29.0 ms
64 bytes from ord30s26-in-f238.1e100.net (<IP_ADDRESS>): icmp_seq=60 ttl=51 time=31.7 ms
64 bytes from ord30s26-in-f238.1e100.net (<IP_ADDRESS>): icmp_seq=61 ttl=51 time=28.9 ms
64 bytes from ord30s26-in-f238.1e100.net (<IP_ADDRESS>): icmp_seq=62 ttl=51 time=29.8 ms
64 bytes from ord30s26-in-f238.1e100.net (<IP_ADDRESS>): icmp_seq=63 ttl=51 time=29.3 ms
64 bytes from ord30s26-in-f238.1e100.net (<IP_ADDRESS>): icmp_seq=64 ttl=51 time=30.2 ms
64 bytes from ord30s26-in-f238.1e100.net (<IP_ADDRESS>): icmp_seq=65 ttl=51 time=29.6 ms
64 bytes from ord30s26-in-f238.1e100.net (<IP_ADDRESS>): icmp_seq=66 ttl=51 time=30.2 ms
64 bytes from ord30s26-in-f238.1e100.net (<IP_ADDRESS>): icmp_seq=67 ttl=51 time=29.8 ms
64 bytes from ord30s26-in-f238.1e100.net (<IP_ADDRESS>): icmp_seq=68 ttl=51 time=30.1 ms
64 bytes from ord30s26-in-f238.1e100.net (<IP_ADDRESS>): icmp_seq=69 ttl=51 time=28.8 ms
64 bytes from ord30s26-in-f238.1e100.net (<IP_ADDRESS>): icmp_seq=70 ttl=51 time=29.3 ms
64 bytes from ord30s26-in-f238.1e100.net (<IP_ADDRESS>): icmp_seq=71 ttl=51 time=29.6 ms
64 bytes from ord30s26-in-f238.1e100.net (<IP_ADDRESS>): icmp_seq=72 ttl=51 time=29.1 ms
64 bytes from ord30s26-in-f238.1e100.net (<IP_ADDRESS>): icmp_seq=73 ttl=51 time=29.1 ms
64 bytes from ord30s26-in-f238.1e100.net (<IP_ADDRESS>): icmp_seq=74 ttl=51 time=29.0 ms
64 bytes from ord30s26-in-f238.1e100.net (<IP_ADDRESS>): icmp_seq=75 ttl=51 time=29.2 ms
64 bytes from ord30s26-in-f238.1e100.net (<IP_ADDRESS>): icmp_seq=76 ttl=51 time=29.5 ms
64 bytes from ord30s26-in-f238.1e100.net (<IP_ADDRESS>): icmp_seq=77 ttl=51 time=29.3 ms
64 bytes from ord30s26-in-f238.1e100.net (<IP_ADDRESS>): icmp_seq=78 ttl=51 time=29.2 ms
64 bytes from ord30s26-in-f238.1e100.net (<IP_ADDRESS>): icmp_seq=79 ttl=51 time=30.2 ms
64 bytes from ord30s26-in-f238.1e100.net (<IP_ADDRESS>): icmp_seq=80 ttl=51 time=30.2 ms
64 bytes from ord30s26-in-f238.1e100.net (<IP_ADDRESS>): icmp_seq=81 ttl=51 time=29.8 ms
64 bytes from ord30s26-in-f238.1e100.net (<IP_ADDRESS>): icmp_seq=82 ttl=51 time=29.1 ms
64 bytes from ord30s26-in-f238.1e100.net (<IP_ADDRESS>): icmp_seq=83 ttl=51 time=29.8 ms
64 bytes from ord30s26-in-f238.1e100.net (<IP_ADDRESS>): icmp_seq=84 ttl=51 time=31.0 ms
64 bytes from ord30s26-in-f238.1e100.net (<IP_ADDRESS>): icmp_seq=85 ttl=51 time=29.8 ms
64 bytes from ord30s26-in-f238.1e100.net (<IP_ADDRESS>): icmp_seq=86 ttl=51 time=29.0 ms
64 bytes from ord30s26-in-f238.1e100.net (<IP_ADDRESS>): icmp_seq=87 ttl=51 time=29.0 ms
64 bytes from ord30s26-in-f238.1e100.net (<IP_ADDRESS>): icmp_seq=88 ttl=51 time=29.0 ms
64 bytes from ord30s26-in-f238.1e100.net (<IP_ADDRESS>): icmp_seq=89 ttl=51 time=29.5 ms
64 bytes from ord30s26-in-f238.1e100.net (<IP_ADDRESS>): icmp_seq=90 ttl=51 time=30.0 ms
64 bytes from ord30s26-in-f238.1e100.net (<IP_ADDRESS>): icmp_seq=91 ttl=51 time=30.8 ms
64 bytes from ord30s26-in-f238.1e100.net (<IP_ADDRESS>): icmp_seq=92 ttl=51 time=31.0 ms
64 bytes from ord30s26-in-f238.1e100.net (<IP_ADDRESS>): icmp_seq=93 ttl=51 time=30.5 ms
64 bytes from ord30s26-in-f238.1e100.net (<IP_ADDRESS>): icmp_seq=94 ttl=51 time=33.1 ms
64 bytes from ord30s26-in-f238.1e100.net (<IP_ADDRESS>): icmp_seq=95 ttl=51 time=32.1 ms
64 bytes from ord30s26-in-f238.1e100.net (<IP_ADDRESS>): icmp_seq=96 ttl=51 time=32.7 ms
64 bytes from ord30s26-in-f238.1e100.net (<IP_ADDRESS>): icmp_seq=97 ttl=51 time=30.4 ms
64 bytes from ord30s26-in-f238.1e100.net (<IP_ADDRESS>): icmp_seq=98 ttl=51 time=31.9 ms
64 bytes from ord30s26-in-f238.1e100.net (<IP_ADDRESS>): icmp_seq=99 ttl=51 time=30.3 ms
64 bytes from ord30s26-in-f238.1e100.net (<IP_ADDRESS>): icmp_seq=100 ttl=51 time=31.9 ms
64 bytes from ord30s26-in-f238.1e100.net (<IP_ADDRESS>): icmp_seq=101 ttl=51 time=31.5 ms
64 bytes from ord30s26-in-f238.1e100.net (<IP_ADDRESS>): icmp_seq=102 ttl=51 time=31.2 ms
64 bytes from ord30s26-in-f238.1e100.net (<IP_ADDRESS>): icmp_seq=103 ttl=51 time=32.4 ms
64 bytes from ord30s26-in-f238.1e100.net (<IP_ADDRESS>): icmp_seq=104 ttl=51 time=30.3 ms
64 bytes from ord30s26-in-f238.1e100.net (<IP_ADDRESS>): icmp_seq=105 ttl=51 time=32.0 ms
64 bytes from ord30s26-in-f238.1e100.net (<IP_ADDRESS>): icmp_seq=106 ttl=51 time=31.5 ms
64 bytes from ord30s26-in-f238.1e100.net (<IP_ADDRESS>): icmp_seq=107 ttl=51 time=30.5 ms
64 bytes from ord30s26-in-f238.1e100.net (<IP_ADDRESS>): icmp_seq=108 ttl=51 time=32.0 ms
64 bytes from ord30s26-in-f238.1e100.net (<IP_ADDRESS>): icmp_seq=109 ttl=51 time=31.6 ms
64 bytes from ord30s26-in-f238.1e100.net (<IP_ADDRESS>): icmp_seq=110 ttl=51 time=31.8 ms
64 bytes from ord30s26-in-f238.1e100.net (<IP_ADDRESS>): icmp_seq=111 ttl=51 time=30.6 ms
64 bytes from ord30s26-in-f238.1e100.net (<IP_ADDRESS>): icmp_seq=112 ttl=51 time=30.8 ms
64 bytes from ord30s26-in-f238.1e100.net (<IP_ADDRESS>): icmp_seq=113 ttl=51 time=30.7 ms
64 bytes from ord30s26-in-f238.1e100.net (<IP_ADDRESS>): icmp_seq=114 ttl=51 time=30.9 ms
64 bytes from ord30s26-in-f238.1e100.net (<IP_ADDRESS>): icmp_seq=115 ttl=51 time=30.8 ms
64 bytes from ord30s26-in-f238.1e100.net (<IP_ADDRESS>): icmp_seq=116 ttl=51 time=30.9 ms
64 bytes from ord30s26-in-f238.1e100.net (<IP_ADDRESS>): icmp_seq=117 ttl=51 time=30.8 ms
64 bytes from ord30s26-in-f238.1e100.net (<IP_ADDRESS>): icmp_seq=118 ttl=51 time=32.1 ms
64 bytes from ord30s26-in-f238.1e100.net (<IP_ADDRESS>): icmp_seq=119 ttl=51 time=31.8 ms
64 bytes from ord30s26-in-f238.1e100.net (<IP_ADDRESS>): icmp_seq=120 ttl=51 time=30.7 ms
64 bytes from ord30s26-in-f238.1e100.net (<IP_ADDRESS>): icmp_seq=121 ttl=51 time=31.0 ms
64 bytes from ord30s26-in-f238.1e100.net (<IP_ADDRESS>): icmp_seq=122 ttl=51 time=31.9 ms
64 bytes from ord30s26-in-f238.1e100.net (<IP_ADDRESS>): icmp_seq=123 ttl=51 time=31.8 ms
64 bytes from ord30s26-in-f238.1e100.net (<IP_ADDRESS>): icmp_seq=124 ttl=51 time=30.8 ms
64 bytes from ord30s26-in-f238.1e100.net (<IP_ADDRESS>): icmp_seq=125 ttl=51 time=30.9 ms
64 bytes from ord30s26-in-f238.1e100.net (<IP_ADDRESS>): icmp_seq=126 ttl=51 time=30.2 ms
64 bytes from ord30s26-in-f238.1e100.net (<IP_ADDRESS>): icmp_seq=127 ttl=51 time=32.1 ms
64 bytes from ord30s26-in-f238.1e100.net (<IP_ADDRESS>): icmp_seq=128 ttl=51 time=30.5 ms
64 bytes from ord30s26-in-f238.1e100.net (<IP_ADDRESS>): icmp_seq=129 ttl=51 time=31.0 ms
64 bytes from ord30s26-in-f238.1e100.net (<IP_ADDRESS>): icmp_seq=130 ttl=51 time=29.6 ms
64 bytes from ord30s26-in-f238.1e100.net (<IP_ADDRESS>): icmp_seq=131 ttl=51 time=31.1 ms
64 bytes from ord30s26-in-f238.1e100.net (<IP_ADDRESS>): icmp_seq=132 ttl=51 time=32.0 ms
64 bytes from ord30s26-in-f238.1e100.net (<IP_ADDRESS>): icmp_seq=133 ttl=51 time=31.7 ms
64 bytes from ord30s26-in-f238.1e100.net (<IP_ADDRESS>): icmp_seq=134 ttl=51 time=30.8 ms
64 bytes from ord30s26-in-f238.1e100.net (<IP_ADDRESS>): icmp_seq=135 ttl=51 time=30.2 ms
64 bytes from ord30s26-in-f238.1e100.net (<IP_ADDRESS>): icmp_seq=136 ttl=51 time=32.2 ms
64 bytes from ord30s26-in-f238.1e100.net (<IP_ADDRESS>): icmp_seq=137 ttl=51 time=30.5 ms
64 bytes from ord30s26-in-f238.1e100.net (<IP_ADDRESS>): icmp_seq=138 ttl=51 time=32.5 ms
64 bytes from ord30s26-in-f238.1e100.net (<IP_ADDRESS>): icmp_seq=139 ttl=51 time=31.8 ms
64 bytes from ord30s26-in-f238.1e100.net (<IP_ADDRESS>): icmp_seq=140 ttl=51 time=31.9 ms
64 bytes from ord30s26-in-f238.1e100.net (<IP_ADDRESS>): icmp_seq=141 ttl=51 time=31.8 ms
64 bytes from ord30s26-in-f238.1e100.net (<IP_ADDRESS>): icmp_seq=142 ttl=51 time=30.8 ms
64 bytes from ord30s26-in-f238.1e100.net (<IP_ADDRESS>): icmp_seq=143 ttl=51 time=31.5 ms
64 bytes from ord30s26-in-f238.1e100.net (<IP_ADDRESS>): icmp_seq=144 ttl=51 time=31.9 ms
64 bytes from ord30s26-in-f238.1e100.net (<IP_ADDRESS>): icmp_seq=145 ttl=51 time=31.3 ms
64 bytes from ord30s26-in-f238.1e100.net (<IP_ADDRESS>): icmp_seq=146 ttl=51 time=32.0 ms
64 bytes from ord30s26-in-f238.1e100.net (<IP_ADDRESS>): icmp_seq=147 ttl=51 time=30.6 ms
64 bytes from ord30s26-in-f238.1e100.net (<IP_ADDRESS>): icmp_seq=148 ttl=51 time=32.1 ms
64 bytes from ord30s26-in-f238.1e100.net (<IP_ADDRESS>): icmp_seq=149 ttl=51 time=31.2 ms
64 bytes from ord30s26-in-f238.1e100.net (<IP_ADDRESS>): icmp_seq=150 ttl=51 time=32.0 ms
64 bytes from ord30s26-in-f238.1e100.net (<IP_ADDRESS>): icmp_seq=151 ttl=51 time=31.7 ms
64 bytes from ord30s26-in-f238.1e100.net (<IP_ADDRESS>): icmp_seq=152 ttl=51 time=30.7 ms
64 bytes from ord30s26-in-f238.1e100.net (<IP_ADDRESS>): icmp_seq=153 ttl=51 time=30.9 ms
64 bytes from ord30s26-in-f238.1e100.net (<IP_ADDRESS>): icmp_seq=154 ttl=51 time=30.7 ms
64 bytes from ord30s26-in-f238.1e100.net (<IP_ADDRESS>): icmp_seq=155 ttl=51 time=31.2 ms
64 bytes from ord30s26-in-f238.1e100.net (<IP_ADDRESS>): icmp_seq=156 ttl=51 time=31.9 ms
64 bytes from ord30s26-in-f238.1e100.net (<IP_ADDRESS>): icmp_seq=157 ttl=51 time=30.5 ms
64 bytes from ord30s26-in-f238.1e100.net (<IP_ADDRESS>): icmp_seq=158 ttl=51 time=32.1 ms
64 bytes from ord30s26-in-f238.1e100.net (<IP_ADDRESS>): icmp_seq=159 ttl=51 time=30.5 ms
64 bytes from ord30s26-in-f238.1e100.net (<IP_ADDRESS>): icmp_seq=160 ttl=51 time=31.0 ms
^C
--- youtube.com ping statistics ---
160 packets transmitted, 160 received, 0% packet loss, time 159155ms
rtt min/avg/max/mdev = 27.653/31.315/68.347/4.812 ms

You should ping host you're downloading from not youtube.com.

You should ping host you're downloading from not youtube.com.

So would this be the domain that shows shows in the [debug] Invoking downloader on 'https..... line?
(Again...I apologize profusely for my ignorance here, and I greatly appreciate the fact that you're taking the time to help)

Correct.

Correct.

Okay...if I ping with just the domain (googlevideo.com) while attempting to download I get the following result
--- googlevideo.com ping statistics ---
316 packets transmitted, 315 received, 0% packet loss, time 315384ms
rtt min/avg/max/mdev = 25.352/33.660/78.595/8.561 ms

If I include the subdomain (r6---sn-p5qs7nel.googlevideo.com):
PING r6.sn-p5qs7nel.googlevideo.com (<IP_ADDRESS>) 56(84) bytes of data.
^C
--- r6.sn-p5qs7nel.googlevideo.com ping statistics ---
206 packets transmitted, 0 received, 100% packet loss, time 209941ms

So I guess that means I can't find the subdomain, but I don't have any clue as to where to go from that point.

I don't know if this means/indicates anything, but I ran a traceroute on the r6---sn-p5qs7nel.googlevideo.com URL, and it finds it...but it doesn't replace the --- with a . like ping seems to be doing.  (ping did that whether I just entered the URL, or put it in single or double quotes)
traceroute r6---sn-p5qs7nel.googlevideo.com
traceroute to r6---sn-p5qs7nel.googlevideo.com (<IP_ADDRESS>), 30 hops max, 60 byte packets
 1  _gateway (<IP_ADDRESS>)  0.966 ms  0.939 ms  0.907 ms
 2  <IP_ADDRESS> (<IP_ADDRESS>)  3.270 ms  2.951 ms  3.241 ms
 3  <IP_ADDRESS> (<IP_ADDRESS>)  16.016 ms  14.845 ms  15.110 ms
 4  * * *
 5  be26.clhgohcc01r.midwest.rr.com (<IP_ADDRESS>)  22.222 ms  20.706 ms  21.864 ms
 6  be14.clevohek02r.midwest.rr.com (<IP_ADDRESS>)  23.040 ms  23.265 ms  19.393 ms
 7  be25.clevohek01r.midwest.rr.com (<IP_ADDRESS>)  22.900 ms  22.638 ms  20.551 ms
 8  bu-ether17.vinnva0510w-bcr00.tbone.rr.com (<IP_ADDRESS>)  30.959 ms  24.937 ms so-7-1-0.ar0.dca10.tbone.rr.com (<IP_ADDRESS>)  23.495 ms
 9  bu-ether11.asbnva1611w-bcr00.tbone.rr.com (<IP_ADDRESS>)  25.459 ms  23.235 ms  29.730 ms
10  <IP_ADDRESS> (<IP_ADDRESS>)  27.035 ms  39.828 ms *
11  ix-ae-17-0.tcore1.aeq-ashburn.as6453.net (<IP_ADDRESS>)  29.081 ms  35.044 ms ix-ae-17-0.tcore2.aeq-ashburn.as6453.net (<IP_ADDRESS>)  21.932 ms
12  <IP_ADDRESS> (<IP_ADDRESS>)  35.298 ms if-ae-2-2.tcore1.aeq-ashburn.as6453.net (<IP_ADDRESS>)  27.853 ms  36.149 ms
13  <IP_ADDRESS> (<IP_ADDRESS>)  26.629 ms  28.080 ms <IP_ADDRESS> (<IP_ADDRESS>)  36.389 ms
14  <IP_ADDRESS> (<IP_ADDRESS>)  36.368 ms  29.150 ms  21.243 ms
15  <IP_ADDRESS> (<IP_ADDRESS>)  20.358 ms <IP_ADDRESS> (<IP_ADDRESS>)  22.819 ms <IP_ADDRESS> (<IP_ADDRESS>)  22.314 ms

#23213 related I believe

#23213 related I believe

Yes, it is related.
I have similar issue like @SlidingHorn. It has following symptoms:

On my desktop in browser Youtube does at first 2 requests to https://r2---sn-nav85oxu-cunl.googlevideo.com/blabla (wrong) after which opens https://r2---sn-2gb7sn7r.googlevideo.com/blabla and video can be played (downloaded).

YTDL (version 2020.05.03) generates link with subdomain https://r2---sn-nav85oxu-cunl.googlevideo.com/blabla (wrong) and after a while ends with [Errno 101] Network is unreachable message.

When I change internet provider (use mobile connection) YTDL works and downloads video from https://r2---sn-nf5o-cunl.googlevideo.com/blabla (new working subdomain).

From remote device video can be downloaded with no problems. YTDL has version 2019.11.22.

When I paste raw video link generated with desktop YTDL https://r2---sn-nav85oxu-cunl.googlevideo.com/blabla (wrong) directly to desktop browser it timeouts after a while. No automatic redirect from Google.

When I paste raw video link generated with desktop YTDL https://r2---sn-nav85oxu-cunl.googlevideo.com/blabla (wrong) directly to remote console (wget 'link') it automatically redirects to new subdomain and downloads.

redirector.googlevideo.com/blabla on desktop returns https://r2---sn-nf5o-cunl.googlevideo.com/blabla (wrong) and redirector.googlevideo.com/blabla on remote device returns https://r2---sn-cgovpm-cg9e.googlevideo.com.

When I change download link (new video) on my desktop, YTDL downloads it without problems.

Video cannot be downloaded only over my primary personal IP address. Can be downloaded with new IP address or on remote device. NOTE: I have no option to test issue from another machine within same network (IP or UA issue). From Youtube-dl developer point of view, it is hard to debug (repeat issue).
Conclusion:
Youbube blocks ability to download certain (politically sensitive) videos for certain users until downloader doesn't simulate browser environment.
I don't understand this Youtube behavior. They are only forcing me to created better downloading solution (proxing, etc) since in "account has been deleted" era I simply want my personal archive.

#23213 related I believe

Yes, it is related.
I have similar issue like @SlidingHorn. It has following symptoms:

On my desktop in browser Youtube does at first 2 requests to https://r2---sn-nav85oxu-cunl.googlevideo.com/blabla (wrong) after which opens https://r2---sn-2gb7sn7r.googlevideo.com/blabla and video can be played (downloaded).

YTDL (version 2020.05.03) generates link with subdomain https://r2---sn-nav85oxu-cunl.googlevideo.com/blabla (wrong) and after a while ends with [Errno 101] Network is unreachable message (76% packet loss).

When I change internet provider (use mobile connection) YTDL works and downloads video from https://r2---sn-nf5o-cunl.googlevideo.com/blabla (new working subdomain).

From remote device video can be downloaded with no problems. YTDL has version 2019.11.22.

When I paste raw video link generated with desktop YTDL https://r2---sn-nav85oxu-cunl.googlevideo.com/blabla (wrong) directly to desktop browser it timeouts after a while. No automatic redirect from Google.

When I paste raw video link generated with desktop YTDL https://r2---sn-nav85oxu-cunl.googlevideo.com/blabla (wrong) directly to remote console (wget 'link') it automatically redirects to new subdomain and downloads.

redirector.googlevideo.com/blabla on desktop returns https://r2---sn-nf5o-cunl.googlevideo.com/blabla (wrong) and redirector.googlevideo.com/blabla on remote device returns https://r2---sn-cgovpm-cg9e.googlevideo.com.

When I change download link (new video) on my desktop, YTDL downloads it without problems.

Video cannot be downloaded only over my primary personal IP address. Can be downloaded with new IP address or on remote device. NOTE: I have no option to test issue from another machine within same network (IP or UA issue). From Youtube-dl developer point of view, it is hard to debug (repeat issue).
I don't understand this behavior. It's only forcing me to created better downloading solution (proxing, etc) since in "account has been deleted" era I simply want my personal archive.


Add a placeholder dependabot-core.gemspec

While auditing our gems, I noticed there was a dependabot-core gem that hadn't been updated in years: https://rubygems.org/gems/dependabot-core/versions/0.94.13
This was probably the original gem before it was all split apart into the meta gem dependabot-omnibus and the subgems.
This creates confusion because the name matches the dependabot-core repo.
At first I planned to delete it, but then I saw the note on Rubygems that deleting a gem frees up the namespace. We would much rather own this namespace to prevent namesquatting, so I've created a placeholder gemspec that has no associated source code.
I wasn't sure if gem would allow building/publishing with no source code, so tested, and it all worked:
$ gem build dependabot-core.gemspec
WARNING:  no files specified
WARNING:  description and summary are identical
WARNING:  See https://guides.rubygems.org/specification-reference/ for help
  Successfully built RubyGem
  Name: dependabot-core
  Version: 0.95.1
  File: dependabot-core-0.95.1.gem
$ gem push dependabot-core-0.95.1.gem
Pushing gem to https://rubygems.org...
Successfully registered gem: dependabot-core (0.95.1)

You can see the updated gem here: https://rubygems.org/gems/dependabot-core/versions/0.95.1
Which is much less confusing than it used to be.
I think we should keep the gemspec around in case anyone needs to make small changes at some point, no need for them to recreate the whole file.
This repo seemed like the best fit, I wasn't sure whether to float it in ./common, so I stuck it in the root dir... seems harmless enough.
Fix https://github.com/dependabot/dependabot-core/issues/6993

Great find!


reset_index does not keep attributes

If an indexing coordinate with attributes is converted to a non indexing coordinate with reset_index, the attributes are lost. I am not sure it is a bug, but I think they should keep the attributes and reset_coords does keep the attributes of reset coordinates.
MCVE Code Sample

temp = 15 + 8 * np.random.randn(2, 2, 3)
time = xr.DataArray(pd.date_range('2014-09-06', periods=3), dims=["time"]).assign_attrs({"attr": 23})
coord = xr.DataArray([[-99.83, -99.32], [-99.79, -99.23]], dims=["x", "y"]).assign_attrs({"coord": True})

ds = xr.Dataset(
    {
        'temperature': (['x', 'y', 'time'],  temp),
    },
    coords={
        'coord_0': coord,
        'time': time,
    }
)
ds
# both coord_0 and time have attributes

ds.reset_index("time")
# coordinate time_ does not have attributes anymore

ds.reset_coords("coord_0")
# data variable coord_0 still has attributes

Expected Output
I would expect attributes to be kept.
Possible solution
I was wondering if changing this line and this other line to
vars_to_create[str(d) + "_"] = Variable(d, index, variables[d].attrs)

could solve this. If so I'll send a PR whenever I can.
 A PR would be welcome.


Allow "android.attached" to accept an array of "adbName" for parallelisation

Is your feature request related to a problem? Please describe.
I want to be able to run parallel tests on multiple attached Android devices (e.g. Genymotion). Currently, the android.attached configuration type accepts only one adbName.
Describe the solution you'd like
The android.attached configuration type to accept an array of adbName's.
Describe alternatives you've considered
I don't see any reason why the logic from src/devices/drivers/EmulatorDriver.js regarding acquireFreeDevice cannot be applied to src/devices/drivers/AttachedAndroidDriver.js. I copied and slightly modified the this.deviceRegistry.allocateDevice call and added a cleanup phase for this.deviceRegistry.disposeDevice(adbName). Worked like a charm.
P.S. I can create a pull request if that helps.

Created a PR https://github.com/wix/Detox/pull/2169


Rename slimevr gui artifact to slimevr.exe

Should work now thanks to help by @ImUrX

closes https://github.com/SlimeVR/SlimeVR-Server/pull/358