* GoogleVideo: add more metadata
* GoogleVideo: fix `contentUrl`
`contentUrl` needs to be the url of the video file itself, not the page or some redirect. Copied the way the url is generated in the RSS code.
* Fix adnim ads
* Adjust ad container width
* Change widget on mobile
* Fix 3 column grid
* Ad ad banner top bar
* Ad ad banner bottom bar on mobile
* Ad ad banner bottom bar radius on mobile
* Adjust ad banners on mobile
* Make some mobile adjustments
* Remove dbeug box
* Combine ad classes
## Issue
Stickly loads fine when Category Page is opened directly (F5, open), but doesn't load if F5 was at Homepage and then navigated into Category Page.
## Root
There is a bug where AdsSticky cannot be loaded on a page where AdsBanner exists. As long as AdsSticky is loaded in a page without AdsBanner, they both can still be visible together later, says from navigating around.
## Temp fix
Adding inAllowedPath to the logic is a band-aid that relies on AdsBanner only being used in Homepage for now, which we currently happen to not place AdsSticky.
## Ticket
1583: "add incontent ads to category/channel pages (break up every X claims?), or add back bottom ad in those areas."
## Behavioral changes
- Hide when in homepage (as currently we have ads between categories).
- Fix the light theme (it was transparent).
## Code changes
- While an Effect is the 'right' choice given that there is no jsx to mount, the need to prop-drill from the parent was getting a bit annoying, so converted to a Component instead.
- Remove the delay for Core Vitals avoidance for now -- seems to make the sticky less likely to serve an ad.
- Now that the membership state is correctly populated for incognito (see 9d830615), there is no more need to check for `isAuthenticated`.
Using that global variable was a bad idea. Stick to redux as the source of truth.
The flag is not listed for rehydration, so it will always start off as `undefined`, which is what we need anyways.
`undefined` indicates we haven't tested for ad-blockers, so we'll run the fetch and update the store with a true|false value.
It would be nice if the individual components can handle the remounting of the ad-script, but there is currently a need to synchronize the cleanup of the `window.OBR` object.
The quickest solution for now is to add a key at the parent side to synchronize the mount-unmounting. Not ideal -- revisit later.
- This increases the amount of ads, filling up the entire width. No more need to restrict with `max-width` ourself.
- Changed the ad-driver to top-right since the "Powered by Outbrain" text is now locked in bottom-right. Also made the container having a minimum height, as the method to "display the driver after ads are loaded" is not future proof -- it depends on the IDs being used by the ad. Reserving some space seems to be easiest, and it also reduces shifts as well.
## Behavior in homepage
- Mobile: show after every other category
- Desktop: show after first category, then every 2 categories.
## Known issue:
- "FYP" is not part of the categories array at the moment, so it does mess up the behavior.
## Notes
I think this is also called "in-content" by adnim (not 100% sure of the terminology).
## Ticket
1572
Always check for availability before use.
## Changes
- Consolidated the keys into one place for easier tracking.
- It'll also be easier to code using constant autocomplete.
- Cleaned up the wrapper to be as close as the original.
- Updated existing code to use the wrapper (even if they already handled the availability) to encourage future code to just use the wrapper.
1. Hardcoding breaks any image changes done on dev instances or locally.
2. The relative path is bad, and there are few more instances of it. But continue as is for now, will file a ticket to fix this.
3. Fix caching.
This requires an accompanying commit in the homepages repo (see "Add announcement support").
Using `raw-loader` to import markdown files as a string works for the app-side, but didn't work well in web-side. Falling back to copying the announcement files to `dist` and reading them via `readFileSync`. Don't really like this -- will return with an alternative.
This reverts commit f6f15531d4.
The root-cause was known (8dd0982f), and I don't think it worked because:
1. The issue happened at the web side which didn't have logging.
2. The `[object Promise]` came after the `get`, not before.
## Issues from the initial attempt
- There are 2 versions of `Lbry` and `buildURI` -- the app and web-server version. There are subtle differences between them, and for the app case, importing the web-server version results in a query into an invalid URL.
- It changed the function from returning a string to returning a promise.
## Changes
- Since the new function (renamed to `fetchStreamUrl` for clarity) is currently only needed for web-server, I moved it into the `web` folder to avoid misuse in app.
- Await on the promise. Unfortunately, this also means the entire chain of function calls need to be adjusted to be `async`.
1446
- Requires an accompanying commit in `odysee-frontend`.
- The change assumes that the `odysee-frontend` is the only project that uses these files directly, i.e. other clients will use the API instead.
## Issue 1263
Previously, we tried to inform the user that when an SDK call such as `support_create` and `publish` fails (specifically, timed out), the operation could be successful -- please check the transactions later.
However, we only covered the case of `fetch` actually getting a response that indicated a timeout, e.g. "status = 524". For our SDK case, the timeout scenario is an error that goes into the `catch` block. In the `catch` block, we can't differentiate whether it is a timeout because it only returns a generic "failed to fetch" message.
## New Approach
Since `fetch` does not support a timeout value, the usual solution is to wrap it with a `setTimeout`. This already exists in our code as `fetchWithTimeout` (yay).
By setting a timeout that is lower than the browser's default and also lower than the SDK operation (90s for most commands, 5m for `publish`), we would now have a way to detect a timeout and inform the user.
Firefox's 90s seems to be the lowest common denominator ... so 60s was chosen as the default (added some buffer).
For the case of 'publish', it is actually called in the backend, so wrap the xhr call with a timeout as well.
Ticket: 1386
The code was caching the first result and returning that.
We would expand the cache for multiple files, that that also require checking if the file has changed, so just read the content every time -- I think the file is small enough?
Re-used lots of Anthony's code + made fixes to a few areas including the publish page.
a
new videojs
video.js@7.18.1 + http-streaming@2.14.2
remove console log
