Fix autoplaying #136
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#136
Loading…
Add table
Reference in a new issue
No description provided.
Delete branch "autoplay"
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?
Fixes having to click play twice. We have an
autoplay
variable but I don't see where it's getting set, so right now no files will actually autoplay still.The logic is more confusing than it ought to be, partially due to poor variable naming, but I believe
autoplay
is set to true when a user clicks the video cover that appears while a video is loading. This is the only case that autoplaying should happen. So I'm not sure this is the right fix.ah, well that's much easier then @kauffj. We can just cut out that autoplay stuff and always play the video when the
VideoPlayer
component is rendered, as it's only rendered when it should be playing anyway. Changes pushed.The video player is now rendered automatically if you have already
downloaded the file. So if you are accessing the show page for a URI you've
downloaded previously, it shouldn't autoplay.
On Fri, May 26, 2017 at 5:07 AM, 6ea86b96 notifications@github.com wrote:
--
Jeremy Kauffman, Founder, LBRY http://lbry.io/
(267) 210-4292
Build LBRY: get https://lbry.io/get, follow https://twitter.com/lbryio,
like https://facebook.com/lbryio
The VideoPlayer isn't rendered until the file is downloaded/ready to play and isPlaying is true in the Video component https://github.com/lbryio/lbry-app/blob/master/ui/js/component/video/view.jsx#L115
so this commit does actually work. If you downloaded a file, readyToPlay is true but isLoading and isPlaying are false. If a stream is loading then the fileInfo is still null so readyToPlay is false. I haven't been able to break the player in any testing so far.
ok, so it seems like it's not working when you purchase new content. Will look into a fix.
Turns out that this is a pain to fix. We have 2
affirmPurchase
modals. One on the file actions and one on the video player. I wanted to hook into the confirmed method to start the video playing but actually the modal on the file actions is the one being displayed.Seems like we're either going to need to refactor the modals a bit or move the currently playing file into redux, or both.
My thought process here would be to move a list of URIs approved for purchase into redux rather than the currently playing file.
Missed your comment earlier @kauffj. I pushed something that works here, but it's a little hacky. For now I just added an option to pass the modal name into the purchase action so we render the correct one.
I also fixed the file buffering issue. I broke that when I switched players. Turns out that playing downloading file streams isn't so easy. Luckily http://webtorrent.to have a similar issue and have created a lib for that. https://github.com/feross/render-media. Seems like a good idea to use? It picks the correct video playback lib to use depending on the file type, and audio/pdf/etc too. Seems like we could change the
Video
component to be aMedia
component later and just allowrender-media
to render whatever we throw at it?I like the approved for purchase state list though. That's a much better solution :)
Also, although
render-media
handles fallback depending on file types and errors on thevideo
element, it doesn't catch errors in the audio. There's something wrong with the Coherence movie for example, where it blows up in the mp4 remuxer. Going to have to find some way to catch those errors.@ -147,3 +154,3 @@
return (
<video controls id="video" ref="video" style={{backgroundImage: "url('" + poster + "')"}} >
<video controls ref="video" style={{backgroundImage: "url('" + poster + "')"}} >
<source src={downloadPath} type={contentType} />
This import doesn't appear to be used.
@reillysmith see @6ea86b96's comment above re: Coherence - do you know if that is from us encoding or if that is in the original encoding?