Explore storing FATE data in the metadata table

FATE operations store their data in zookeeper.  This is ok when FATE is used for a relatively low volume of operations.  However in #3462 a use case arose where using FATE to commit compactions would have been nice however it was deemed that commiting compactions would be too high volume for zookeeper.  So as part of #3462 a simple ~refresh metadata section was created to ensure that tablet refresh happens after compaction commit even when the process dies between commit and refresh.  This is similar in functionality to FATE, but much simpler and more specialized.  Using FATE for this use case would be nice as it would reduce custom code in Accumulo.
The ~refresh entry introduced as part of #3462 is stored in ZK, root table, or metadata table depending on the tablet that is committing a compaction.  Could FATE data be stored in a similar way, could the following be done?

For root table and system FATE operations, store the FATE data in ZK
For metadata table FATE operations, store the FATE data in the root table
For user table FATE operations, store the FATE data in the metadata table

Currently many FATE operations are tightly coupled to table locks.  These would also need to be stored in the metadata table, not sure if these could be done using conditional mutations. That is an example of something that could cause problems for this strategy.
The benefit of this change is it would open FATE up for more use cases and would place less memory and write pressure on zookeeper for current use cases.  However if #3462 is the only use case that needs this, it may not be worthwhile.
Another possible use case that could benefit from this is from #3382 where system initiated splits are now executed as FATE operations.  However system initiated splits would not normally cause the sustained high levels of metadata activity that compactions would.  System initiated splits could cause burst of metadata activity that would place a lot of write and memory pressure on ZK.  For example if a table decides all of its tablets need to split around the same time.
Also wondering if this could help with making multiple manager possible by making it easier to partition the FATE operations and data.
The purpose of this issue is to decided if this is workable and worthwhile.

User compaction are currently driven by a fate operation, however those create ZK node that scale with the number of compaction request coming in via the API.  User compactions do not create ZK nodes for each tablet in a compaction request.  For example if a user initiated compaction has range that covers 100K tablets, then it will create a few ZK nodes but not N*100K ZK nodes.   The compaction commit process in #3462 is a pert tablet operation, so for it to use FATE it would need to create a FATE operation per a tablet.  This is why it was deemed too much for ZK.

You tagged this with the elasticity project, but it seems to me that this could be an independent development effort. It doesn't seem strictly tied to the elasticity effort. Though, that effort would benefit from it. This could be done as an independent intermediate step towards the elasticity effort, rather than as something tightly coupled and interdependent on it.
Also, related to this idea, there was an idea to change the serialization of Fate storage to use Java 17 record types. That doesn't impact where we store the data... just how it's serialized when we do store it. But, if somebody were to work on this, they could take that proposed change into account, if they had to change how things were serialized to use the metadata table.

Also, related to this idea, there was an idea to change the serialization of Fate storage to use Java 17 record types.

No, but that sounds really nice.
Also something unrelated is prioritization of FATE operations.  This is also driven by elasticity.  Currently the system initiated split FATE operations are mixed in with user initated FATE ops.  Ideally the user initiated operations would get some sort of priority.  If FATE ops were stored in the metadata table, then maybe the schema could naturally support prioritization and/or different queues in its sort order.

@ctubbsii I think using records for serialization deserves its own issue if it does not have one.

Taking a quick look at how table locks work currently I think they may work as conditional mutations.  The table locks do not use ephemeral nodes or notifications, features that on ZK would have. Fate threads will try to get a lock and if they can not then jump to another fate operation, so they never wait for a lock which could use ZK notifications.  This polling approach would work with conditional mutations.  The lock nodes in ZK are related to a FATE operation and not a running process, that is why ephemeral nodes are not used.  The server process locks in ZK use ephemeral nodes.

Bulk may benefit from this feature as it would allow Fate ops driving bulk imports for user tables to be stored in the metadata table.  For any system with lots of bulk imports, this would take pressure off of ZK.

@ctubbsii I think using records for serialization deserves its own issue if it does not have one.

It was mentioned on https://github.com/apache/accumulo/issues/2473#issuecomment-1033230922, which is an overarching issue about refactoring FATE. This issue and that one probably overlap a lot, as they are both very high level and not clear on details. There may be smaller bits that can be separated out and worked on independently. However, I don't want to create any new issues, given that there's already 2 broadly themed ones, and it's not clear what the path forward is going to be. I think the ideas between the two tickets need to be thought through, so a clear design can be proposed. At that point, it might make sense to create sub-issues to track the individual tasks as part of working towards the overall goal.
Another thing to consider: we have a whole accumulo.* namespace. If the metadata isn't appropriate, then it's possible another table in that namespace could be... as long as we don't create any bootstrapping issues between which tables come online first.

This issue and that one probably overlap a lot, as they are both very high level and not clear on details.

I think this issue is very narrowly defined, its about making FATEs storage more scalable so that FATE can be used more frequently than it is currently used.  Below are the details and background.

All writes to zookeeper must go through a single server with a single write ahead log and then be pushed to a quorum of other servers.  Therefore writes to ZK are not scalable (ZK is more scalable on the read side).
FATE operations can be write heavy ZK operations.  This could negatively impact the general health of ZK on which accumulo depends for ZKs more scalable read functionality.
The metadata table is much more scalable for writes as each tabletserver has its own walog and metadata tablets scan span many tablet servers.
Using the metadata table for storage of FATE would increase the number of FATE operations that could execute concurrently and reduce the general write load on ZK.
Making FATE storage more scalable would open it up to being used for operations that it is currently not suitable for like per tablet compaction commit.  Making the fate storage more scalable may help improve user operations like bulk import at scale also.

In addition to walog scalability, using the metadata table as storage for fate operations is also more scalable in terms of memory usage.  Everything stored in ZK must be able to fit in memory on a single machine.  Storing data in the metadata table does not have this constraint, but it can leverage much much more memory for caching data across many tservers.

I have started looking into this and have started thinking about a schema design for storing FATE. @keith-turner talked offline and one option is to actually store FATE data its own table vs metadata which might be cleaner

@ctubbsii - You had mentioned in an earlier comment doing this as an independent effort outside of elasticity but @keith-turner had some good points of why this might be better to do as part of Elasticity. I've only just begin to look at this issue and still trying to figure out what all is involved here so he could probably explain better the reasons. (Maybe Keith can respond here or it can be discussed on slack/dev list etc.). Mostly I just wanted to bring it up as now that I am starting to look into this it would be good to get onto the same page as to what part of the work is being targeted at main vs elasticity to avoid any issues down the road.

The following are reasons why I think it makes sense to do this in elasticity.

With the adoption of using conditional mutations in elasticity we may be able able to get rid if table locks.  See #3823.  If table locks are not removed, then supporting FATE using the metadata table for storage would mean table locks also need to support the metadata table.  Table locks are currently stored in zookeeper.  So implementing this in main and merging to elasticity may mean implementing tables locks in the metadata table and then throwing that work away on merge.
The needs for storing FATE operations in the metadata table is being able to do per tablet operations in FATE like the compaction use case described in this issue and #3560 and #3526.  These use cases are not present in main.

@cshannon, In general, I prefer to keep features as independent as possible. I think this is good development practice, and results in more modular code design, which is easier to maintain. It also helps with release and feature planning when things aren't so co-dependent and tightly coupled. I'm fine with targeting elasticity, though, if the benefits of doing so are substantial.
On the two points @keith-turner mentioned:

The conditional mutation work isn't done yet, nor is the removal of table locks, but that's also a feature that could be done outside of the elasticity branch (possibly). It's also possible that conditional mutations can be used for this feature, without the other work in the metadata tables using conditional mutations yet, since conditional mutations are a per-write feature, not a per-table feature. I agree that there's a good chance that this may be easier or save some work by starting in the elasticity branch, because of how it relates to those things, but right now, I think this is all very speculative, as there are so many things in flight. I think think it's worth considering those things, but also making an effort to think of how it can be done independently, as the exploration of this feature proceeds.
The use cases for this may primarily exist in the elasticity branch, but that's not an argument against doing this incrementally with some progress in the main branch. If the dependency is one way, there's no reason we couldn't make some incremental changes in the main branch that is utilized more heavily later. Right now, I think it's too early to say what that might look like, since this is still at an exploratory stage.

