kill render-media (range-requests) and add floating player #2707
No reviewers
Labels
No labels
accessibility
app-parity
area: creator
area: daemon
area: design
area: devops
area: discovery
area: docs
area: installer
area: internal
area: livestream
area: performance
area: proposal
area: reposts
area: rewards
area: search
area: security
area: subscriptions
area: sync
area: ux
area: viewer
area: wallet
BEAMER
channel
comments
community PR
consider soon
core team
css
dependencies
electron
Epic
feature request
first-timers-only
good first issue
hacktoberfest
help wanted
hub-dependent
icebox
Invalid
level: 0
level: 1
level: 2
level: 3
level: 4
merge when green
needs: exploration
needs: grooming
needs: priority
needs: repro
needs: tech design
notifications
odysee
on hold
playlists
priority: blocker
priority: high
priority: low
priority: medium
protocol dependent
recsys
redesign
regression
resilience
sdk dependent
Tom's Wishlist
trending
type: bug
type: discussion
type: improvement
type: new feature
type: refactor
type: task
type: testing
unplanned
windows
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference: LBRYCommunity/lbry-desktop#2707
Loading…
Add table
Reference in a new issue
No description provided.
Delete branch "not-streaming-but-streaming"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
By no means is this file viewer/purhcase logic code good, but this is sure as hell better than it was before.
The plan
Merge this shit before anyone can take a really close look at thisI'm happy with this now. It should be a lot easier to work moving forward.Things to actually do before this is ready
.lbry
file supportThis is ready. I'm going to wait to add analytics in a different PR. Just so we can get a little testing on this to see if anything crazy needs to change before I update this new
play
api. It should be fairly easy to add for all file types now.@tzarebczan Can you add some help text for this setting?
Slightly hastier review than I would have liked, but wanted to get something back to you today. I also did not run the code. I'd still like to do this, but do not let me block.
Is
blobs_completed
a number or a boolean? this contrasts with https://github.com/lbryio/lbry-desktop/pull/2707/files#diff-90966bed4cd947a3f12fa8f891fd193aR35 below@ -148,3 +101,4 @@
const source = IS_WEB ? `https://api.lbry.tv/content/claims/${claim.name}/${claim.claim_id}/stream` : streamingUrl;
// Human-readable files (scripts and plain-text files)
const readableFiles = ['text', 'document', 'script'];
does the creation of
mediaTypes
trigger the instantiation/invocation of the individual components? or is that deferred until the element is used in some way? (I think it's the latter, but making sure)out of scope for this PR, but I wonder if putting all of these on the
Lbry
object is the right design@ -0,0 +11,4 @@
const SANDBOX_TYPES = ['application/x-lbry', 'application/x-ext-lbry'];
// This server exists in src/platforms/electron/startSandBox.js
const SANDBOX_SET_BASE_URL = 'http://localhost:5278/set/';
are these important enough configuration values that they should be hoisted to top-level config of some kind? does anything else use them?
@ -0,0 +52,4 @@
src={appUrl}
autosize="on"
style={{ border: 0, width: '100%', height: '100%' }}
useragent="Mozilla/5.0 AppleWebKit/537 Chrome/60 Safari/537"
can this be read from Electron?
Add 0.25, 0.75, and 1.1 (assuming no or minimal UI cost or other costs)
YouTube does 0.25 and 0.75 and I've found 1.1 is not very perceptible but still saves meaningful time
can 53-59 just be:
videoNode.paused ? videoNode.play() : videoNode.pause()
Check boxes always enable, so you do not need to put this in the label. Present tense is better:
"Save all viewed content"
Helper text:
"Content is saved to downloads directory. Paid content and some file types are saved by default. Changing this setting will not affect previously downloaded content."
Possibly the first sentence of helper would be better in label, or something close to this. Try both.
Rewrite similar to above, "Save..."
i18n
I've seen a few fileInfo checks similar to this, consider if it makes sense to combine into a selector (it might not).
why always save if cost > 0? I would not expect this
return is avoidable if made into 3 nested if
@ -102,3 +102,3 @@
export const selecetMute = createSelector(
export const selectMute = createSelector(
selectState,
👌
It is a number, good catch
@ -0,0 +11,4 @@
const SANDBOX_TYPES = ['application/x-lbry', 'application/x-ext-lbry'];
// This server exists in src/platforms/electron/startSandBox.js
const SANDBOX_SET_BASE_URL = 'http://localhost:5278/set/';
Nope, they exist entirely for this app viewer
Nice. Much cleaner
IMO nested if statements are harder to skim and understand. Especially when one of the if statements does something else.
Especially during this new video player refactor, the hardest parts to follow were blocks with nested if statements.
So one if/else is okay, but a third means use an early return?
I don't hate this but I do think this will result in idiosyncratic code because I doubt others are following this paradigm
However, debating this is classic bikeshedding, so ship whatever you want
Blobs completed is a count
Saw it was resolved but not fixed yet
We also have the file name with extension in the claim data now, but we should fall back to file list when it's not available
Will add it today.
@ -148,3 +101,4 @@
const source = IS_WEB ? `https://api.lbry.tv/content/claims/${claim.name}/${claim.claim_id}/stream` : streamingUrl;
// Human-readable files (scripts and plain-text files)
const readableFiles = ['text', 'document', 'script'];
If download path exists and the file is completed, we should use that for the video and audio player.
@ -0,0 +52,4 @@
src={appUrl}
autosize="on"
style={{ border: 0, width: '100%', height: '100%' }}
useragent="Mozilla/5.0 AppleWebKit/537 Chrome/60 Safari/537"
Possibly. I haven't spent any time looking into that, just copy pasting it from the old file
Since that only has some of the media types, I don't think it's worth it to use for now, especially since it's working pretty well.
And yeah, this is probably better as a regular utility function?
@kauffj this is ready for another review
I gave up on mute/volume/position memory, will circle back after this is merged but I'd rather get this in so I can start on the other tickets before the release.
I would just look at the last commit
2b09d56b63
I responded to your change requests and did all the floating player stuff in that one commit.
@seanyesmunt I heard the answer to this but I still question it. I say remove.
Code can be shipped, but some UX feedback left in Slack