## Ticket
1329
The existing nudge to refresh the webpage only happens when the app cannot find the specific javascript file in the server. As we don't purge the files on each build, the browser typically uses the cached version of the app, which could be weeks behind (based on the error logs).
## Approach
Poll the current version periodically (set to 1 hour for now) and invoke the nudge when a newer version is detected.
We typically don't need to bump `MINIMUM_VERSION` unless there is an urgent need to make users move away from older versions (e.g. API changes, mistakes, etc.)
## Trade-offs
Wanted to put the value in a separate file called `.min.version` so that the env's history won't be polluted with version bumps, but not sure how to implement with minimal code without having to read from the file. Getting from the env is the easiest to implement (per my limited knowledge).
And function name - was confusing that we had 2 with different paths.
Use 1280x720 to improve caching (used on mobile/tablets). There's no real spec for size.
## Issue
Due the `parseUri` not being used in a try-catch block, the thrown error surfaces all the way up and the 500 catch-all status was used.
The search console was been complaining about this for a while now. I've always thought "what's the problem here, you entered the wrong claim format", but now I realized it's about the error code.
## Change
`try-catch` the call as normal for that function, and return 404. We will still relay the error message it was.
## Issue
- When `/$/download/:claimname/:claimId` is invalid, it results in a bad redirect loop that keeps requesting the same thing. Eventually it stops, though.
- When `/$/stream/:claimname/:claimId` is invalid, it results in a 302 page that simply says `Redirecting to .`, and is increasing in count in the search console.
## Fix
Return a 404 not found for these.
* 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.
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.
## 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.
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
Ticket: 1318
Had to create v2 as there is no backward-compatible location in the v1 json to place it.
v2 allows any future expansion beyond 'categories' and 'meme'.
One-meme-per-homepage is also supported, but not enabled for now.
The fn version was only needed for Search Page, and that was making it hard to move the metadata to the homepage repo.
Revert back to original, then handle Search separately.
## Issue
`/$/embed/尾崎豊--－-大阪球場ライブ%E3%80%801_6/bfd63daa9453bb1a11674ca8a7c5f5dd6b49d024?r=2ituZftpdG18f1TBADDbCaaEZ9ecYYYm` wasn't working
## Change
Probably need to revisit this properly, but for now, grab the `requestPath` that's needed for resolving before escaping the characters.
Tested that `http://localhost:1337/$/search?q=%22\/%3E%3Cimg%20s+src+c=x%20on+onerror+%20=alert(1)+\%3E` would still be blocked.
