Twtube

[duche...@gmail.com]

I'm running Tiddlywiki 5.1.22 on node.js v12.14.1 and trying to install Twtube plugin from https://github.com/TheDiveO/TwTube.

Sorry I'm far from being a js developer and probably missing basic js and node knowlegge.

After I git cloned the directory above, cd into it and ran install I try to start it with "npm start".

The media server seems to start but then issue an error message about an undefined property "addroute", see the attached image.

Any help will be appreciated.  Thank you.

[Donald Coates]

So I just went to the live demo and downloaded the tid then dragged it into a standalone wiki and it worked fine.  I think the instructions are for development?  I realize you are using a nodejs server which may work differently but maybe just try dragging the tid 'into' your server, reloading, and testing.

[Donald Coates]

Okay I went ahead and just did it on my nodejs server.  Did just like I said below and again it worked fine, as you can see here

On Thursday, December 3, 2020 at 3:24:23 PM UTC-5 duche...@gmail.com wrote:

[duche...@gmail.com]

The idea to test it first on a standalone wiki is a good one so I did so and was very happy to see that it worked!

Unfortunately the install on my node server is still a failure and I can't find what I'm doing wrong.

Few questions for you (if you don't mind):

1. Do you start the media server with 'npm start' from the 'TheDiveO' directory?  Do you get any message like the ones I have in my print screen above?  Is the media server using the same port (8080) than your tiddlywiki instance (not me)?
2. I am using a dedicated linux user (non-sudo) owning the Tiddlywiki directory, is the same for you?
3. My tiddlywiki is behind a proxy (nginx), forwarding port 443 to Tiddlywiki listening on port 8080.  I didn't configure any port on the proxy for the media server (on port 8090).  Do you I have to?  If so, how different the server name would be  from the Tiddlywiki one?
   
4. I have the current folder structure:

user@server:/mnt/VHD/mywiki/plugins/TheDiveO$ ll
total 2.1M
drwxrwxr-x  4 user user 4.0K Dec  1 18:48 editions
-rw-rw-r--  1 user user  21K Dec  1 18:48 LICENSE.md
drwxrwxr-x  2 user user 4.0K Dec  7 09:17 media
drwxrwxr-x 29 user user 4.0K Dec  1 18:49 node_modules
-rw-rw-r--  1 user user 1.2K Dec  7 10:08 package.json
-rw-rw-r--  1 user user 9.1K Dec  1 18:49 package-lock.json
-rw-rw-r--  1 user user 3.3K Dec  1 18:48 README.md
drwxrwxr-x  3 user user 4.0K Dec  1 18:48 src
-rw-rw-r--  1 user user    5 Dec  7 10:09 tw.pid
-rw-rw-r--  1 user user  407 Dec  1 18:48 twtube.js
-rw-r--r--  1 user user 2.0M Dec  2 10:09 twtube.tid

Thanks again for helping out, much appreciated!  (BTW, funny video you put as an example!)

[Donald Coates]

I started my tiddlywiki nodejs server the normal way with the `tiddlywiki` command.  In fact it had been running for a couple weeks.

I did the same as with the standalone - just dragged the downloaded tid onto the nodejs servers page and reloaded.  Start there and see if all the other problems are solved.  If not let me know but there shouldn't be any need to open additional ports.

I think `npm start` is for development purposes - ie if you were going to directly make changes to the code of the plugin itself.  For using the plugin just add it to a running wiki like you would any other plugin.

[duche...@gmail.com]

Ok, so I Removed the TwTube plugin from control panel, uninstalled the media server (npm uninstall) and even removed the 'TheDiveO' directory from 'plugins' to start fresh.

Restarted my tiddlywiki server.

Everything seems to be clean at this stage.

I dragged the plugin from 'Download' of this source to my tiddlywiki.  Success, I see the plugin installed in my control panel.

My test tiddler however still shows an error message (see below).  I tried moving the .mp4 file to different locations: within mywiki root; within a 'media' directory under mywiki root; within the 'tiddlers' folder; within a 'media' directory within the 'tiddlers' folder.

My video files has permissions 644 and is owned by the tiddlywiki's user, like all others tiddlers.

All unsuccessful...  :(

Thanks again.

[Donald Coates]

My barely educated guess:  tiddlywiki still relies on nginx to connect to the video.  The src has to be in a place that is accessible to nginx.   Therefore you should be able to add that directory location onto a web address and have nginx serve it directly, like an external image. 

One way to troubleshoot would be to bring up your Web Developer network tools (method depends on browser) and see what address your browser is trying to connect to in order to see the video.

My guess is the src you have in your code is not accessible to nginx in that format.  Think of the video as an external image that tiddlywiki is linking to.

One thing you could do is make sure the video plays with a direct link and then put that link as the src.  So make sure you can play the video at "https://mysite.com/dir/to/video.mp4 and then put that direct link as your src.  Once you know it works you can play with relative links but those are generally a whole different beast to contend with.

[duche...@gmail.com]

I'm getting closer!

One thing I missed was to import the videos using tiddlywiki import, rather than just copying them from the server file system into mywiki directory.  So I was missing the .meta file.

Now if I put this imported name within the <source src="BigBuckBunny_SampleVideo_1280x720_1mb.mp4" type="video/mp4"/> statement, I get an error message.

If I just put the imported video name within {{ }} then I can play it, but without any controls of the visual.js / Twtube plugin, see below.

BTW I can play without issue your video that I copied into my test tiddler, probably because this is a network location rather than a server file.

So all of this seems to lead to a file location or permission problem.  I'll have to play with Firefox Web Developer tools to find the address / file location that is asked.

Have a good day.

[Donald Coates]

So I don't think it will work this way - trying to access it by tw import.  You have to think of it this way - nginx is serving the file within tiddlywiki.  nginx has to be able to serve the file separately on its own.  Here is the code I put in for the video you see in my wiki:

```

<$videojs controls="controls" fluid="fluid" width="800">
  <source src="https://digitalap3.com/christinemessages_0.mp4" type="video/mp4">
</$videojs>

```

So I put the video in a place that I can directly access it from nginx if I copy paste the address in the src into the address bar.  It is the same for external images.  External images or any files are not imported directly into tiddlywiki.  Nginx is serving the file to the browser inside of tiddlywiki.  This is what makes relative addresses as your src tricky.  Nginx is looking relative to the webroot in the website's config file.

[duche...@gmail.com]

Yes, it works that way, i.e. when I input the url of a file located on my ngnix server to the 'source src=' .

However I thought that I could also address a video located within the tiddlywiki folder, as we do with images.  And Tiddlywiki shows right such a video as it does for an image using the transclusion syntax: {{video.mp4}}.  The only problem is that the plugin isn't used hence no control on the size of it. 

Isn't it what the  statement '  <source src="media/BigBuckBunny_SampleVideo_1280x720_1mb.mp4" type="video/mp4"/>' from TwTube Github page suggests?

Thanks again digit!

[duche...@gmail.com]

Re my last paragraph above I now understand that '<source src="media/BigBuckBunny_...' refers to the root statement of your nginx site configuration file,  so no need to provide the full path of the url (https://...).

Too bad this wasn't documented.

Anyway this now works fine and your assistance has been very useful, thanks digit!

[Donald Coates]

No problem!!  Yes serving external files with a proxy server is always like this - lots of assumptions that lead to lots of confusion.  It's a bit outside most use cases I guess.  Using nginx to serve media files outside TW is absolutely the way to go though IMO the performance is way worth it.