* Resolve claim and stream types when there is a filter
## Symptom
Channel Page 'Content Type' filter not working
## Issue
The Advanced Filter work by placing a `?content=` URL param. The list component then parses it and makes the `claim_search` params accordingly. But:
1. There is a mix up in how the list component treats `?content=`.
- The original code seems to treat this as a way to define the type externally but only for a list without `claimType` defined via code. In other words, if `claimType="something"`, `?content=` is ignored.
- On the other hand, the Advanced Filter relies on `?content=` being used.
2. `?content=` is then split between `claimType` and `streamType`. The current code does not check if the split makes sense, e.g. if `?content=channel` and `streamType=['video']`, these 2 are incompatible and produces no results.
## Change
1. I'm not really sure what's the original intention, but let's just make `?content=` as an override/filter.
2. `?content=` should probably be limited to always be a subset of `claimType` and `streamType`. But this seems complicated to do, so for now let's just make always override/filter everything. For that, we need to make sure the filtered `claimType` -- `streamType` combo makes sense.
* Fix 'Channel' filter not working in Wild West
## Cause
The Wild West list defines `release_time` to be 1 week ago. As long as this parameter exists, a channel `claim_search` produces no results (I thought channels have creation dates?). That is why an unfiltered Wild West never showed Channel Tiles.
## Change
The existing `release_time` handling does seem to hint that we should not set the parameter when searching for Channels. Expanded that to consider the final (filtered) claim type, not just the original.
## Issue
After enabling Advanced Filter in Category Pages, the 'Content Type' filter only works for "repost/video/list".
## Root-cause
When `streamType` is not provided, it defaults to 'Video|Audio', making it always "defined":
```
streamType = SIMPLE_SITE ? [CS.FILE_VIDEO, CS.FILE_AUDIO] : undefined,
```
This seem to override the purpose of `defaultStreamType`, which will not be used unless the client explicitly set `streamType=null`, which currently is only being applied for `RECENT_FROM_FOLLOWING[]`.
```
const streamTypeParam =
streamType || (CS.FILE_TYPES.includes(contentTypeParam) && contentTypeParam) || defaultStreamType || null;
```
The quality API doesn't work on the default PNG but works on JPG.
- Switching to JPEG (100%) produces a smaller image than the default PNG. This covers most scenes.
- For some scenes, the size could still be larger than 2MB, so retry with JPEG (80%). For a 1080p image, this action produces the file at <1MB range. The quality still looks ok, I think.
Completely remove any assumptions of multi-tab uploading from server status (should have done it previously, but wanted to be conservative). This should make it less confusing to the user.
The real issue still remains -- the upload is somehow locked at the backend.
Also, when we override the error to present a user-friendly message to the user, pass the original error to the log (just in case it gives extra info).
From the logs, it seems like the second retry (5s) fixes the "normal" cases, so just remove the first retry (0s).
Also from the logs, if a retry doesn't work by the third attempt (10s), it's most likely the "locked" case and retrying further doesn't help. So, reduce one more useless retry attemp.
Removed logging since we've gathered enough data, and that this hook is expected to be hit a lot, so we don't want to clog the logs.
* Add ordering Icons
* Refactor doCollectionEdit
- It required claims as parameter, when only uris are used to populate the collection, so that was changed to pass down the uris instead.
- There were unused and mostly unnecessary functions inside, for example the parameter claimIds was never used so it would never enter the claimSearch function which again would be used to generate uris, so it's better to just use uris as parameter
* Add List Reordering changes
* Add toggle button for list editing
* Add toggle on content page collection sidebar
* Enable drag-n-drop to re-order list items
https://www.youtube.com/watch?v=aYZRRyukuIw
* Allow removing all unavailable claims from a List
* Fix <g> on icons
* Fix section buttons positioning
* Move preventDefault and stopPropagation to buttons div instead of each button, preventing clicking even if disabled opening the claim
* Change dragging cursor
* Fix sizing
* Fix dragging component
* Restrict dragging to vertical axis
* Ignore shuffle state for ordering
* Fix console errors
* Mobile fixes
* Fix sidebar spacing
* Fix grey on mobile after click
## Issue
656 Automatic language detection can't recognize de-DE as de
## Note
We do fallback to the main language, but seems like the code got lost ... not sure when, but probably during the CN/TW or PT-BR support. The refactor in 81e47300 still did that, but the refactor was reverted due to some compilation issue (should revisit that someday).
## Change
Put back equivalent code.
* Tooltip: add 'followCursor' and 'placement' option
When used on a `<span>` with short text but large empty area, the location of the tooltip was at the bottom-center of the area, which isn't ideal.
I think 'followCursor' should be the default, but making it optional for now to minimize testing.
Also added the 'placement' prop -- for the span case again, the mouse cursor is blocking the tooltip.
* View/Follower count: only use compact when > 10k
## Issue
Received complaints -- some people prefer to see full resolution.
## Changes
- As a compromise, we'll only apply the compact notation when the value is greater than 10k, with the exception of Tile View Count, where we'll always apply it due to space limitation.
- Also added Tooltip for Follower count.
## Fixes
- The string was always in 'en' locale in some instances, so it wasn't grouping up digits properly in Japanese (groups of 4), for example.
## Issue
When "Upcoming livestream" appears in a list, infinite scroll stops working.
## Cause
The difference between `mainEl.getBoundingClientRect().bottom` and `window.innerHeight` became slightly greater than 0.5, so it was deemed as "haven't reached the bottom".
## Change
Coincidently, I've been wanting to make the inf scroll load earlier (instead of after reaching the absolute bottom) to make the experience smoother, so added a 200px threshold, which is roughly the height of a tile. This gets us the new behavior while also fixes the original problem.
## Background
Per developer of `tus-js-client`, it is normal to occasionally encounter upload errors. The auto-retry mechanism is meant to address this.
While implementing tab-lock to prevent multiple uploads of the same file, 423_locked was used to detect this scenario. But 423_locked could also mean "the server is busy writing the chunk" (per discussion with Randy), so we kind of disabled the auto-retry mechanism accidentally.
Meanwhile, from a prior discussion with Randy, one of the chunk-writing duration took 3 minutes. Our current maximum of "retry after 15s" wouldn't help.
## Change
1. Given that tab-locking was improved recently and no longer reliant on the server error messages (we use secure storage to mark a file as locked), reverted the change to "skip retry on 409/423". This is now back to normal recommended behavior.
2. `tus-js-client` currently does not support variable retry delay, otherwise we could prolong the delay if the error was 423. Since we know it could take up to 3 minutes, and that we don't know if it's file-size dependant, just add another 30s retry and put a friendlier message asking the user to retry themselves after waiting a bit.
- activeChannelClaim is the comment creator, not receiver.
- doSeeNotifications marks a notification as "seen", and not "send a notification".
- Removed comments that are just explaining the syntax.
* Test out a horizontal scroll for upcoming (tile only for now)
* - add support for list layout
- add following label on home page
- clan up css and naming conventions
* Update header type + show only if scheduled streams are showing
Our current chunk size is 25,000,000.
Google and S3 documentation suggests the chunk size to be multiples of 256KiB. MongoDB too. We aren't using any of those, but I guess no harm doing the same. From the logs, the values "25,000,000" and "50,000,000" seems to be common.
