Some video players like VLC or PotPlayer support proving the timecode as a parameter. It would be really helpful if it would be possible to do that from Video Hub App (e.g. when using the video strip).
I like this idea a lot -- I had this as an idea to implement someday. Good to know there's external interest in this feature. As I'm trying to get version 2.0.0 through the door, I might put this feature off until a minor release.
The work involved:
It doesn't seem like a lot of work -- if I can get it done in an hour without running into annoying trouble, I'll put it into 2.0.0 ๐ค
Awesome! Thanks for the quick response.
Although it would probably require more than a toggle. Each player will require the timecode in a different format and/or using a different parameter. Adding a textbox to enter the full path to the player and the parameters to be used would work. It would also require a variable for the timecode. PotPlayer, mplayer and VLC all accept the timecode as total seconds.
Good to know -- I was hoping there was some consistency across media players.
I think the most common one must be _VLC_ though I personally use _MPC-BE_
If you have suggestions for where to look on popularity of players (or just your personal guess) so I could grab the top 2 or 3 - I could look into them ๐
PotPlayer uses /seek=seconds.
VLC uses --time=seconds.
MPC uses /startpos <miliseconds> or /start <hh:mm:ss>.
mplayer uses `-ss time'.
VLC is most likely the most popular player. I didn't find any lists that actually go by downloads or number of installations or such.
So I guess having the user provide the command line would be easiest. It's flexible and you don't have to care what player the user actually uses. As you can't know which player is associated with the file being opened I don't see any other way of getting this done properly.
I tried building the app with electron-builder but got nowhere (so far only used Angular in a gulp project with JS only for the frontend). Otherwise I would offer to help out here. Thanks again.
Sorry to hear you had trouble with _electron-builder_
I just tried out (to check) and was able to build the app on both _Windows_ and _Mac_
I've not touched the _Linux_ build in over a year -- so I suspect that may be broken.
electron-builder version=20.44.4
Please let me know if you'd like any assistance -- I'd like my repository to be buildable ๐
It's Windows. I just downloaded yarn, then installed electron-builder and ran that and got this:
electron-builder build
โข electron-builder version=20.44.4
โข loaded configuration file=C:\temp\Video-Hub-App\electron-builder.json
โข writing effective config file=release\builder-effective-config.yaml
โข no native production dependencies
โข packaging platform=win32 arch=x64 electron=5.0.7 appOutDir=release\win-unpacked
Error: Application entry file "main.js" in the "C:\temp\Video-Hub-App\release\win-unpacked\resources\app.asar" does not exist. Seems like a wrong configuration.
at error (c:\temp\Video-Hub-App\node_modules\app-builder-lib\out\asar\asarFileChecker.js:44:14)
at c:\temp\Video-Hub-App\node_modules\app-builder-lib\src\asar\asarFileChecker.ts:30:4
at Generator.next (<anonymous>)
at callback (c:\temp\Video-Hub-App\node_modules\graceful-fs\polyfills.js:295:20)
at FSReqWrap.oncomplete (fs.js:154:5)
From previous event:
at _checkFileInArchive (c:\temp\Video-Hub-App\node_modules\app-builder-lib\src\asar\asarFileChecker.ts:36:17)
at checkFileInArchive (c:\temp\Video-Hub-App\node_modules\app-builder-lib\out\asar\asarFileChecker.js:40:30)
at c:\temp\Video-Hub-App\node_modules\app-builder-lib\src\platformPackager.ts:409:13
at Generator.next (<anonymous>)
From previous event:
at WinPackager.checkFileInPackage (c:\temp\Video-Hub-App\node_modules\app-builder-lib\src\platformPackager.ts:406:110)
at c:\temp\Video-Hub-App\node_modules\app-builder-lib\src\platformPackager.ts:460:16
at Generator.next (<anonymous>)
at callback (c:\temp\Video-Hub-App\node_modules\graceful-fs\polyfills.js:295:20)
at FSReqWrap.oncomplete (fs.js:154:5)
From previous event:
at WinPackager.sanityCheckPackage (c:\temp\Video-Hub-App\node_modules\app-builder-lib\src\platformPackager.ts:446:92)
at c:\temp\Video-Hub-App\node_modules\app-builder-lib\src\platformPackager.ts:249:16
at Generator.next (<anonymous>)
at runCallback (timers.js:705:18)
at tryOnImmediate (timers.js:676:5)
at processImmediate (timers.js:658:5)
From previous event:
at WinPackager.doPack (c:\temp\Video-Hub-App\node_modules\app-builder-lib\src\platformPackager.ts:167:165)
at c:\temp\Video-Hub-App\node_modules\app-builder-lib\src\platformPackager.ts:113:16
at Generator.next (<anonymous>)
From previous event:
at WinPackager.pack (c:\temp\Video-Hub-App\node_modules\app-builder-lib\src\platformPackager.ts:111:95)
at c:\temp\Video-Hub-App\node_modules\app-builder-lib\src\packager.ts:430:24
at Generator.next (<anonymous>)
at xfs.stat (c:\temp\Video-Hub-App\node_modules\fs-extra\lib\mkdirs\mkdirs.js:56:16)
at callback (c:\temp\Video-Hub-App\node_modules\graceful-fs\polyfills.js:295:20)
at FSReqWrap.oncomplete (fs.js:154:5)
From previous event:
at Packager.doBuild (c:\temp\Video-Hub-App\node_modules\app-builder-lib\src\packager.ts:396:24)
at c:\temp\Video-Hub-App\node_modules\app-builder-lib\src\packager.ts:366:57
at Generator.next (<anonymous>)
at c:\temp\Video-Hub-App\node_modules\graceful-fs\graceful-fs.js:111:16
at c:\temp\Video-Hub-App\node_modules\graceful-fs\graceful-fs.js:45:10
at FSReqWrap.args [as oncomplete] (fs.js:140:20)
From previous event:
at Packager._build (c:\temp\Video-Hub-App\node_modules\app-builder-lib\src\packager.ts:335:133)
at c:\temp\Video-Hub-App\node_modules\app-builder-lib\src\packager.ts:331:23
at Generator.next (<anonymous>)
at runCallback (timers.js:705:18)
at tryOnImmediate (timers.js:676:5)
at processImmediate (timers.js:658:5)
From previous event:
at Packager.build (c:\temp\Video-Hub-App\node_modules\app-builder-lib\src\packager.ts:288:14)
at build (c:\temp\Video-Hub-App\node_modules\app-builder-lib\src\index.ts:59:28)
at build (c:\temp\Video-Hub-App\node_modules\electron-builder\src\builder.ts:228:10)
at then (c:\temp\Video-Hub-App\node_modules\electron-builder\src\cli\cli.ts:49:19)
Unsure ๐คทโโ I've not tried things with _yarn_
I don't think _yarn_ will use _npm_'s _package-lock.json_ and so it might download slightly different dependencies.
I've not updated _electron-builder_ in a while as it might have some breaking changes (at least for the Linux build) -- I'll be updating it when I'm done polishing the app, just before _2.0.0_ release ๐
If you'd like to build the app, consider trying _npm_ at least for this project ๐ I like _yarn_ too, but I started with _npm_ and don't think I'll change anytime soon.
ps - _yarn 2_ is coming ๐ https://github.com/yarnpkg/berry
The key line I see where things go wrong for you is:
Error: Application entry file "main.js" in the "C:\temp\Video-Hub-App\release\win-unpacked\resources\app.asar" does not exist.
When I build the app, there's a new folder that gets created release and then win-unpacked gets generated by the builder. Perhaps something went wrong with some script somewhere and the release folder doesn't get created automatically? ๐คทโโ
There's actually a release folder and an EXE inside which was built. When I start it I get the same error message.
I just used yarn because it was recommended by electron-builder. I'll try it with npm :-)
Alright, got it. At first it didn't work with npm either (just running electron-builder build).
I took a look at the package.json (which contains the line "main": "main.js", which explains why electron-builder was complaining of that file not being available). I got it running (or to build) using the several command lines from the script section, e.g. npm run build:prod && electron-builder build --windows.
I don't have a lot of free time right now, probably not enough to immerse myself into another project, but who knows...
By the way, I absolutely adore your "commercial" model with all the proceeds going to charity.
Thanks for sharing how you got things to work.
Keep in touch ๐
@theotherp -- you caught me just at the right time ๐
I just checked out the branch to take a look. I don't know if you're aware or if you would want a new ticket for this, but here goes:
The thumbnails are not displayed because the path is not built correctly. The main folder is e:\Download\VideoHubApp\Test\ while e:\Download\VideoHubApp\Test\vha-Test\ contains the three folders for the clips, filmstrips and thumbnails. The path used is e.g. ' file:///E:/ownloadVideoHubAppTest/vha-Test/thumbnails/82655a64759cffb1d0cdb17b8878123a.jpg'. I think the backslashes in folderPath must be escaped or replaced with slashes. I set a breakpoint at preview.component.ts and corrected the path (replacing the backslashes with slashes) and the images are shown.
Thank you for the bug report -- I've long been meaning to go across the entire app looking at the \ & / discrepancies -- the code related to it has been updated numerous times over the year (since the official 1.3.0 release) with quick bugfixes rather than explicit grand architecture.
I appreciate the data point ๐
I think there are still lingering problems when the hub has a space in it, etc ๐
_master_ has been updated to open videos at location where screenshot was taken ๐
See #250 for details (only works on 3 apps on Windows and 1 app on Mac -- PRs welcome to make it work with other players; I'm not currently planning on adding others unless requested).
I'll be looking into the folder path issues next ๐
@theotherp -- I'm starting a PR to fix this and other issues: #251
Currently _WIP_ but will hopefully be fixed shortly.
I have not yet been able to replicate the error where the slashes are not correctly escaped as you had:
file:///E:/ownloadVideoHubAppTest/vha-Test/thumbnails/82655a64759cffb1d0cdb17b8878123a.jpg
It looks like the D in "Download" got removed because it was preceded by \ -- I'll keep looking in my code where that could have happened ๐
I remember coming across this bug before but feel like I may have fixed it.
Is it happening on a hub created while running app from current _master_?
Feel free to create a separate issue or keep the conversation here ๐
@theotherp -- I cleaned up some more code relating to paths with #251
If you have the time, please see if you can replicate the issue ๐
If the issue only occurs on hubs that were created previously (not with _current_ master) then it's not a problem, but if you can replicate with a newly created hub, then I'd love to fix that ASAP ๐
Hi, sorry, same problem as before :-(
Also, I've enabled the option to open the video files at a timestamp. VLC is opened with a timestamp parameter but the timestamp is wrong (always 0).
Looks like the thumbIndex (line 840 in home.component.ts) is undefined.
Thank you -- I was able to reproduce things just now!
The error occurs upon the creation of the file, but not upon a re-opening of the file
file:///C:/temp%20folder%20with%20spaces//vha-testing
looks like there is an extra slash ๐ -- should be able to fix somehow ๐
I just checked against my VLC and was able to open at timestamp ๐ค
In the app when I select VLC I see:
C:\Program Files\VideoLAN\VLC\vlc.exe
Open-at-location will only work in _thumbnail_ view when the setting is enabled.
You're right that thumbIndex can be undefined -- it's accounted for in line 873 (line 849 calls openVideo and the 2nd param is optional). If the index is not present, the timecode is set to zero.
Please let me know if you can't get the video to open at the correct location from the _thumbnail_ view.
๐ this reminds me -- I forgot to include that in the button description -- that it _only_ works in Thumbnail or Details views
UPDATE: odd -- open at location was broken on VLC but not on MPC when I _just_ checked, but then I checked VLC again and it was working as desired ๐ -- I'll have to check again before release.
Figured out why it fails on first scan:
main.ts on line 749 didn't have the newly-added getHtmlPath method wrapping the string sent to Angular ๐
Should be fixed with #252 ๐
Hate to be the bearer of bad news, but same problem as before. file-path.service.ts returns file://E:\Download\VideoHubApp\Test/vha-t/thumbnails/82655a64759cffb1d0cdb17b8878123a.jpg which should be file://E:/Download/VideoHubApp/Test/vha-t/thumbnails/82655a64759cffb1d0cdb17b8878123a.jpg. It actually works without path.normalize().
Timestamp seeking does indeed work from the thumbnail view. I expected it to work from the filmstrip view as well, but that's alright :-)
Thank you for reporting in! Definitely want to fix this ASAP ๐
Will look later today ๐
I don't think figuring out which thumbnail the user is clicking from the _filmstrip_ view will be easy (since the thumbnails slide under the mouse as you move it), and I might need to do the calculation with the width of the filmstrip, etc. I'll give it a go -- if it's solvable in under 30 minutes I'll include it ๐
Couple of comments:
1) IINA is very popular for MacOS - based off mpv
2) The custom command option would be very nice (allowing users to add say %time% in their command and the app would replace and run it)
3) The app does work and build on linux - I run it all the time on my server! ๐ (I also have the travis-ci code for all 3 platforms as well)
Most helpful comment
Couple of comments:
1) IINA is very popular for MacOS - based off mpv
2) The custom command option would be very nice (allowing users to add say %time% in their command and the app would replace and run it)
3) The app does work and build on linux - I run it all the time on my server! ๐ (I also have the travis-ci code for all 3 platforms as well)