Question

Still working on my personal web server, I was trying to use the html5 audio and video tags within Nitrogen.

As there is no #audio nor #video records, I decided to insert html text directly in the page generated by nitrogen, the result looks like this:

<audio controls preload="metadata"><source src="../../My Music/subdir/song.ogg" type="audio/ogg"  /source>audio tags not supported</audio>

In my understanding this should work because the audio tag is supposed to be interpreted directly by the client browser, and there is not any nitrogen id or event observer in the code.

But when I browse this code from Firefox, I briefly see the control opening, and then the audio element simply disappears.

If I copy paste the whole code generated by nitrogen (display html source page, copy and paste in a file located at the origin of the nitrogen project) and open it with the browser, it works fine. The relative path is correct, assuming that the search stats in nitrogen project. I have tried absolute path also, without success.

I don’t know

• if it builds a file name of the form “.._.._My music_subdir_song.ogg” like nitrogen does for url analysis,
• or if it uses another directory to start the path,
• or if it simply doesn’t work the way I am thinking.
• …

Edit: some complementary information:

I have done the following changes:

create one directory including some ogg files in the site/static directory + move a static test.html file in the site/static. If I open directly test.html -> ok. if I redirect from my web site -> Not ok.

same test with a copy of the directory at the Nitrogen application root and access from my web site -> not ok

As the information on the web page is ambiguous, I modified test.html to access to a file that does not exist on my PC -> same behavior.

I think I’ll use the debugger to understand how the request is managed, to be continued…

Edit 2:

using the debugger I can verify that the wf_core:run_catched() is called several times. The fist call is when it process the event in my page that redirect to the static file.

The second time to process the static html file itself.

A third time to process finish_static_request() with a Path equal to my_music/song.ogg, and then I get lost in the processing of the answer. Another wf_core:run_catched() was called in parallel, but I didn’t follow it…

I have been able to verify that the file can be accessed: I have added several audio tag in the html files, and I was able to “download” the existing files using the DownloadHelper Firefox plugin.

My understanding now is that the path is correct (at least when I place the files in a subdirectory of site/static), the server is able to retrieve the files and send them, the browser recognize the audio and video tags, but the link between the embedded audio/video reader and the files is lost, although I have added a type definition inside the audio tag.

Any idea to continue?

Edit 3:

Finally I got it. As Chops suggest it I had to go in the inets server configuration, not to define the path, but to define the type association. I have added the following definitions in etc/inets_httpd.erlenv, and it works.

{mime_types, [
    {"css", "text/css"}, 
    ...
    {"ogg","audio/ogg"},
    {"webm","video/webm"}
]}

:o)

Answer 1

Based on the contents of the url attribute (“../../My Music/subdir/song.ogg”), the problem, when it’s served from Nitrogen is that the request (Assuming you’re using the default 127.0.0.1:8000) for the audio will be to the url “http://127.0.0.1:8000/My Music/subdir/song.ogg”

What you want to to do, if you’re using the standard Nitrogen installation, is to put the song files you want into the site/static directory, perhaps in “songs” subdirectory.

Then change the url attribute to be “/songs/mysong.ogg” (or whatever path within site/static you used).

Note: Dependinding on your server choice (Webmachine, for example), you may need to tinker with the server’s specific config file to tell it to handle the new directory for static paths, for help, check the configuration docs on the Nitrogen site.

Beyond that, there’s nothing special about outputting raw HTML in Nitrogen. It is my understanding that the problem here is really just related to the paths of the requests being sent to the server.