I'm okay with starting the exploration in elasticity branch, but please consider putting in some effort to make things modular and work towards incremental progress, wherever possible. If it doesn't strictly need to be implemented in the elasticity branch, I'd prefer it not be. I'd much rather make incremental progress in the main branch than dump everything into elasticity, with an all-or-nothing approach... if we can help it (we might not be able to help it... it may still make sense to bundle it all in elasticity, and if so, I'll accept that... I just don't think it's inevitable yet).


feat(PLAYWRIGHT_VERSION): added build argument to specify version

feat(PLAYWRIGHT_VERSION): added build argument to specify version
fix(Dockerfile): fixed warnings "FromAsCasing: 'as' and 'FROM' keywords' casing do not match

NOTE: this also fixes issue with global playwright-core mismatch server app playwright-core for whatever reason (cache, npm package updated while build, etc)

LGTM! Thanks.
I don't remember why, but I think adding the edge channel is because some dependency was only available there before.
I'll add the version mismatch notice in the README.


Sparse Merkle Trees (SMTs) designs

SSZ for general purpose merkleization is lacking a few types, of which sparse merkle trees are probably the most different from what is already there.
It only passed by a few times in the specs:

lists merkleization discussion 1115
multi-proof queries 644
lists/vectors, and the desire for a future sparse vector variant 1160

However I do think it is necessary to have if SSZ is to be adopted more widely than the current spec state machines.
Options
There is not one way to implement this, we have many options:

With breaking changes:

Back to specialized trees like Merkle Patricia Trees, at the cost of complexity and hard to optimize structures/merkleization
Hack in extension nodes in the otherwise binary tree
Change of hash function for efficient merges with zeroes, but have to maintain some information in the hash, a byte or two: https://ethresear.ch/t/a-nearly-trivial-on-zero-inputs-32-bytes-long-collision-resistant-hash-function/5511

No breaking changes, but full hashing (large proof size problem, slow on-chain):

Compress proof data, but do the full-depth hashes: https://ethresear.ch/t/optimizing-sparse-merkle-trees/3751/12
Plasma cash SMTs, bitfield to refer where zero hashes are: https://ethresear.ch/t/plasma-cash-with-sparse-merkle-trees-bloom-filters-and-probabilistic-transfers/2006

Merkleize based on prefix difference (with vector commitment problem):

Preserve position by hashing in the key into each leaf ("Compressed merkle proofs"): https://github.com/aergoio/aergo/tree/master/pkg/trie

Similarities with the "1 hash extra" case I described in the list discussion: harden leaf nodes to then put them anywhere easily.
Also called Compact Merkle Trees, with "split index" for point of divergence, assuming unique leaf nodes, no precise vector commitment. https://ethresear.ch/t/compact-sparse-merkle-trees/3741/16
"Binary Indexed Tree": like above, but with max distance between nodes to navigate: https://github.com/ChosunOne/merkle_bit

Purposefully forget about positions in favor of fast sparse set merkleization, the "Merklix" (Merkle + radix) tree: https://www.deadalnix.me/2016/09/24/introducing-merklix-tree-as-an-unordered-merkle-tree-on-steroid/
Libra sparse compact merkle tree: make leaf nodes different by typing them

"jellyfish merkle" implementation: https://github.com/libra/libra/tree/master/storage/jellyfish-merkle
https://developers.libra.org/docs/assets/papers/the-libra-blockchain.pdf

"Secure Merkle trees must use different hash functions to hash the leaves and internal nodes to avoid confusion between the two types of nodes."

New idea (or thought experiment, not efficient, but new possibilities): Compact merkle tree with special mixin at root, see below. Separating the vector commitment from the contents commitment, while preserving some other properties with affinity for SSZ in the contents commitment.

More suggestions welcome, it is hard to aggregate it all.

Opinion
Personally I dislike breaking changes here, and feel like those solutions are too specialized, hard to optimize or simply too incompatible with other parts of the spec.
The full hashing is also something I like to avoid, 256 hashes is computationally unacceptable, even with proof encoding compression (something proof backings should be optimizing, not sparse merkle trees).

By all means, do tear the new idea apart, there are many options and discussion is welcome.

Another possible variant of the compact sparse merkle trees, to make it work somewhat with generalized indices, and define two missing sparse data structures:
We define a MerkleSet[T], MerkleMap[K, V] and generalized index annotations.
MerkleSet[T]: Take the hash-tree-root of each element, this will be the identity in the set.
The set is merkleized as a compact tree, with each element in the position determined by its hash-tree-root, but each element is wrapped with a right-hand zero to mark it as a leaf element. H(obj_T, 0x000...)
MerkleMap[K, V]: As a MerkleSet[T], where each element is positioned by just the hash-tree-root of K, but is merkleized as H(H(V, K), 0x000...) (incl the right-hand-zeroes as leaf marker).
Now, to access a set or map value with a stable generalized index we need the generalized index to know where to stop and look for a 0x000... right hand in the tree.
A generalized index could be like:
0x1aaaa...aaaabbbb...bbbbcccc...cccc
aaaa...aaaa: some regular generalized index path, anything, leading to the root of the set or map.
bbbb...bbbb: 32 bytes key embedded. (set value hash-tree-root, or map key hash-tree-root)
cccc...cccc: path within the value

And then add an annotation like "at bit index i a 32 byte key can be found, follow this path like normal, but stop and skip to the end of the 32 byte key once a right-hand zeroed node is encountered".
And to work with for the MerkleMap encoding, define a second type of annotation, exactly like the first, but with an addition: "the 32 byte key must match the next right child node" (i.e. in the pair left from the zeroes).
Such annotation could be just an index, maybe 2 bytes with the first bit reserved to describe the map case (2**15 = 32768 max merkle depth).
And one modification could be made to consider the hash with zeroes (H(e, 0x000...)) as the identity, instead of the element itself. Making the content keys uniform.
The pro of not doing this would be that keys can be chosen (and made uniform manually with a hash if necessary), and more readable in the generalized index.

As I am implementing a merkle-tree backing and typed views/partials in Go I'm starting to be a fan of single-node mixins. I.e. A mix-in like the list length is not opt-out: it's always part of a proof about the data. You are forced into the right direction, enabled to check in every case, and deal with less edge cases.
Similarly the zeroes as stopper for the sparse tree work well, they are always part of the proof data.
Maybe the flexibility and super-compatibility (with regular ssz merkle trees) offered by the content-vector commitment separation is still worth it, but it will be much more difficult to enforce to use it properly.

Edited this out of the main-post. It is a complementary idea to the compact trees that has some efficiency problems (2x proof size of individual leaf), but offers some fun new possibilities. Think of it as a thought-experiment to complete the picture of the different compact merkle trees.

The idea of compact sparse merkle trees has been re-hashed (no pun intended 🤔) by many authors, but I think gets close to fitting our needs. (ignoring stable merkle depth for a moment here). Let's just explore another variant.
Compact tree affinity
One thing that is particularly striking is that prefixes just fit well with binary trees and our generalized indices:

1, 100, 1000000, etc are all exclusive: cannot represent them as leafs in the same sparse compact tree (unless you define splits over depth differences too). Aligning it to the left is no problem. E.g.<PHONE_NUMBER> ... 0000 can be a key.
Always starts with a 1, we can special case something that starts with a 0 when we merkleize this type of info.
If we do not mess the with leaf nodes, every current SSZ merkle structure is a valid sparse merkle tree!

vector commitment issue: positions are ignored by the sparse merkle tree. But the SSZ structures embedded here would have a static shape anyway.

Vector commitment mixin
Now take a look at SSZ lists:

Positional information is mixed in at the root, not per leaf. It's just that lists are not very complex, but it could be anything. And it is convenient for proofs to have this basic vector commitment: "elements 0...N are here"
Only when the vector commitment changes, the mix-in changes.

Now this new idea is to do the same for sparse trees: separate the vector commitment, and call it the "sparse tree mixin".
And this vector commitment can be a compact sparse tree of keys, optimized exactly the same way.
And since the vector commitment may not change as much (well, in some cases it does, in others never at all), an extra hash for an update there wouldn't be as bad.
So in the vector commitment, we take the "1 extra hash" to separate leafs (the actual keys) from hashes. And this hash can be 000...0000 as positions all start with 1 and can't collide with the zeroes. Nor should a random hash.
Also note that the contents part would back the values and the vector part would back the keys of the data-structure. And membership commitment depends on what you are after: content inclusion can be proven with just the values part, identity inclusion can be proven with just the keys part.
And now that the vector commitment can be summarized into 32 bytes, and the contents commitment part is compatible with regular SSZ trees, we can have really interesting type-less but safe tree interactions:
E.g. a BeaconState can be explored as a sparse tree, by just mixing in (to the regular BeaconState root) a constant magic 32 bytes derived from its type definition to convert a regular root into that of a valid sparse tree.
Another special property is that moving a value by just a little (slight key alternation) may only change the keys commitment part.
Compactness vs Stable depth
The remaining problem here is that compactness on a sparse structure cannot be achieved without breaking the stable depth. A generalized index to an actual sparse tree leaf cannot be derived without knowing about the contents of the tree. On the bright side, the separation of the vector commitment makes this easy to learn and communicate.
The compactness gets us O(log(N)) node depth for N nodes with uniformly distributed tree keys.
This compactness applies to both the values as the keys part of the tree.
And the compactness still puts adjacent keys close together efficiently, if a sparse tree is used for non-uniform data it is perfectly fine. (bit bigger proof size, but not much more than a regular List would do, and fast computation)
Drawbacks
size: If the only use case is to both proof the key and value at the same time, and the tree changes a lot, it would be ~2x more data (separate key and value proofs) compared to regular compact trees that harden the leaf nodes with a position. The total amount of nodes may be comparable still, but the 2x is especially noticeable when proofing

Out of all the options I think I like leaf-level mixins the most. The main challenge (really, with any of these schemes except my modified hash function proposal) is that generalized indices would not work because the path for any given object would be dynamic. I would suggest we just bite the bullet and in objects that contain sets/dicts we just require a path to consist of a generalized index (that pretends every key is the full 256 bits) along with a second object that is a list of pairs (depth of dict root, depth of leaf relative to root). Note that this list would need to be dynamically generated and passed along with each proof.
From this list of pairs, you can translate the generalized index into a "modified generalized index" (basically, the bit positions corresponding to levels that were elided in the tree get snipped out of the generalized index), and generate a list of mixin checks ("check that the value at generalized index x is y").

Instead of transforming the generalized indices, and then still having to pass the information to check the keys, we could also mark the "anchor points" with generalized indices:
Say, for some type there is a SMT with its root anchored at 0b10010011, then it would be sufficient to pass that to the multiproof checker. The checker can check if it is in this subtree, and if so, check that the 32 bytes after this prefix in the gindex of a SMT leaf match the key part of the SMT leaf. (Assuming we standardize on 32 byte keys, and hash-tree-root if the actual key is bigger).
And this data would be the same for every entry in the sparse merkle tree: no need to duplicate it for each leaf in that subtree under the SMT anchor. And if regular SMTs are not nested very deep into the type of the proof as whole, this SMT anchor gindex only costs a few bytes. Negligible compared to the size of a single leaf node.

What do you think about AVL+ trees?

@Tolsi Here is my view, primarily focused on how compact trees compare. I probably missed a few things, but will do a proper full read when I have more time.

Observation  1:   Use  Tree-Balancing  Operations  that  Stay  on  Path

If single-node branches are already reduced to just the node itself, and keys are random and uniform, I do not think rebalancing is helpful. It is more like another way to compress a set of leafs into a binary looking tree, just with more edge-cases an optimized merkleization implementation has to deal with. A compact tree of N leafs has an avg. leaf depth of O(log(N) which is fine. And no re-hashing of anything else than on the branch of a modified leaf.

Observation 2:  Do Not Hash Internal Keys

we do not add the  keys  of  internal  nodes
the verifier does not need to know how  the  leaf  was  found

There do not have to be internal keys indeed; if you already key the leafs, the internal nodes just have to reach them indeed, and be able to verify the leaf corresponds to some key. And IMHO it is much better if it is intuitive and simple: walk the path of the key until you find the key. Rather than determine your path based on the entire contents of the tree. All of this may end up in a every-op-counts smartcontract. And although the verifier does not need to know where the leaf was found, being able to quickly locate and read/write a leaf in a proof is important.

Observation 3:  Skip Lists are Just a Variant of Treaps

Another thing with SSZ is to keep optimized tree descriptions separate from merkleization: new use-cases and algorithms will keep emerging. Merkleization should just be fast, minimal and straightforward. The lookup tricks and tree description can be provided alongside the proof. A "backing" is a representation that implements the merkle proof tree traversal needs, and optimizes reads/writes/etc. as it likes. Tree-rotation is something too much (ssz trees are static and predictable, and we hope SMTs can be nearly-statically described), but skip lists etc. can be part of the "backing". E.g. you can optimize lookups without moving nodes perfectly fine. See tree-offsets described here: https://github.com/protolambda/eth-merkle-trees

Observation 4:  Deterministic is Better.
However,  since inserted keys may be influenced by the adversary, this method of generating randomness may give an attacker the ability to make the data structure very slow and the proofs very long

Yes, deterministic structures and values are better. A SSZ SMT should hash to the same root regardless of tree constructor or insertion order.
Regarding determinism in compact trees: I do think choosing keys is not so much of a problem: keys are already hashes of other data (with the exception of basic keys, see below). And because of the compacting property (a branch stops at a single node, no extra depth), the only real attack surface is to insert a large amount of keys, or lots of keys with the same prefix (which is exponentially hard the longer the prefix is, so only effectively adds a few hashes).
For MerkleSet[A] or MerkleMap[A, X] of A a basic type or Bytes32, the user can pick a MerkleMap[K, V], where K = Hash(A). Chosen consecutive basic keys are not that bad either: keys are little-endian and so the prefix should differ immediately for regular use of basic keys 0 ... N has a minimal amount of common prefixes. However, if you try to use e.g. a range of 2**240 ... 2**240 + N as your keys, then yes, the common prefix is 240 bits long and the proof gets very large. Hash your keys, or avoid such arbitrary range. We can try to optimize out this common prefix, but the user can handle this exceptional case themselves, and I do not like some type of extension-nodes as in Merkle Patricia Trees: breaking otherwise viable optimizations and dealing with them in every single proof is not worth it. I may reconsider this if we get numbers on possible attacks and just the random birthday-like chance of a tree leaf key sharing a long common prefix with another.

Observation 5:  AVL Trees Outperform on the Most Relevant Parameters
the worst-case distance [for leafs when inserting many random keys] for AVL trees is 1.44 times the optimal

We should run some numbers on compact trees, but I don't expect this worst case to occur very often with uniform keys.

Observation 6:  Proofs for Multiple Operations Can Be Compressed.

As with any multi-merkle-proof? Providing just the leaf nodes, and witness data that can't be constructed from lower witness-data and leaves is relatively easy. There is some (naive but readable) pseudo code here: multiproofs. Compression of the actual description of the tree is then a responsibility of the "backing", replaceable later.

Implementation and Evaluation

Impressed by the amount of analysis in the paper, but prefer simplicity and closer affinity with the general binary merkle spec. The MerkleSet and MerkleMap are just a discussion thing for now, before anything gets standardized proposals, simulations and review will be done.

Say, for some type there is a SMT with its root anchored at 0b10010011, then it would be sufficient to pass that to the multiproof checker. The checker can check if it is in this subtree, and if so, check that the 32 bytes after this prefix in the gindex of a SMT leaf match the key part of the SMT leaf. (Assuming we standardize on 32 byte keys, and hash-tree-root if the actual key is bigger).

Ah, I was thinking of the case where the SMT is fully embedded into the SSZ suite, so you could have the SMT be an element of other structures, other structures be an element of the SMT, etc, with possibly multiple SMTs in one path. Yes, if you have a gindex for just an SMT leaf from its own root then that is sufficient.

Right, for each SMT anchor (start of the tree, i.e. the SMT root) in an SSZ structure you would need to declare it's an SMT to get the special traversal behavior. But nothing extra depending on SMT contents. And it's just the anchor to be described if we standardize on 32 byte SMT keys. (Take hash-tree-root of key).

You would also need to specify the length of the branches. Otherwise if you just provide a branch it's not clear what part is supposed to go down to the leaf and what part is doing something further after that leaf. One possible case to think about would be a direct 2-level SMT (ie. an SMT of SMTs); you need to declare where the first one ends and the second begins.

Well, you don't need an end and start I think, just the anchors of each SMT: if you have the start (anchor) info of both SMTs, and you traverse the first one, you can skip 256 bits of gindex after this first anchor. Navigate the SMT till you hit the bottom (zero right hand, or 256 gindex bits all consumed), check the key (against the skipped 256 bits), and then continue reading the remaining part of the gindex to navigate deeper. Which could be into the next deeper SMT, anchored at higher SMT anchor ++ its SMT 256 bit position ++ optional in-between SMTs navigation. (++ is generalized index concat). It's not pretty, but still minimal enough imo.

Navigate the SMT till you hit the bottom (zero right hand

Ah, are we assuming that the leaf in an SMT is (0, real_leaf)? Then where would the key go?

I was thinking (and described it in MerkleMap/MerkleSet) for a map it the bottom would be like H(H(htr(V), htr(K)), 0). First you break traversal on the 0 (as full 0 is not a natural hash of any kv pair). Then you check the key one level deeper (but to the left). And for a set you can say that H(V) is the position to check, and you don't need a K.

@protolambda What's the status on this issue? Do you still want to push it forward?

@JustinDrake Yes, but it simply is not required right now for phase0, and not impossible to implement in addition to what we currently have. So I'm alright with keeping this open for now, and focusing on the network/testnet problems. If anyone is not working on testnets and wants to give this another look, maybe a new proposal, I'm happy to review it though.

Hi @protolambda
I am the author of Compact sparse merkle trees (https://ethresear.ch/t/compact-sparse-merkle-trees/3741)
Unfortunately I could not find time for the past 2 years to do some follow up work on this but now I do thanks to the current world situation.
I'm not familiar with Ethereum's internals and what exactly are Ethereum's requirement in relation to this, could you please point me to a document where the broad requirements for using a Sparse merkle tree for Ethereum are listed.
Thanks


Receiving an empty list when using RecordFilterStrategy on batch messages

Discussed in https://github.com/spring-projects/spring-kafka/discussions/2805

Originally posted by m-hetz September 11, 2023
Hi!
I'm using RecordFilterStrategy to filter records based on headers. This works great on single messages, the filter works and records don't  reach the listener (annotated with @KafkaListener).
When using batch mode, filtering also works but when the entire batch is filtered, the listener is invoked with an empty list.
Is this expected behavior? According to this  when returning an empty list all records are filtered
Is there a way to configure it not to reach the listener at all? (on an empty bulk)
Thanks!
val filter = object : RecordFilterStrategy<String, String> {
    override fun filter(consumerRecord: ConsumerRecord<String, String>): Boolean {
        val header = consumerRecord.headers().lastHeader("SKIP")
        if (header != null) {
            logger.info("Filtering header=" + consumerRecord.key())
            return true
        }
        return false
    }

    override fun filterBatch(records: MutableList<ConsumerRecord<String, String>>): MutableList<ConsumerRecord<String, String>> {
        val iterator: MutableIterator<ConsumerRecord<String, String>> = records.iterator()

        while (iterator.hasNext()) {
            if (this.filter(iterator.next())) {
                iterator.remove()
            }
        }
        if (records.size > 0) return records
        return mutableListOf()
    }
}
factory.setBatchListener(isBatchListener)
factory.setRecordFilterStrategy(filter)

@KafkaListener(topics = ["topic"], containerFactory = "messageContainerFactory")
fun listener(messages: List<ConsumerRecord<String, String?>>,
) {

    logger.info("Consuming messages, batch size=${messages.size}")
}

Sorry for the unformatted code, I tried editing the message but the code is still messed up

Hi, @artembilan.
I'm interested in solving this issue.
		if (consumerRecords.size() > 0 || consumerAware
				|| (!this.ackDiscarded && this.delegateType.equals(ListenerType.ACKNOWLEDGING))) {
			invokeDelegate(consumerRecords, acknowledgment, consumer);
		}

Why we should consider consumerAware type even if consumerRecords.size() == 0?
		if (!filter(consumerRecord)) {
			switch (this.delegateType) {
				case ACKNOWLEDGING_CONSUMER_AWARE -> this.delegate.onMessage(consumerRecord, acknowledgment, consumer);
				case ACKNOWLEDGING -> this.delegate.onMessage(consumerRecord, acknowledgment);
				case CONSUMER_AWARE -> this.delegate.onMessage(consumerRecord, consumer);
				case SIMPLE -> this.delegate.onMessage(consumerRecord);
			}
		}
		else {
			ackFilteredIfNecessary(acknowledgment);
		}

In a not batch mode, if record are filtered, MessageListenerAdapter does not care about at all.
Thus, what do you think like this?
                 // Fix Here. consumerRecords.size() should be grater than 0.
		if ((consumerRecords.size() > 0) && (consumerAware
				|| (!this.ackDiscarded && this.delegateType.equals(ListenerType.ACKNOWLEDGING)))) {
			invokeDelegate(consumerRecords, acknowledgment, consumer);
		}
                // And then, consumerRecords.size() == 0, ackFilteredIfNecessary!
		else {
			if (this.ackDiscarded && acknowledgment != null) {
				acknowledgment.acknowledge();
			}
		}

If it is okay to you, i'll make PR to contribute.
What do you think?

@chickenchickenlove You can go ahead and work on a PR. Then, we can review the details. Keep in mind that we are already in an RC state with 3.2.0. Therefore, any new enhancements like these must wait for the 3.3.0 version.


Building Android with EAS Build, the build fails due to Gradle with Bugsnag

Describe the bug
When  I try to run EAS build on Android, I'm getting this error message.
`Running 'gradlew :app:bundleRelease' in /home/expo/workingdir/build/android
Downloading https://services.gradle.org/distributions/gradle-7.5.1-all.zip
10%
20%.
30
%.
40%
50
%.
60%.
70%.
80%.
90
%.
100%
Welcome to Gradle 7.5.1!
Here are the highlights of this release:

Support for Java 18
Support for building with Groovy 4
Much more responsive continuous builds
Improved diagnostics for dependency resolution
For more details see https://docs.gradle.org/7.5.1/release-notes.html
To honour the JVM settings for this build a single-use Daemon process will be forked. See https://docs.gradle.org/7.5.1/userguide/gradle_daemon.html#sec:disabling_the_daemon.
Daemon will be stopped at the end of the build

Task :react-native-gradle-plugin:pluginDescriptors
Task :react-native-gradle-plugin:processResources
Task :react-native-gradle-plugin:compileKotlin
w: /home/expo/workingdir/build/node_modules/react-native-gradle-plugin/src/main/kotlin/com/facebook/react/ReactExtension.kt: (10, 37): 'BaseVariant' is deprecated. Deprecated in Java
w: /home/expo/workingdir/build/node_modules/react-native-gradle-plugin/src/main/kotlin/com/facebook/react/ReactExtension.kt: (119, 30): 'BaseVariant' is deprecated. Deprecated in Java
w: /home/expo/workingdir/build/node_modules/react-native-gradle-plugin/src/main/kotlin/com/facebook/react/ReactExtension.kt: (135, 26): 'BaseVariant' is deprecated. Deprecated in Java
w: /home/expo/workingdir/build/node_modules/react-native-gradle-plugin/src/main/kotlin/com/facebook/react/ReactExtension.kt: (157, 32): 'BaseVariant' is deprecated. Deprecated in Java
w: /home/expo/workingdir/build/node_modules/react-native-gradle-plugin/src/main/kotlin/com/facebook/react/ReactExtension.kt: (163, 31): 'BaseVariant' is deprecated. Deprecated in Java
w: /home/expo/workingdir/build/node_modules/react-native-gradle-plugin/src/main/kotlin/com/facebook/react/ReactExtension.kt: (171, 36): 'BaseVariant' is deprecated. Deprecated in Java
w: /home/expo/workingdir/build/node_modules/react-native-gradle-plugin/src/main/kotlin/com/facebook/react/ReactPlugin.kt: (114, 48): 'reactRoot: DirectoryProperty' is deprecated. reactRoot was confusing and has been replace with root to point to your root project and reactNativeDir to point to the folder of the react-native NPM package
w: /home/expo/workingdir/build/node_modules/react-native-gradle-plugin/src/main/kotlin/com/facebook/react/TaskConfiguration.kt: (10, 37): 'ApplicationVariant' is deprecated. Deprecated in Java
w: /home/expo/workingdir/build/node_modules/react-native-gradle-plugin/src/main/kotlin/com/facebook/react/TaskConfiguration.kt: (11, 37): 'BaseVariant' is deprecated. Deprecated in Java
w: /home/expo/workingdir/build/node_modules/react-native-gradle-plugin/src/main/kotlin/com/facebook/react/TaskConfiguration.kt: (12, 37): 'LibraryVariant' is deprecated. Deprecated in Java
w: /home/expo/workingdir/build/node_modules/react-native-gradle-plugin/src/main/kotlin/com/facebook/react/TaskConfiguration.kt: (27, 51): 'BaseVariant' is deprecated. Deprecated in Java
w: /home/expo/workingdir/build/node_modules/react-native-gradle-plugin/src/main/kotlin/com/facebook/react/TaskConfiguration.kt: (130, 12): 'ApplicationVariant' is deprecated. Deprecated in Java
w: /home/expo/workingdir/build/node_modules/react-native-gradle-plugin/src/main/kotlin/com/facebook/react/TaskConfiguration.kt: (131, 12): 'LibraryVariant' is deprecated. Deprecated in Java
w: /home/expo/workingdir/build/node_modules/react-native-gradle-plugin/src/main/kotlin/com/facebook/react/TaskConfiguration.kt: (251, 14): 'BaseVariant' is deprecated. Deprecated in Java
Task :react-native-gradle-plugin:compileJava NO-SOURCE
Task :react-native-gradle-plugin:classes
Task :react-native-gradle-plugin:inspectClassesForKotlinIC
Task :react-native-gradle-plugin:jar
[stderr]
FAILURE: Build failed with an exception.
[stderr]

Where:
[stderr]
Build file '/home/expo/workingdir/build/android/app/build.gradle' line: 375
[stderr]
What went wrong:
[stderr]
A problem occurred evaluating project ':app'.
[stderr]

Failed to apply plugin 'com.bugsnag.android.gradle'.
[stderr]
Using com.bugsnag.android.gradle:8+ with Android Gradle Plugin < 8 is not supported. Either upgrade the Android Gradle Plugin to 8, or use an earlier version of the BugSnag Gradle Plugin. For more information about this change, see https://docs.bugsnag.com/build-integrations/gradle/
[stderr]

Try:
[stderr]

Run with --stacktrace option to get the stack trace.
[stderr]
Run with --info or --debug option to get more log output.
[stderr]
Run with --scan to get full insights.
[stderr]

Get more help at https://help.gradle.org
[stderr]
BUILD FAILED
[stderr]
in 1m 40s
5 actionable tasks: 5 executed
Error: Gradle build failed with unknown error. See logs for the "Run gradlew" phase for more information.`

I tried removing bugsnag package from my project, and the build works.
I have also tried downgrading bugsnag package to version 44 ( this is my last project version before bumping up Expo SDK) and the build works.
It seems like expo build is on SDK 47 is using Gradle 7.5.1.
My project have these dependencies from bugsnag:
"@bugsnag/expo": "^47.0.0",
"@bugsnag/plugin-expo-eas-sourcemaps": "^47.0.0",
"@bugsnag/source-maps": "^2.3.1",
Steps to reproduce
Im not sure to report to expo or bugsnag but since the error seems like caused by bugsnag specifically, I decided to report here instead.
Environment

Bugsnag version: 47.0.0 & 47.1.0 (tried both)
Expo SDK version (e.g. SDK 44): SDK47
OS:  Android

I guess worth also mentioning that when I build on Android with the same package version on Dec 2022, the build works.
Im not sure why bugsnag expect gradle version 8.

Update: the build works when remove @bugsnag/plugin-expo-eas-sourcemaps package. My guess is that it expect Gradle 8 as per the error.

@amalasyrafs - I just ran into the same issue today. It's due to a new release of the gradle plugin.
At least for local AS builds (using expo prebuild), I was able to tweak it
        dependencies {
            classpath 'com.bugsnag:bugsnag-android-gradle-plugin:[7.4.1]'
        }

instead of
        dependencies {
            classpath 'com.bugsnag:bugsnag-android-gradle-plugin:[7.3.0,)'
        }

The solution here it try to patch the config plugin locally so that EAS builds work as well.

Yea, I fixed the bugsnag gradle plug-in version to the latest before Gradle 8. Below the patch package. My build on EAS was successful. I feel like the config plug-in should be updated to protect against this breaking change. At least make it a configurable param to opt-in to use gradle 8. @lemnik what do you think?
diff --git<EMAIL_ADDRESS><EMAIL_ADDRESS>index 5f6279c..b23a06a 100644
---<EMAIL_ADDRESS>+++<EMAIL_ADDRESS>@@ -52,7 +52,7 @@ function injectDependencies (script) {
             mavenCentral()
         }
         dependencies {
-            classpath 'com.bugsnag:bugsnag-android-gradle-plugin:[7.3.0,)'
+            classpath 'com.bugsnag:bugsnag-android-gradle-plugin:[7.4.1]'
         }
     }

Nevermind - already fixed - https://github.com/bugsnag/bugsnag-expo/releases - strange that it didn't pull this in automatically since it's a patch version change.

Yeah it was fixed with the patch and I manage to create a build on Android again.
But your patch also helped a lot.
Thanks @thorbenprimke . I was able to learn something new today.

Hi all - thanks for raising this with us. As discussed above, this was caused by a beta release of our support for Android Gradle Plugin v8.
The fix has been released for all versions of Expo we currently maintain support for and ensures that this won't happen again for future v8 releases of the BugSnag Android Gradle Plugin. The issue also doesn't impact earlier versions of bugsnag-expo (i.e. v44 and below).

https://github.com/bugsnag/bugsnag-expo/releases/tag/v47.1.1
https://github.com/bugsnag/bugsnag-expo/releases/tag/v46.0.3
https://github.com/bugsnag/bugsnag-expo/releases/tag/v45.1.3

@luke-belton can you please publish 47.1.1 to npm?

Hi @lucasklaassen - thanks for raising this with us. We're working on getting all of the above releases published on npm (currently only v45.1.3 is available). We'll update this thread when they're available.

@lucasklaassen This only required an update to @bugsnag/plugin-expo-eas-sourcemaps where v47.1.1 is already on npm
@bugsnag/expo itself did not change, so there's no corresponding version on npm
So to update you only need to bump the version of @bugsnag/plugin-expo-eas-sourcemaps to v47.1.1


Prevent accidental double-boxing of StreamReadFailed errors

Since the inner stream already wraps the error in StreamReadFailed, there’s no need to do it again.

Not to suggest that we shouldn't fix this (I agree the way it's been implemented is pretty funky), but I want to note that this isn't quite doing the same thing as before. Before we would get something like StreamReadFailed(StreamSizeExceeded) whereas with this we would only get StreamSizeExceeded.  This seems better to me, but it might (?) be a breaking change.

Merged in https://github.com/rousan/multer-rs/commit/3940c4a09724b84debcac9694b7666450fa25123. Thank you!


2024 view test

What problem were solved in this pull request?
description: description
issue number: close #xxx
What is changed and how it works?
Other information
score: 10
pass:

current_work

result:

#46
您好，create view 是特意没合到主分支的，在总结里提了下


194: Add network plugin support

Overview
This PR includes the following proposed change(s):

New context that provides network information
Added a footer bar to display network information

This isn't necessarily the only place to show it, but is working first pass.

Added titles to the tabs (they show up in the browser tab)
Updated some div to Box, in keeping with material-ui style.

Moved some css from useStyles into the inline settings of the Box component

Updated initConfig to keycloakConfig just for readability
Misc updates/tweaks

Type of change

[ ] Bug fix (non-breaking change which fixes an issue)
[x] New feature (non-breaking change which adds functionality)
[ ] Refactoring / Documentation
[ ] Version change

if your change is a breaking change, please add breaking change label to this PR
How Has This Been Tested?
Locally.  The main change is the addition of the network context which works (and is simple).
More testing will be needed to ensure the larger goal of moving between offline/online and syncing and keycloak tokens is working.  Possibly some discussions around how best to manage those states (online vs offline), and what considerations there are around the user workflow.
Screenshots

Checklist:

[x] My code follows the style guidelines of this project
[x] I have performed a self-review of my own code
[ ] I have made corresponding changes to the documentation
[ ] New and existing unit tests pass locally with my changes

looks like there are some code smells and bit of duplication being reported by sonarcloud - would be nice to clean those up prior to merge if possible :)


No Codecov report for pull request base

Describe the bug
Whenever a PR is submitted, Codecov Report shows "No coverage uploaded for pull request base".
Example: https://github.com/projectmesa/mesa-geo/pull/69#issuecomment-1148381066
Expected behavior
Example: https://github.com/projectmesa/mesa/pull/1355#issuecomment-1148269552
To Reproduce
Submit any PR to reproduce.

https://app.codecov.io/gh/projectmesa/mesa-geo
Probably need to ask codecov.io's tech support about it.

Let me see if adding a .coveragerc file helps.
I contacted codecov.io but they do not provide support : ( Their reply:

Thanks for reaching out to Codecov Support. Please note that, with hundreds of thousands of developers using Codecov, we are not able to offer direct email support to our open source / free users at this time.
To that end, we strongly recommend visiting our Community Board to see if this request has come up before or to create a new post there. Our Support Team reviews the posts on that board regularly to provide best-effort support.
In case you are on a paid plan and this message was an error, please let us know and we will get back to you shortly.

Seems to be fixed via the .coveragerc! See #72 for the test.


Consider ROCm releases with upstream llvm compatibility

One of major issues for ROCm distribution packaging is the compatibility with upstream llvm due to the asynchronous development cycle.
For example, feature A pushed to ROCm's llvm, and then pushed to upstream llvm. If unfortunate, A needs to wait about half a year to enter next llvm stable release; while for ROCm the next release will come sooner, shipping A and components depending on A.
What's more, A is implemented upon llvm version X, but when upstreamed it enters the X+1 release. However the ROCm new release Y ships A with llvm X (ROCm forked). Distribution: cannot ship llvm-X & ROCm-Y becuase ROCm-Y depend on A. llvm-X+1 is also incompatible with ROCm-Y because it is based on llvm-X.
Situation nowadays are much better, only few patches can do the hack. But it still makes maintaining ROCm distribution packages difficult. It would be better if ROCm latest source releases can be compatible with the upstream llvm release.
@emollier @cgmb @Mystro256 @Madouura @tpkessler Distribution packagers can also reference this issue when reporting and fixing such incompatibility, and sharing information to reduce workload.

I was speaking with some of the compiler guys and I believe the intention is to move towards using stable LLVM or at least allow for compilation against stable LLVM. Unfortunately, there's no timeline and it seems like a bit of an involved task due to how their code flows processes work.
For now, I've been just maintaining my own branch of compiler support:
https://github.com/Mystro256/ROCm-CompilerSupport/tree/rocm-4.5.2-llvm13
https://github.com/Mystro256/ROCm-CompilerSupport/tree/rocm-roc-5.0.x-llvm13
https://github.com/Mystro256/ROCm-CompilerSupport/tree/roc-5.1.x-llvm14
https://github.com/Mystro256/ROCm-CompilerSupport/tree/rocm-5.2.x-llvm14
https://github.com/Mystro256/ROCm-CompilerSupport/tree/rocm-5.2.x-llvm15
(I believe ROCm 5.3 and 5.4 just worked as-is with LLVM 15 and 16 respectively)
It's mostly reverts or cherry-picks to get it to work. It's not perfect, but it gets the Fedora packages moving.
Some downstream ROCm components might expect a newer LLVM, but this component is definitely the most sensitive. I suspect when I eventually get around to packaging HIP in Fedora, the package set will be more sensitive to the LLVM version.

I was speaking with some of the compiler guys and I believe the intention is to move towards using stable LLVM or at least allow for compilation against stable LLVM. Unfortunately, there's no timeline and it seems like a bit of an involved task due to how their code flows processes work.

Hope stable releases of downstream projects could be synced with LLVM. It would be better if they got upstream (especially rocm-device-libs)

Some downstream ROCm components might expect a newer LLVM, but this component is definitely the most sensitive. I suspect when I eventually get around to packaging HIP in Fedora, the package set will be more sensitive to the LLVM version.

From my experience rocm-device-libs and rocm-compilersupport has the closest relationship with LLVM. The first one provides bitcodes, and the second currently contains comgr, in my sense a library that calls clang driver (using C++ API) to compile and inspect GPU code objects. HIP is a runtime API + hipcc the perl wrapper (for AOT) + hiprtc (the wrapper for comgr? For JIT), and it's relationship with llvm/clang is somehow weaker compared to the previous two.

https://github.com/llvm/llvm-project/issues/60313 & https://github.com/RadeonOpenCompute/ROCm-CompilerSupport/issues/45
4 of comgr test case use a feature to call amdgpu kernel within a amdgpu kernel, but the feature is not well implemented and not upstreamed. Last time a check fedora has patched out these 4 tests.
In Gentoo I patched the test to avoid calling other kernels inside a kernel, so the compilations are OK with upstream clang. This strips out the test failures, and keeps the purpose of testing basic compilation capabilities of comgr.

And in developing branch a potential breakage is found between llvm/clang and rocm-device-libs:
https://reviews.llvm.org/D142507 & https://github.com/RadeonOpenCompute/ROCm-Device-Libs/commit/8dc779e19cbf2ccfd3307b60f7db57cf4203a5be

@searlmc1 as FYI

4 of comgr test case use a feature to call amdgpu kernel within a amdgpu kernel, but the feature is not well implemented and not upstreamed. Last time a check fedora has patched out these 4 tests.

Yes that was me, and I just adopted your patch. Thank you!
See:
https://src.fedoraproject.org/rpms/rocm-compilersupport/c/cd84e9a05e34cedd76a1e9e8eeb586cf7bf50791?branch=rawhide

And in developing branch a potential breakage is found between llvm/clang and rocm-device-libs:

Thanks for pointing this out. I guess it means we should keep device libs at 5.4 for LLVM 16? I'm a bit uncomfortable with this response:

[from https://reviews.llvm.org/D142507] In general the idea is that compiler and device-libs should match. I guess the correct answer then users of clang-16 shall use rocm-5.4.x branch of the device libs?

See: https://src.fedoraproject.org/rpms/rocm-compilersupport/c/cd84e9a05e34cedd76a1e9e8eeb586cf7bf50791?branch=rawhide

And in amd-stg-open branch they added mangled_names test, which needs to be adjusted after the workaround for amdgpu kernel call:
https://github.com/littlewu2508/gentoo/blob/rocm-9999/dev-libs/rocm-comgr/files/rocm-comgr-9999-fix-tests.patch

Thanks for pointing this out. I guess it means we should keep device libs at 5.4 for LLVM 16? I'm a bit uncomfortable with this response:

Yes. While there's uncertainties. If (ROCm) may revert https://github.com/RadeonOpenCompute/ROCm-Device-Libs/commit/8dc779e19cbf2ccfd3307b60f7db57cf4203a5be on ROCm-5.5.x releases then things will be fine. Or we have to revert it ourselves for llvm-16 compatibility.

Ok after some thought, for the meantime I think I'm going to try to maintain some branches for LLVM versions:
https://github.com/Mystro256/ROCm-Device-Libs/tree/release/16.x
https://github.com/Mystro256/ROCm-CompilerSupport/tree/release/16.x
Feel free to contribute if you are interested. I'm going to try evaluating it as I go when Fedora bumps to llvm 16.
I'm going to skim through the patches as they come in release branches and pull in the critical fixes as I go. For now it's just a snapshot of amd-stg-open.

Haven't cut a release yet, but for the HIP portion of ROCm I now have Bazel build files in rules_ll.
This project makes it possible to write a target like:
ll_binary(name="hip_example", srcs=["hello.hip"], compilation_mode="hip_amdgpu")

Which can be built and run with:
bazel run hip_example

rules_ll will fetch LLVM and ROCm from close to upstream, build a C++ toolchain from the fetched LLVM, use that toolchain to build the ROCm stack and then construct a hip_amdgpu toolchain that builds the hip_example target. (and then Bazel runs it). This all happens in wrapped Nix environments, making this build fully hermetic and reproducible down to the c library (modulo bugs).
With a single command invocation this all happens automaticlly 🥳
This is of course highly experimental. at the moment it only works with out-of-tree rules_ll, and not with the regular installation instructions. I'll create a release in the next few days and then create an issue that explains this in more detail.

@littlewu2508 Is this ticket still relevant? Thanks!


BUG - Sub folders not working on crunchyroll

Program version
3.0.7
Operating System
Windows
Type
Cli
Service
Crunchyroll
Command used
anidl.exe --service crunchy --srz GNVHKN78X -e 12 timeout /t -1
Show ID
all
Episode
all
Console Output
Not Working:
C:\Users\rdkno\OneDrive\Desktop\multi-downloader-nx-1.0.0-win64>anidl.exe --service crunchy --srz GNVHKN78X -e 12
=== Multi Downloader NX 3.0.7 ===
[INFO] USER: drknss89<EMAIL_ADDRESS>[INFO] Your Country: US
[Z:GNVHKN78X] Cautious Hero: The Hero is Overpowered but Overly Cautious (Seasons: 3, EPs: 24) [SUB, DUB]
[S:GYWEC39DE] Cautious Hero: The Hero is Overpowered but Overly Cautious (Season: 1) [SUB]
[S:GYGGCVMGN] Cautious Hero: The Hero is Overpowered but Overly Cautious (English Dub) (Season: 1) [DUB]
[INFO] USER: drknss89<EMAIL_ADDRESS>[INFO] Your Country: US
[E1] Cautious Hero: The Hero is Overpowered but Overly Cautious - Season 1 - This Hero Is Too Arrogant [☆ Japanese, ☆ English]
[E2] Cautious Hero: The Hero is Overpowered but Overly Cautious - Season 1 - Too Much For a Novice Goddess to Bear [☆ Japanese, ☆ English]
[E3] Cautious Hero: The Hero is Overpowered but Overly Cautious - Season 1 - This Hero Is Too Self-Serving [☆ Japanese, ☆ English]
[E4] Cautious Hero: The Hero is Overpowered but Overly Cautious - Season 1 - I So Don't Need Any Allies [☆ Japanese, ☆ English]
[E5] Cautious Hero: The Hero is Overpowered but Overly Cautious - Season 1 - This Goddess Is Too Spooky [☆ Japanese, ☆ English]
[E6] Cautious Hero: The Hero is Overpowered but Overly Cautious - Season 1 - The Great Dragon Mother Is Too Sneaky [☆ Japanese, ☆ English]
[E7] Cautious Hero: The Hero is Overpowered but Overly Cautious - Season 1 - This Lady Knight Is Too Doglike [☆ Japanese, ☆ English]
[E8] Cautious Hero: The Hero is Overpowered but Overly Cautious - Season 1 - Neat and Tidy but Overly Nymphomaniacal [☆ Japanese, ☆ English]
[E9] Cautious Hero: The Hero is Overpowered but Overly Cautious - Season 1 - This Reaper Is Just Too Invincible [☆ Japanese, ☆ English]
[E10] Cautious Hero: The Hero is Overpowered but Overly Cautious - Season 1 - This Man Is Too Strong for Being So Old [☆ Japanese, ☆ English]
[E11] Cautious Hero: The Hero is Overpowered but Overly Cautious - Season 1 - The Truth Is Too Much to Bear [☆ Japanese, ☆ English]
[E12] Cautious Hero: The Hero is Overpowered but Overly Cautious - Season 1 - The Hero Is Overpowered But Overly Cautious [☆ Japanese, ☆ English]

[S1E12] - The Hero Is Overpowered But Overly Cautious [✓ English]
[INFO] Requesting: [GQJUG9PV5] Cautious Hero: The Hero is Overpowered but Overly Cautious - 12 - The Hero Is Overpowered But Overly Cautious
[INFO] Selecting raw stream
[INFO] Full stream found! (✓1: adaptive_hls/eng/- )
[INFO] Full stream found! ( 2: download_hls/eng/- )
[INFO] Full stream found! ( 3: vo_adaptive_hls/eng/- )
[INFO] Downloading video...
[INFO] Playlists URL: https://pl.crunchyroll.com/evs3/3303b0f71b0828d5793299d84a665732/assets/5ac170d4e168b4adc61a3f67a0faa5a4_,4287438.mp4,4287439.mp4,4287437.mp4,4287435.mp4,4287436.mp4,4287434.mp4,.urlset/master.m3u8?Expires=1656700748&Policy=eyJTdGF0ZW1lbnQiOlt7IlJlc291cmNlIjoiaHR0cHM6Ly9wbC5jcnVuY2h5cm9sbC5jb20vZXZzMy8zMzAzYjBmNzFiMDgyOGQ1NzkzMjk5ZDg0YTY2NTczMi9hc3NldHMvNWFjMTcwZDRlMTY4YjRhZGM2MWEzZjY3YTBmYWE1YTRfLDQyODc0MzgubXA0LDQyODc0MzkubXA0LDQyODc0MzcubXA0LDQyODc0MzUubXA0LDQyODc0MzYubXA0LDQyODc0MzQubXA0LC51cmxzZXQvbWFzdGVyLm0zdTgiLCJDb25kaXRpb24iOnsiRGF0ZUxlc3NUaGFuIjp7IkFXUzpFcG9jaFRpbWUiOjE2NTY3MDA3NDh9fX1dfQ__&Signature=Ax~8aHhXckx1eU1x~n3GRk~gYdK5JmmlaZ1NqsxV1~giDKLcvM3BsEzMfilr3bHfyDsK9cIE-VL8DQ-r892S0ocvG3pmwnT2B26nALw3uQVvtPYv2~TZLVmuAYLZi5feFOBK6sHVszvCXaEQlV7rwc4Mn6oBj~b2xJYnqttOpk52k8SK7Mtp~I1D9H4LvDMG5gAeLIreFr3cB3-FqxxOHQJETC94qI9HvhorglSQhRoHwZs7GTEqswS6bCJySQTnJXtpnsiEKy4XxOlD~H3RcP1JhJtwS-BtlLNEZDe7r6gpNvUd39R6jPj55rPF7nB4tkfSWcjf-qRnDwHPJV8ueQ__&Key-Pair-Id=APKAJMWSQ5S7ZB3MF5VA (adaptive_hls/eng/-)
[INFO] Servers available:
pl.crunchyroll.com (ll-prod)
pl.crunchyroll.com (akamai-prod)
[INFO] Available qualities:
[1] 144x80 (190KiB/s)
[2] 428x240 (549KiB/s)
[3] 640x360 (1066KiB/s)
[4] 848x480 (2037KiB/s)
[5] 1280x720 (4018KiB/s)
[6] 1920x1080 (7910KiB/s)
[INFO] Selected quality: 1920x1080 @ pl.crunchyroll.com (ll-prod)
[INFO] Stream URL: https://pl.crunchyroll.com/evs3/3303b0f71b0828d5793299d84a665732/assets/5ac170d4e168b4adc61a3f67a0faa5a4_4287439.mp4/index-v1-a1.m3u8?Expires=1656700749&Policy=eyJTdGF0ZW1lbnQiOlt7IlJlc291cmNlIjoiaHR0cHM6Ly9wbC5jcnVuY2h5cm9sbC5jb20vZXZzMy8zMzAzYjBmNzFiMDgyOGQ1NzkzMjk5ZDg0YTY2NTczMi9hc3NldHMvNWFjMTcwZDRlMTY4YjRhZGM2MWEzZjY3YTBmYWE1YTRfKi5tM3U4PyoiLCJDb25kaXRpb24iOnsiRGF0ZUxlc3NUaGFuIjp7IkFXUzpFcG9jaFRpbWUiOjE2NTY3MDA3NDl9fX1dfQ__&Signature=lj4IgGLCym4RcdaZI7v~w~1-o8g2eQZYftXc3uR9rFJLBmpMENFxosfaKuiXcxDOKoLhxdstcX4D50k9zf5GyhZ4JVm00hWw8Zo-ST0Lox6OjSbc2MAQ5T5NJvi5UjnCtWtTQ7wuGBIUlTk21RD45ST-RogRT3hU8wu5i57z-0H4IyHa2aihbAsUZYOhP~VuHvgB~6Fcf0t2nVcR4fiaoEK9ZoROo96eb688ITQbV6CcJbkWSQwvWL9emyvimPPdaf6ngwFyKOBESX3UtTAEFcHdXEwn66KaboPfqprXAO3lq~N1AQNryF1u9LvhnbmfCsg6CM5tZjw-ck9s8cy2Dw__&Key-Pair-Id=APKAJMWSQ5S7ZB3MF5VA&cdn=ll-prod
[INFO] Output filename: \Cautious Hero_ The Hero is Overpowered but Overly Cautious\S01\Cautious Hero_ The Hero is Overpowered but Overly Cautious - S01E12 - The Hero Is Overpowered But Overly Cautious.English
[INFO] Total parts in stream: 356 (18*20)
[INFO] Saving stream to «\Cautious Hero_ The Hero is Overpowered but Overly Cautious\S01\Cautious Hero_ The Hero is Overpowered but Overly Cautious - S01E12 - The Hero Is Overpowered But Overly Cautious.English.ts»...
[WARN] Part 4: 2 attempt to retrieve data
ERROR: Timeout awaiting 'request' for 15000ms
[WARN] Part 2: 2 attempt to retrieve data
ERROR: Timeout awaiting 'request' for 15000ms
[WARN] Part 17: 2 attempt to retrieve data
ERROR: Timeout awaiting 'request' for 15000ms
Error: ENOENT: no such file or directory, open '\Cautious Hero_ The Hero is Overpowered but Overly Cautious\S01\Cautious Hero_ The Hero is Overpowered but Overly Cautious - S01E12 - The Hero Is Overpowered But Overly Cautious.English.ts'
at Object.openSync (node:fs:585:3)
at Object.openSync (pkg/prelude/bootstrap.js:796:32)
at Object.writeFileSync (node:fs:2170:35)
at hlsDownload.download (C:\snapshot\multi-downloader-nx\lib\node_modules\hls-download\src\hls-download.js:200:28)
at runMicrotasks ()
at processTicksAndRejections (node:internal/process/task_queues:96:5) {
errno: -4058,
syscall: 'open',
code: 'ENOENT',
path: '\Cautious Hero_ The Hero is Overpowered but Overly Cautious\S01\Cautious Hero_ The Hero is Overpowered but Overly Cautious - S01E12 - The Hero Is Overpowered But Overly Cautious.English.ts'
}
[ERROR] Unable to write to file '\Cautious Hero_ The Hero is Overpowered but Overly Cautious\S01\Cautious Hero_ The Hero is Overpowered but Overly Cautious - S01E12 - The Hero Is Overpowered But Overly Cautious.English.ts' (Attempt 1/3)
[INFO] Waiting 5s before retrying
Error: ENOENT: no such file or directory, open '\Cautious Hero_ The Hero is Overpowered but Overly Cautious\S01\Cautious Hero_ The Hero is Overpowered but Overly Cautious - S01E12 - The Hero Is Overpowered But Overly Cautious.English.ts'
at Object.openSync (node:fs:585:3)
at Object.openSync (pkg/prelude/bootstrap.js:796:32)
at Object.writeFileSync (node:fs:2170:35)
at hlsDownload.download (C:\snapshot\multi-downloader-nx\lib\node_modules\hls-download\src\hls-download.js:200:28) {
errno: -4058,
syscall: 'open',
code: 'ENOENT',
path: '\Cautious Hero_ The Hero is Overpowered but Overly Cautious\S01\Cautious Hero_ The Hero is Overpowered but Overly Cautious - S01E12 - The Hero Is Overpowered But Overly Cautious.English.ts'
}
[ERROR] Unable to write to file '\Cautious Hero_ The Hero is Overpowered but Overly Cautious\S01\Cautious Hero_ The Hero is Overpowered but Overly Cautious - S01E12 - The Hero Is Overpowered But Overly Cautious.English.ts' (Attempt 2/3)
[INFO] Waiting 5s before retrying
Error: ENOENT: no such file or directory, open '\Cautious Hero_ The Hero is Overpowered but Overly Cautious\S01\Cautious Hero_ The Hero is Overpowered but Overly Cautious - S01E12 - The Hero Is Overpowered But Overly Cautious.English.ts'
at Object.openSync (node:fs:585:3)
at Object.openSync (pkg/prelude/bootstrap.js:796:32)
at Object.writeFileSync (node:fs:2170:35)
at hlsDownload.download (C:\snapshot\multi-downloader-nx\lib\node_modules\hls-download\src\hls-download.js:200:28) {
errno: -4058,
syscall: 'open',
code: 'ENOENT',
path: '\Cautious Hero_ The Hero is Overpowered but Overly Cautious\S01\Cautious Hero_ The Hero is Overpowered but Overly Cautious - S01E12 - The Hero Is Overpowered But Overly Cautious.English.ts'
}
[ERROR] Unable to write to file '\Cautious Hero_ The Hero is Overpowered but Overly Cautious\S01\Cautious Hero_ The Hero is Overpowered but Overly Cautious - S01E12 - The Hero Is Overpowered But Overly Cautious.English.ts' (Attempt 3/3)
[INFO] Waiting 5s before retrying
[ERROR] Unable to write content to '\Cautious Hero_ The Hero is Overpowered but Overly Cautious\S01\Cautious Hero_ The Hero is Overpowered but Overly Cautious - S01E12 - The Hero Is Overpowered But Overly Cautious.English.ts'.
[ERROR] DL Stats: {"first":1,"total":356,"completed":0}
node:fs:585
handleErrorFromBinding(ctx);
^
Error: ENOENT: no such file or directory, open 'C:\Users\rdkno\OneDrive\Desktop\multi-downloader-nx-1.0.0-win64\videos\Cautious Hero_ The Hero is Overpowered but Overly Cautious\S01\Cautious Hero_ The Hero is Overpowered but Overly Cautious - S01E12 - The Hero Is Overpowered But Overly Cautious.01 eng English.ass'
at Object.openSync (node:fs:585:3)
at Object.openSync (pkg/prelude/bootstrap.js:796:32)
at Object.writeFileSync (node:fs:2170:35)
at C:\snapshot\multi-downloader-nx\lib\crunchy.js
at step (C:\snapshot\multi-downloader-nx\lib\crunchy.js)
at Object.next (C:\snapshot\multi-downloader-nx\lib\crunchy.js)
at step (C:\snapshot\multi-downloader-nx\lib\crunchy.js)
at Object.next (C:\snapshot\multi-downloader-nx\lib\crunchy.js)
at step (C:\snapshot\multi-downloader-nx\lib\crunchy.js)
at Object.next (C:\snapshot\multi-downloader-nx\lib\crunchy.js) {
errno: -4058,
syscall: 'open',
code: 'ENOENT',
path: 'C:\Users\rdkno\OneDrive\Desktop\multi-downloader-nx-1.0.0-win64\videos\Cautious Hero_ The Hero is Overpowered but Overly Cautious\S01\Cautious Hero_ The Hero is Overpowered but Overly Cautious - S01E12 - The Hero Is Overpowered But Overly Cautious.01 eng English.ass'
}
Working:
C:\Users\rdkno\OneDrive\Desktop\multi-downloader-nx-1.0.0-win64>anidl.exe --service crunchy --srz GNVHKN78X -e 12
=== Multi Downloader NX 3.0.7 ===
[INFO] USER: drknss89<EMAIL_ADDRESS>[INFO] Your Country: US
[Z:GNVHKN78X] Cautious Hero: The Hero is Overpowered but Overly Cautious (Seasons: 3, EPs: 24) [SUB, DUB]
[S:GYWEC39DE] Cautious Hero: The Hero is Overpowered but Overly Cautious (Season: 1) [SUB]
[S:GYGGCVMGN] Cautious Hero: The Hero is Overpowered but Overly Cautious (English Dub) (Season: 1) [DUB]
[INFO] USER: drknss89<EMAIL_ADDRESS>[INFO] Your Country: US
[E1] Cautious Hero: The Hero is Overpowered but Overly Cautious - Season 1 - This Hero Is Too Arrogant [☆ Japanese, ☆ English]
[E2] Cautious Hero: The Hero is Overpowered but Overly Cautious - Season 1 - Too Much For a Novice Goddess to Bear [☆ Japanese, ☆ English]
[E3] Cautious Hero: The Hero is Overpowered but Overly Cautious - Season 1 - This Hero Is Too Self-Serving [☆ Japanese, ☆ English]
[E4] Cautious Hero: The Hero is Overpowered but Overly Cautious - Season 1 - I So Don't Need Any Allies [☆ Japanese, ☆ English]
[E5] Cautious Hero: The Hero is Overpowered but Overly Cautious - Season 1 - This Goddess Is Too Spooky [☆ Japanese, ☆ English]
[E6] Cautious Hero: The Hero is Overpowered but Overly Cautious - Season 1 - The Great Dragon Mother Is Too Sneaky [☆ Japanese, ☆ English]
[E7] Cautious Hero: The Hero is Overpowered but Overly Cautious - Season 1 - This Lady Knight Is Too Doglike [☆ Japanese, ☆ English]
[E8] Cautious Hero: The Hero is Overpowered but Overly Cautious - Season 1 - Neat and Tidy but Overly Nymphomaniacal [☆ Japanese, ☆ English]
[E9] Cautious Hero: The Hero is Overpowered but Overly Cautious - Season 1 - This Reaper Is Just Too Invincible [☆ Japanese, ☆ English]
[E10] Cautious Hero: The Hero is Overpowered but Overly Cautious - Season 1 - This Man Is Too Strong for Being So Old [☆ Japanese, ☆ English]
[E11] Cautious Hero: The Hero is Overpowered but Overly Cautious - Season 1 - The Truth Is Too Much to Bear [☆ Japanese, ☆ English]
[E12] Cautious Hero: The Hero is Overpowered but Overly Cautious - Season 1 - The Hero Is Overpowered But Overly Cautious [☆ Japanese, ☆ English]

[S1E12] - The Hero Is Overpowered But Overly Cautious [✓ English]
[INFO] Requesting: [GQJUG9PV5] Cautious Hero: The Hero is Overpowered but Overly Cautious - 12 - The Hero Is Overpowered But Overly Cautious
[INFO] Selecting raw stream
[INFO] Full stream found! (✓1: adaptive_hls/eng/- )
[INFO] Full stream found! ( 2: download_hls/eng/- )
[INFO] Full stream found! ( 3: vo_adaptive_hls/eng/- )
[INFO] Downloading video...
[INFO] Playlists URL: https://pl.crunchyroll.com/evs3/3303b0f71b0828d5793299d84a665732/assets/5ac170d4e168b4adc61a3f67a0faa5a4_,4287438.mp4,4287439.mp4,4287437.mp4,4287435.mp4,4287436.mp4,4287434.mp4,.urlset/master.m3u8?Expires=1656701334&Policy=eyJTdGF0ZW1lbnQiOlt7IlJlc291cmNlIjoiaHR0cHM6Ly9wbC5jcnVuY2h5cm9sbC5jb20vZXZzMy8zMzAzYjBmNzFiMDgyOGQ1NzkzMjk5ZDg0YTY2NTczMi9hc3NldHMvNWFjMTcwZDRlMTY4YjRhZGM2MWEzZjY3YTBmYWE1YTRfLDQyODc0MzgubXA0LDQyODc0MzkubXA0LDQyODc0MzcubXA0LDQyODc0MzUubXA0LDQyODc0MzYubXA0LDQyODc0MzQubXA0LC51cmxzZXQvbWFzdGVyLm0zdTgiLCJDb25kaXRpb24iOnsiRGF0ZUxlc3NUaGFuIjp7IkFXUzpFcG9jaFRpbWUiOjE2NTY3MDEzMzR9fX1dfQ__&Signature=kKS7jPmI2dGtweefESlIgf3D9rHKs4NpZaRWR5KnD17HebbhdUtWjfAFc7CJ26Mvr2CgvLqTDJWqnOjVp81hUQG8iwLwEYqeuRKSLSlEXpmgGquozuPN4VdddTJ6EfiuTHSHT2hQNEtrBDX5DNZS7Tg~N8guQtsJaKZXH4CVKXOTFJpVDX2Zd78mWPM2PddLoQfU9OrjtCyElljcC3qPopn80Jgoo~dkWvdK-umXvxjTBVBR1kfCpS~v-VgS2~YEw8DMc90NphBGHz~EWu~bzlo-FMqfQtEABAVtXCtFdhBhaIhCn9UVaek2N~Tio6jmLC2o2HP4zBm8c7EIjmEqnQ__&Key-Pair-Id=APKAJMWSQ5S7ZB3MF5VA (adaptive_hls/eng/-)
[INFO] Servers available:
pl.crunchyroll.com (ll-prod)
pl.crunchyroll.com (akamai-prod)
[INFO] Available qualities:
[1] 144x80 (190KiB/s)
[2] 428x240 (549KiB/s)
[3] 640x360 (1066KiB/s)
[4] 848x480 (2037KiB/s)
[5] 1280x720 (4018KiB/s)
[6] 1920x1080 (7910KiB/s)
[INFO] Selected quality: 1920x1080 @ pl.crunchyroll.com (ll-prod)
[INFO] Stream URL: https://pl.crunchyroll.com/evs3/3303b0f71b0828d5793299d84a665732/assets/5ac170d4e168b4adc61a3f67a0faa5a4_4287439.mp4/index-v1-a1.m3u8?Expires=1656701334&Policy=eyJTdGF0ZW1lbnQiOlt7IlJlc291cmNlIjoiaHR0cHM6Ly9wbC5jcnVuY2h5cm9sbC5jb20vZXZzMy8zMzAzYjBmNzFiMDgyOGQ1NzkzMjk5ZDg0YTY2NTczMi9hc3NldHMvNWFjMTcwZDRlMTY4YjRhZGM2MWEzZjY3YTBmYWE1YTRfKi5tM3U4PyoiLCJDb25kaXRpb24iOnsiRGF0ZUxlc3NUaGFuIjp7IkFXUzpFcG9jaFRpbWUiOjE2NTY3MDEzMzR9fX1dfQ__&Signature=ay~gk0RoR9QXtbAHkGoXwNIGO010i6Xya7jimKkk1F4Us5jn-Xb3HHfgZFba0Hi5BMyw6Rnlf2xyKx1gH~daqoe70UHznyhJES3PlnJIg9TIC1jELkUJkpDoyu-4EypnOlseDL8n03q4d3H5qcaJsrpdTNiHqRENcM~casynq49eJ04SN6SOz0IL2rZQn-38-aWoMnPy~47Q2l~-wg1uDbMeRbAdKXan5GoiFLynkqjdc8wvUbi8bE1JzjDNlJ0nZ4hVnrC8md9g5PwuvEKolckdvYF651CsSZLTjDyVIVCZrmjKtG~mPssdbD6DjY4Np7qJ-8tjzmbKlxAz18WmPA__&Key-Pair-Id=APKAJMWSQ5S7ZB3MF5VA&cdn=ll-prod
[INFO] Output filename: Cautious Hero_ The Hero is Overpowered but Overly Cautious - S01E12 - The Hero Is Overpowered But Overly Cautious.English
[INFO] Total parts in stream: 356 (18*20)
[INFO] Saving stream to «C:\Users\rdkno\OneDrive\Desktop\multi-downloader-nx-1.0.0-win64\videos\Cautious Hero_ The Hero is Overpowered but Overly Cautious - S01E12 - The Hero Is Overpowered But Overly Cautious.English.ts»...
[INFO] 20 of 356 parts downloaded [6%] (4m04s | 6.1Mb/s)
[INFO] 40 of 356 parts downloaded [11%] (4m21s | 5.0Mb/s)
[INFO] 60 of 356 parts downloaded [17%] (5m06s | 4.0Mb/s)
[INFO] 80 of 356 parts downloaded [22%] (4m37s | 4.0Mb/s)
[INFO] 100 of 356 parts downloaded [28%] (4m15s | 4.0Mb/s)
[INFO] 120 of 356 parts downloaded [34%] (3m51s | 4.1Mb/s)
[INFO] 140 of 356 parts downloaded [39%] (3m33s | 4.1Mb/s)
[INFO] 160 of 356 parts downloaded [45%] (3m11s | 4.2Mb/s)
[INFO] 180 of 356 parts downloaded [51%] (2m43s | 4.3Mb/s)
[INFO] 200 of 356 parts downloaded [56%] (2m22s | 4.4Mb/s)
[INFO] 220 of 356 parts downloaded [62%] (2m01s | 4.5Mb/s)
[INFO] 240 of 356 parts downloaded [67%] (1m52s | 4.2Mb/s)
[INFO] 260 of 356 parts downloaded [73%] (1m31s | 4.3Mb/s)
[INFO] 280 of 356 parts downloaded [79%] (1m12s | 4.3Mb/s)
[INFO] 300 of 356 parts downloaded [84%] (52s | 4.3Mb/s)
[INFO] 320 of 356 parts downloaded [90%] (33s | 4.4Mb/s)
[INFO] 340 of 356 parts downloaded [96%] (15s | 4.3Mb/s)
[INFO] 356 of 356 parts downloaded [100%] (0s | 4.4Mb/s)
[INFO] Subtitle downloaded: Cautious Hero_ The Hero is Overpowered but Overly Cautious - S01E12 - The Hero Is Overpowered But Overly Cautious.01 eng English.ass
[INFO] Subtitles: en (Total: 1)
[INFO] Required fonts: Arial (Total: 1)
[INFO][ffmpeg] Started merging

"ffmpeg" -i "C:\Users\rdkno\OneDrive\Desktop\multi-downloader-nx-1.0.0-win64\videos\Cautious Hero_ The Hero is Overpowered but Overly Cautious - S01E12 - The Hero Is Overpowered But Overly Cautious.English.ts" -i "C:\Users\rdkno\OneDrive\Desktop\multi-downloader-nx-1.0.0-win64\videos\Cautious Hero_ The Hero is Overpowered but Overly Cautious - S01E12 - The Hero Is Overpowered But Overly Cautious.01 eng English.ass" -map 0:a -map 0:v -metadata:s:a:0 language=eng -metadata:s:v:0 title="undefined" -map 1 -c:v copy -c:a copy -c:s ass -metadata:s:s:0 title="English" -metadata:s:s:0 language=eng "C:\Users\rdkno\OneDrive\Desktop\multi-downloader-nx-1.0.0-win64\videos\Cautious Hero_ The Hero is Overpowered but Overly Cautious - S01E12 - The Hero Is Overpowered But Overly Cautious.mkv"
ffmpeg version 2021-07-18-git-694545b6d5-full_build-www.gyan.dev Copyright (c) 2000-2021 the FFmpeg developers
built with gcc 10.3.0 (Rev5, Built by MSYS2 project)
configuration: --enable-gpl --enable-version3 --enable-static --disable-w32threads --disable-autodetect --enable-fontconfig --enable-iconv --enable-gnutls --enable-libxml2 --enable-gmp --enable-lzma --enable-libsnappy --enable-zlib --enable-librist --enable-libsrt --enable-libssh --enable-libzmq --enable-avisynth --enable-libbluray --enable-libcaca --enable-sdl2 --enable-libdav1d --enable-libzvbi --enable-librav1e --enable-libsvtav1 --enable-libwebp --enable-libx264 --enable-libx265 --enable-libxvid --enable-libaom --enable-libopenjpeg --enable-libvpx --enable-libass --enable-frei0r --enable-libfreetype --enable-libfribidi --enable-libvidstab --enable-libvmaf --enable-libzimg --enable-amf --enable-cuda-llvm --enable-cuvid --enable-ffnvcodec --enable-nvdec --enable-nvenc --enable-d3d11va --enable-dxva2 --enable-libmfx --enable-libglslang --enable-vulkan --enable-opencl --enable-libcdio --enable-libgme --enable-libmodplug --enable-libopenmpt --enable-libopencore-amrwb --enable-libmp3lame --enable-libshine --enable-libtheora --enable-libtwolame --enable-libvo-amrwbenc --enable-libilbc --enable-libgsm --enable-libopencore-amrnb --enable-libopus --enable-libspeex --enable-libvorbis --enable-ladspa --enable-libbs2b --enable-libflite --enable-libmysofa --enable-librubberband --enable-libsoxr --enable-chromaprint
libavutil      57.  0.100 / 57.  0.100
libavcodec     59.  3.101 / 59.  3.101
libavformat    59.  4.100 / 59.  4.100
libavdevice    59.  0.100 / 59.  0.100
libavfilter     8.  0.103 /  8.  0.103
libswscale      6.  0.100 /  6.  0.100
libswresample   4.  0.100 /  4.  0.100
libpostproc    56.  0.100 / 56.  0.100
[mpegts @ 0000026f8810ed40] start time for stream 2 is not set in estimate_timings_from_pts
Input #0, mpegts, from 'C:\Users\rdkno\OneDrive\Desktop\multi-downloader-nx-1.0.0-win64\videos\Cautious Hero_ The Hero is Overpowered but Overly Cautious - S01E12 - The Hero Is Overpowered But Overly Cautious.English.ts':
Duration: 00:23:45.06, start: 0.101000, bitrate: 8315 kb/s
Program 1
Stream #0:0[0x100]: Video: h264 (High) ([27][0][0][0] / 0x001B), yuv420p(progressive), 1920x1080 [SAR 1:1 DAR 16:9], 23.98 fps, 23.98 tbr, 90k tbn
Stream #0:1[0x101]: Audio: aac (LC) ([15][0][0][0] / 0x000F), 44100 Hz, stereo, fltp, 130 kb/s
Stream #0:2[0x102]: Data: timed_id3 (ID3  / 0x20334449)
Input #1, ass, from 'C:\Users\rdkno\OneDrive\Desktop\multi-downloader-nx-1.0.0-win64\videos\Cautious Hero_ The Hero is Overpowered but Overly Cautious - S01E12 - The Hero Is Overpowered But Overly Cautious.01 eng English.ass':
Duration: N/A, bitrate: N/A
Stream #1:0: Subtitle: ass
Output #0, matroska, to 'C:\Users\rdkno\OneDrive\Desktop\multi-downloader-nx-1.0.0-win64\videos\Cautious Hero_ The Hero is Overpowered but Overly Cautious - S01E12 - The Hero Is Overpowered But Overly Cautious.mkv':
Metadata:
encoder         : Lavf59.4.100
Stream #0:0(eng): Audio: aac (LC) ([255][0][0][0] / 0x00FF), 44100 Hz, stereo, fltp, 130 kb/s
Stream #0:1: Video: h264 (High) (H264 / 0x34363248), yuv420p(progressive), 1920x1080 [SAR 1:1 DAR 16:9], q=2-31, 23.98 fps, 23.98 tbr, 1k tbn
Metadata:
title           : undefined
Stream #0:2(eng): Subtitle: ass
Metadata:
title           : English
encoder         : Lavc59.3.101 ass
Stream mapping:
Stream #0:1 -> #0:0 (copy)
Stream #0:0 -> #0:1 (copy)
Stream #1:0 -> #0:2 (ass (ssa) -> ass (native))
Press [q] to stop, [?] for help
frame=34167 fps=5045 q=-1.0 Lsize= 1409995kB time=00:23:45.12 bitrate=8105.0kbits/s speed= 210x
video:1387022kB audio:22687kB subtitle:0kB other streams:0kB global headers:1kB muxing overhead: 0.020230%
[INFO][ffmpeg Done]

Working Funi Folder
C:\Users\rdkno\OneDrive\Desktop\multi-downloader-nx-1.0.0-win64>anidl.exe --service "funi" -s 595600 -e 1 --nosubs
=== Multi Downloader NX 3.0.7 ===
[#595600] RADIANT (2018)
[0001] RADIANT - #01 The Young Sorcerer -Seth- (24:30) [HD1080, English] (selected)
[0002] RADIANT - #02 True Courage -Bravery- (24:30) [HD1080, English]
[0003] RADIANT - #03 The Day of Departure -Alma- (24:30) [HD1080, English]
[0004] RADIANT - #04 A Meeting in the Sky -Encounter- (24:30) [HD1080, English]
[0005] RADIANT - #05 A Paradise of Wisdom and Hope -Artemis- (24:30) [HD1080, English]
[0006] RADIANT - #06 Drops of Friendship -Melie- (24:30) [HD1080, English]
[0007] RADIANT - #07 The Beast of the Underground Water System -Monster- (24:30) [HD1080, English]
[0008] RADIANT - #08 Proof of Strength -Progress- (24:30) [HD1080, English]
[0009] RADIANT - #09 Those Who Hunt Heretics -Inquisition- (24:30) [SD540, English]
[0010] RADIANT - #10 Broom of Memories -Memory- (24:30) [HD1080, English]
[0011] RADIANT - #11 The City That Roars Like Thunder -Rumble Town- (24:30) [HD1080, English]
[0012] RADIANT - #12 The Shadow Lurking in the City -Darkness- (24:30) [HD1080, English]
[0013] RADIANT - #13 Overture of Turbulence -Storm- (24:30) [HD1080, English]
[0014] RADIANT - #14 The Bell Tolls the Sound of Destruction -Catastrophe- (24:30) [HD1080, English]
[0015] RADIANT - #15 With Fists Like Shooting Stars -Burst- (24:30) [HD1080, English]
[0016] RADIANT - #16 Fly High and Pierce Through the Storm -Rising- (24:30) [HD1080, English]
[0017] RADIANT - #17 To Stop the Sound of the Wind -Serenade- (24:30) [HD1080, English]
[0018] RADIANT - #18 The Light That Follows the Darkness -Awakening- (24:30) [HD1080, English]
[0019] RADIANT - #19 The World That You Changed -Relief- (24:30) [HD1080, English]
[0020] RADIANT - #20 Omen -Sign- (24:30) [SD540, English]
[0021] RADIANT - #21 In Search of the Future -Utopia- (24:30) [HD1080, English]
[0022] RADIANT S2 - #01 Toward a New Adventure -Overture- (24:30) [HD1080, English]
[0023] RADIANT S2 - #02 An Encounter in the Rain -Mist- (24:30) [HD1080, English]
[0024] RADIANT S2 - #03 The City of Knights -Caislean Merlin- (24:30) [HD1080, English]
[0025] RADIANT S2 - #04 The Bringer of Calamity -Dullahan- (24:30) [HD1080, English]
[0026] RADIANT S2 - #05 Silent Rain, Distant Hearts -Rain- (24:30) [HD1080, English]
[0027] RADIANT S2 - #06 His Name Is -Diabal- (24:30) [HD1080, English]
[0028] RADIANT S2 - #07 The Spectre Battle -Spectre- (24:30) [HD1080, English]
[0029] RADIANT S2 - #08 Seth in the Forest of Time -Caillte- (24:30) [HD1080, English]
[0030] RADIANT S2 - #09 The Palace of Schemes -Palace- (24:30) [HD1080, English]
[0031] RADIANT S2 - #10 The Qualifications of a Knight -Quality- (24:30) [HD1080, English]
[0032] RADIANT S2 - #11 Now, Feel the World -Resonance- (24:30) [HD1080, English]
[0033] RADIANT S2 - #12 The Truth Is Like a Curse -Ocoho- (24:30) [HD1080, English]
[0034] RADIANT S2 - #13 Your Decision -Knighthood- (24:30) [HD1080, English]
[0035] RADIANT S2 - #14 The Final Battlefield -Battlefield- (24:30) [HD1080, English]
[0036] RADIANT S2 - #15 Led to the Abyss by a Melody of Death -Harmonizium- (24:30) [HD1080, English]
[0037] RADIANT S2 - #16 The Light of Life is Extinguished -Tragedy- (24:30) [HD1080, English]
[0038] RADIANT S2 - #17 The Black Dragon Descends -Pen Draig- (24:30) [HD1080, English]
[0039] RADIANT S2 - #18 The Will of the People Shines Bright -Resistance- (24:30) [HD1080, English]
[0040] RADIANT S2 - #19 I Can't Hear Your Voice -Myrddin- (24:30) [HD1080, English]
[0041] RADIANT S2 - #20 A Bouquet of Flowers for This Land -Fantasia- (24:30) [HD1080, English]
[0042] RADIANT S2 - #21 The Future Is With You -Eternity- (24:30) [HD1080, English]
[INFO] Selected Episodes: 0001
[INFO] RADIANT - S1E1 - The Young Sorcerer -Seth-
[INFO] Available streams (Non-Encrypted):
[#595666] English [Simulcast]
[#959589] English [Uncut] (selected)
[INFO] Servers available:
vmfst-api.prd.funimationsvc.com
[INFO] Available qualities:
1: 416x234 (462KiB/s)
2: 640x360 (703KiB/s)
3: 768x432 (1106KiB/s)
4: 768x432 (1496KiB/s)
5: 960x540 (2494KiB/s)
6: 1280x720 (3793KiB/s)
7: 1280x720 (5494KiB/s)
8: 1920x1080 (7314KiB/s)
9: 1920x1080 (9533KiB/s)
[INFO] Selected layer: 9 (1920x1080) @ vmfst-api.prd.funimationsvc.com
[INFO] Stream URL: https://vmfst-api.prd.funimationsvc.com/FunimationStoreFront/V1722003/1b932e4c-b9b7-4ea0-a3b7-71c25ff20321strnv-hl154_streaming_video_1920_1080_7800000_index.m3u8?t=exp%3D1656532853~acl%3Dhttps%3A%2F%2Fvideo.prd.funimation.com%2FFunimationStoreFront%2FV1722003%2F*~hmac%3D063c6fa50c4ec2ae063f7c3e800e405b387acd9404eb5e5da933aaf71a69c32d
[INFO] Output filename: \RADIANT\S01\RADIANT - S01E01 - The Young Sorcerer -Seth-.ts
[INFO] Saving stream to «C:\Users\rdkno\OneDrive\Desktop\multi-downloader-nx-1.0.0-win64\videos\RADIANT\S01\RADIANT - S01E01 - The Young Sorcerer -Seth-.video.ts»...
[INFO] 20 of 783 parts downloaded [3%] (3m57s | 4.6Mb/s)
[INFO] 40 of 783 parts downloaded [5%] (3m52s | 4.7Mb/s)
[INFO] 60 of 783 parts downloaded [8%] (4m04s | 4.4Mb/s)
[INFO] 80 of 783 parts downloaded [10%] (4m00s | 4.4Mb/s)
[INFO] 100 of 783 parts downloaded [13%] (3m41s | 4.7Mb/s)
[INFO] 120 of 783 parts downloaded [15%] (3m34s | 4.7Mb/s)
[INFO] 140 of 783 parts downloaded [18%] (3m33s | 4.5Mb/s)
[INFO] 160 of 783 parts downloaded [20%] (3m30s | 4.4Mb/s)
[INFO] 180 of 783 parts downloaded [23%] (3m21s | 4.5Mb/s)
[INFO] 200 of 783 parts downloaded [26%] (3m14s | 4.5Mb/s)
[INFO] 220 of 783 parts downloaded [28%] (3m05s | 4.6Mb/s)
[INFO] 240 of 783 parts downloaded [31%] (3m02s | 4.5Mb/s)
[INFO] 260 of 783 parts downloaded [33%] (2m56s | 4.4Mb/s)
[INFO] 280 of 783 parts downloaded [36%] (2m48s | 4.5Mb/s)
[INFO] 300 of 783 parts downloaded [38%] (2m59s | 4.0Mb/s)
[INFO] 320 of 783 parts downloaded [41%] (2m50s | 4.0Mb/s)
[INFO] 340 of 783 parts downloaded [43%] (2m42s | 4.1Mb/s)
[INFO] 360 of 783 parts downloaded [46%] (2m31s | 4.1Mb/s)
[INFO] 380 of 783 parts downloaded [49%] (2m30s | 4.0Mb/s)
[INFO] 400 of 783 parts downloaded [51%] (2m21s | 4.0Mb/s)
[INFO] 420 of 783 parts downloaded [54%] (2m14s | 4.0Mb/s)
[INFO] 440 of 783 parts downloaded [56%] (2m10s | 3.8Mb/s)
[INFO] 460 of 783 parts downloaded [59%] (2m02s | 3.9Mb/s)
[INFO] 480 of 783 parts downloaded [61%] (1m53s | 3.9Mb/s)
[INFO] 500 of 783 parts downloaded [64%] (1m51s | 3.7Mb/s)
[INFO] 520 of 783 parts downloaded [66%] (1m45s | 3.7Mb/s)
[INFO] 540 of 783 parts downloaded [69%] (1m39s | 3.6Mb/s)
[INFO] 560 of 783 parts downloaded [72%] (1m30s | 3.6Mb/s)
[INFO] 580 of 783 parts downloaded [74%] (1m22s | 3.6Mb/s)
[INFO] 600 of 783 parts downloaded [77%] (1m14s | 3.6Mb/s)
[INFO] 620 of 783 parts downloaded [79%] (1m08s | 3.5Mb/s)
[INFO] 640 of 783 parts downloaded [82%] (1m00s | 3.5Mb/s)
[INFO] 660 of 783 parts downloaded [84%] (51s | 3.5Mb/s)
[INFO] 680 of 783 parts downloaded [87%] (43s | 3.5Mb/s)
[INFO] 700 of 783 parts downloaded [89%] (35s | 3.5Mb/s)
[INFO] 720 of 783 parts downloaded [92%] (27s | 3.4Mb/s)
[INFO] 740 of 783 parts downloaded [95%] (19s | 3.4Mb/s)
[INFO] 760 of 783 parts downloaded [97%] (10s | 3.4Mb/s)
[INFO] 780 of 783 parts downloaded [99%] (1s | 3.4Mb/s)
[INFO] 783 of 783 parts downloaded [100%] (0s | 3.4Mb/s)
[INFO] Saving stream to «C:\Users\rdkno\OneDrive\Desktop\multi-downloader-nx-1.0.0-win64\videos\RADIANT\S01\RADIANT - S01E01 - The Young Sorcerer -Seth-.audio.eng.ts»...
[INFO] 20 of 784 parts downloaded [3%] (38s | 1.3Mb/s)
[INFO] 40 of 784 parts downloaded [5%] (40s | 1.2Mb/s)
[INFO] 60 of 784 parts downloaded [8%] (38s | 1.2Mb/s)
[INFO] 80 of 784 parts downloaded [10%] (42s | 1.1Mb/s)
[INFO] 100 of 784 parts downloaded [13%] (43s | 1.0Mb/s)
[INFO] 120 of 784 parts downloaded [15%] (42s | 1.0Mb/s)
[INFO] 140 of 784 parts downloaded [18%] (45s | 0.93Mb/s)
[INFO] 160 of 784 parts downloaded [20%] (43s | 0.95Mb/s)
[WARN] Part 173: 2 attempt to retrieve data
ERROR: Timeout awaiting 'request' for 15000ms
[WARN] Part 162: 2 attempt to retrieve data
ERROR: Timeout awaiting 'request' for 15000ms
[WARN] Part 167: 2 attempt to retrieve data
ERROR: Timeout awaiting 'request' for 15000ms
[INFO] 180 of 784 parts downloaded [23%] (1m34s | 0.42Mb/s)
[INFO] 200 of 784 parts downloaded [26%] (1m25s | 0.44Mb/s)
[INFO] 220 of 784 parts downloaded [28%] (1m19s | 0.46Mb/s)
[INFO] 240 of 784 parts downloaded [31%] (1m13s | 0.48Mb/s)
[INFO] 260 of 784 parts downloaded [33%] (1m09s | 0.49Mb/s)
[INFO] 280 of 784 parts downloaded [36%] (1m04s | 0.51Mb/s)
[INFO] 300 of 784 parts downloaded [38%] (1m00s | 0.53Mb/s)
[INFO] 320 of 784 parts downloaded [41%] (55s | 0.54Mb/s)
[INFO] 340 of 784 parts downloaded [43%] (53s | 0.55Mb/s)
[INFO] 360 of 784 parts downloaded [46%] (50s | 0.55Mb/s)
[INFO] 380 of 784 parts downloaded [48%] (46s | 0.57Mb/s)
[INFO] 400 of 784 parts downloaded [51%] (43s | 0.58Mb/s)
[INFO] 420 of 784 parts downloaded [54%] (39s | 0.60Mb/s)
[INFO] 440 of 784 parts downloaded [56%] (37s | 0.61Mb/s)
[INFO] 460 of 784 parts downloaded [59%] (34s | 0.62Mb/s)
[INFO] 480 of 784 parts downloaded [61%] (32s | 0.62Mb/s)
[INFO] 500 of 784 parts downloaded [64%] (31s | 0.60Mb/s)
[INFO] 520 of 784 parts downloaded [66%] (28s | 0.60Mb/s)
[INFO] 540 of 784 parts downloaded [69%] (26s | 0.61Mb/s)
[INFO] 560 of 784 parts downloaded [71%] (24s | 0.62Mb/s)
[INFO] 580 of 784 parts downloaded [74%] (21s | 0.62Mb/s)
[INFO] 600 of 784 parts downloaded [77%] (19s | 0.62Mb/s)
[INFO] 620 of 784 parts downloaded [79%] (17s | 0.62Mb/s)
[INFO] 640 of 784 parts downloaded [82%] (15s | 0.62Mb/s)
[INFO] 660 of 784 parts downloaded [84%] (13s | 0.61Mb/s)
[INFO] 680 of 784 parts downloaded [87%] (11s | 0.61Mb/s)
[INFO] 700 of 784 parts downloaded [89%] (9s | 0.61Mb/s)
[INFO] 720 of 784 parts downloaded [92%] (7s | 0.62Mb/s)
[INFO] 740 of 784 parts downloaded [94%] (5s | 0.60Mb/s)
[INFO] 760 of 784 parts downloaded [97%] (3s | 0.60Mb/s)
[INFO] 780 of 784 parts downloaded [99%] (0s | 0.61Mb/s)
[INFO] 784 of 784 parts downloaded [100%] (0s | 0.60Mb/s)
[INFO][ffmpeg] Started merging

"ffmpeg" -i "C:\Users\rdkno\OneDrive\Desktop\multi-downloader-nx-1.0.0-win64\videos\RADIANT\S01\RADIANT - S01E01 - The Young Sorcerer -Seth-.video.ts" -i "C:\Users\rdkno\OneDrive\Desktop\multi-downloader-nx-1.0.0-win64\videos\RADIANT\S01\RADIANT - S01E01 - The Young Sorcerer -Seth-.audio.eng.ts" -map 0 -map -0:a -metadata:s:v:0 title="undefined" -map 1 -metadata:s:a:0 language=eng -c:v copy -c:a copy -c:s ass "C:\Users\rdkno\OneDrive\Desktop\multi-downloader-nx-1.0.0-win64\videos\RADIANT\S01\RADIANT - S01E01 - The Young Sorcerer -Seth-.mkv"
ffmpeg version 2021-07-18-git-694545b6d5-full_build-www.gyan.dev Copyright (c) 2000-2021 the FFmpeg developers
built with gcc 10.3.0 (Rev5, Built by MSYS2 project)
configuration: --enable-gpl --enable-version3 --enable-static --disable-w32threads --disable-autodetect --enable-fontconfig --enable-iconv --enable-gnutls --enable-libxml2 --enable-gmp --enable-lzma --enable-libsnappy --enable-zlib --enable-librist --enable-libsrt --enable-libssh --enable-libzmq --enable-avisynth --enable-libbluray --enable-libcaca --enable-sdl2 --enable-libdav1d --enable-libzvbi --enable-librav1e --enable-libsvtav1 --enable-libwebp --enable-libx264 --enable-libx265 --enable-libxvid --enable-libaom --enable-libopenjpeg --enable-libvpx --enable-libass --enable-frei0r --enable-libfreetype --enable-libfribidi --enable-libvidstab --enable-libvmaf --enable-libzimg --enable-amf --enable-cuda-llvm --enable-cuvid --enable-ffnvcodec --enable-nvdec --enable-nvenc --enable-d3d11va --enable-dxva2 --enable-libmfx --enable-libglslang --enable-vulkan --enable-opencl --enable-libcdio --enable-libgme --enable-libmodplug --enable-libopenmpt --enable-libopencore-amrwb --enable-libmp3lame --enable-libshine --enable-libtheora --enable-libtwolame --enable-libvo-amrwbenc --enable-libilbc --enable-libgsm --enable-libopencore-amrnb --enable-libopus --enable-libspeex --enable-libvorbis --enable-ladspa --enable-libbs2b --enable-libflite --enable-libmysofa --enable-librubberband --enable-libsoxr --enable-chromaprint
libavutil      57.  0.100 / 57.  0.100
libavcodec     59.  3.101 / 59.  3.101
libavformat    59.  4.100 / 59.  4.100
libavdevice    59.  0.100 / 59.  0.100
libavfilter     8.  0.103 /  8.  0.103
libswscale      6.  0.100 /  6.  0.100
libswresample   4.  0.100 /  4.  0.100
libpostproc    56.  0.100 / 56.  0.100
Input #0, mpegts, from 'C:\Users\rdkno\OneDrive\Desktop\multi-downloader-nx-1.0.0-win64\videos\RADIANT\S01\RADIANT - S01E01 - The Young Sorcerer -Seth-.video.ts':
Duration: 00:26:07.15, start: 10.041711, bitrate: 5883 kb/s
Program 16727
Stream #0:0[0x21]: Video: h264 (High) ([27][0][0][0] / 0x001B), yuv420p(tv, bt709/unknown/unknown, progressive), 1920x1080 [SAR 1:1 DAR 16:9], 23.98 fps, 23.98 tbr, 90k tbn
[aac @ 00000225de774040] Estimating duration from bitrate, this may be inaccurate
Input #1, aac, from 'C:\Users\rdkno\OneDrive\Desktop\multi-downloader-nx-1.0.0-win64\videos\RADIANT\S01\RADIANT - S01E01 - The Young Sorcerer -Seth-.audio.eng.ts':
Duration: 00:26:02.16, bitrate: 259 kb/s
Stream #1:0: Audio: aac (LC), 48000 Hz, stereo, fltp, 259 kb/s
Output #0, matroska, to 'C:\Users\rdkno\OneDrive\Desktop\multi-downloader-nx-1.0.0-win64\videos\RADIANT\S01\RADIANT - S01E01 - The Young Sorcerer -Seth-.mkv':
Metadata:
encoder         : Lavf59.4.100
Stream #0:0: Video: h264 (High) (H264 / 0x34363248), yuv420p(tv, bt709/unknown/unknown, progressive), 1920x1080 [SAR 1:1 DAR 16:9], q=2-31, 23.98 fps, 23.98 tbr, 1k tbn
Metadata:
title           : undefined
Stream #0:1(eng): Audio: aac (LC) ([255][0][0][0] / 0x00FF), 48000 Hz, stereo, fltp, 259 kb/s
Stream mapping:
Stream #0:0 -> #0:0 (copy)
Stream #1:0 -> #0:1 (copy)
Press [q] to stop, [?] for help
frame=37574 fps=4568 q=-1.0 Lsize= 1145860kB time=00:26:07.21 bitrate=5989.5kbits/s speed= 191x
video:1096022kB audio:49478kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: 0.031468%
[INFO][ffmpeg Done]

[INFO] Done!
Additional Information
cli_default has been changed to fileName: \${showTitle}\S${season}\${showTitle} - S${season}E${episode} - ${title} so as to easily organize shows into folders.  When set to this, shows will not download.  when cli_default is set to fileName: ${showTitle} - S${season}E${episode} - ${title}, the shows download just fine.  I believe the issue stems from where the program creates the sub folders.  Instead of creating it in content: ./videos/ and fonts: ./fonts/, it creates them in the parent folder of the entire program.

Example:
When download normal code - C:\Users\rdkno\OneDrive\Desktop\multi-downloader-nx-1.0.0-win64\videos\Cautious Hero_ The Hero is Overpowered but Overly Cautious - S01E12 - The Hero Is Overpowered But Overly Cautious.mkv
When download folder code - C:\Users\rdkno\OneDrive\Desktop\multi-downloader-nx-1.0.0-win64\Cautious Hero_ The Hero is Overpowered but Overly Cautious\S01\
But unfortunately no episode is actually downloaded.

Works with funimation though for the folder orginization.

Remove that first \ from your fileName setting.  It doesn't need a leading one.

that worked, thank you very much, weird that funimation downloads didn't mind the first \ though


Test hello-world example with Android Emulator on CI

@Gordon-F Would you be able to help out? For quite some time now the CI seems to be unresponsive around adb install, timing out the job 3hrs after:
https://github.com/rust-windowing/android-ndk-rs/actions/runs/1452352305

I vaguely remember writing down some more info in https://github.com/rust-windowing/android-ndk-rs/pull/169, too.

@Gordon-F I bumped it from macos-10.15 to macos-latest in https://github.com/rust-windowing/android-ndk-rs/commit/b665be0ae32ebbab82b5c3079ea8d3ed90ca3962, and vaguely remember it started happening exactly since that patch. However:
https://docs.github.com/en/actions/learn-github-actions/workflow-syntax-for-github-actions#github-hosted-runners

The macos-latest label currently uses the macOS 10.15 runner image.

So it should not have made a difference?

Also, the emulator starts 3 times for 3 different tasks, if I understood everything correctly. Is it necessary? It seems to me that it would be more optimal to start it only 1 time and run all tests on it.

The broken run also shows that it was on 10.15:
Current runner version: '2.284.0'
Operating System
  Mac OS X
  10.15.7
  19H1419

Also, the emulator starts 3 times for 3 different tasks, if I understood everything correctly. Is it necessary? It seems to me that it would be more optimal to start it only 1 time and run all tests on it.

But we'd like to have a clean emulator for every artifact that we need to test. Could deinstall the application but that seems far from ideal. However, perhaps starting 3 of them instead of one is the problem "somehow" in scheduling?

But we'd like to have a clean emulator for every artifact that we need to test.

Android-emulator-runner docs suggest using a clean snapshot to speed up CI in this case. What do you think about it? It should speed up CI time and maybe help with the runner issue.

Yeah, we can try that :)

It's a bit strange because this shouldn't happen regardless (I kept the set -x from aforementioned PR #169, and it doesn't show anything out of the ordinary).

@Gordon-F It also seems to have been fixed by disabling animations, GPU etc from that page, see #198. We can add caching in a separate PR and see how well that speeds things up separate from fixing the regression lockup.


padding causal with conv1d gives an error

System information

I wrote custom code
System : Linux
TensorFlow 1.11
Keras version(embedded in TF) '2.1.6-tf'

It seems keras Conv1D (embedded in Tensorflow) does not support 'causal' in Conv1D contrary to what is stated in the class doc string in the code. Here is a simple code to reproduce
from tensorflow.python.keras.models import Sequential
from tensorflow.python.keras.layers import InputLayer
from tensorflow.python.keras.layers.convolutional import Conv1D
model = Sequential()
model.add(InputLayer(name='input_layer', input_shape=(5,3,)))
model.add(Conv1D(1, kernel_size=1, padding='causal'))

This results in the error
ValueError: Attr 'padding' of 'Conv2D' Op passed string 'CAUSAL' not in: "SAME", "VALID".

Any help please? (please notice I am trying to construct a Conv1D layer but the error mentions Conv2D

With tensorflow 1.13.1 I am not seeing the issue. Think the issue has been resolved?

Automatically closing due to lack of recent activity. Please update the issue when new information becomes available, and we will reopen the issue. Thanks!


Investigate benefits of upgrading & possibly upgrade to GraalVM 20.3

https://www.graalvm.org/release-notes/20_2/#2020

This version seems to address this issue that we were seeing: https://github.com/oracle/graal/issues/1306#issuecomment-516064882

@viktorklang, try out GraalVM CE 20.2.0 (build 11.0.8+10-jvmci-20.2-b03) specifically. I did run my Groovy examples using the newest GraalVM CE 20.2.0 (build 25.262-b10-jvmci-20.2-b03, mixed mode) - the OpenJDK 8u262 one, and it still does not work. I hope it works for you :)

Thanks for the tip, @wololock! :+1:

Worth tracking: https://github.com/oracle/graal/issues/2761

This issue of ours seem to have been recently closed:
https://github.com/oracle/graal/issues/2736
https://github.com/oracle/graal/issues/2369

Graalvm 20.3 has been released: https://www.graalvm.org/release-notes/20_3/

Minimal upgrade to 20.3.1 in #519. Leaving this issue open for any follow-ups and looking at upgrading to version 21.0.

Minimal upgrade to 20.3.1 in #519. Leaving this issue open for any follow-ups and looking at upgrading to version 21.0.


format unit support for non decimal percentage

Maybe add a spec? there's some existing specs for the class


No intellisense working at all

I have installed V on windows using the instructions from "Installing V from source" at https://github.com/vlang/v/blob/master/doc/docs.md#installing-v-from-source .
I have installed the plugin in VSCode and create a new V project using the "v new" command and opened the folder in VSCode.
Upon trying to use any intellisense (such as getting the type name of a sum type as shown here https://github.com/vlang/v/blob/master/doc/docs.md#sum-types) there is no intellisense at all.

Just a list of things already used or defined.
I have tried running VSCode as admin but insure what else to try. When trying to run the "Update VLS" command I am simply given a error which states
Spawning v ls --json --update...
Error: spawn v ENOENT

Unsure if this is relevant and what I am missing for this to work. Any help would be much appreciated.

Any news or update on this?

vls is unstable unfortunately
intellij v is much better, but we'll make vls just as stable
will take a couple of months though

*Not formally
Vuck, it veels like that VSCode is discriminated against by the community.

Same under Ubuntu 22. Simply doesn’t work anymore.
How can I help ? ( I’ve got 0 exp with vscode extensions )
Where do I need to start in your code ?