A very odd business, this.

I'm updating two pages of a complex (and messy) website. One page is in the English-language half, created by one company. The other's in the Japanese-language half, created by another company. The halves are in subdirectory structures called "ja" and "en" respectively but these structures are asymmetrical: although there's also a single subdirectory called "video" it's one level beyond (is separated by one more "../" from) most Japanese-language pages than it is from their English-language counterparts.

Each of the two pages I'm updating has links to the same pair of videos. In the old pages, the way they're linked is crude. (For this I blame myself, not either of the companies.) I thought that for the revision (with a new pair of videos) I'd use a "lightbox" effect: the visitor clicks on a link and a little window opens in the centre of the page for the video, which starts automatically as the rest of the page is darkened; the visitor then clicks on a link titled "back" within the little window and this window disappears while the original page reappears. This of course requires a pile of Javascript and Flash hocus pocus, about which I am totally ignorant, as well as CSS.

I decided to tackle the English-language page first. Thanks to the combination of (a) Saeid Mohadjer's excellent lightbox example (together with the explanation linked from its foot) and (b) Longtail's JW Player "wizard", it all works.

Here's one vital (and fully working) script within that page:

<script type='text/javascript'>
var so = new SWFObject('../video/player.swf','mpl','480','270','9');
so.addParam('allowfullscreen','true');
so.addParam('allowscriptaccess','always');
so.addParam('wmode','opaque');
so.addVariable('duration','136');
so.addVariable('file','../video/pickles.mp4');
so.addVariable('autostart','true');
so.addVariable('type','video');
so.write('mediaspace1');
</script>

So far so good. Now to do a similar revision of the Japanese-language page. This is one level further below, and I therefore copy in the stuff above, adjusting two lines of it so that they read:

var so = new SWFObject('../../video/player.swf','mpl','480','270','9');
so.addVariable('file','../../video/pickles.mp4');

(Note the extra "../".) But now the Flash player can't see (or is denied access to) the MP4 file. The Flash console does open up, but it glumly reports "Video not found or access denied: ../../pickles.mp4".

Note that the SWF and the MP4 files are in the same directory, linked to in the same way.

Wondering whether the SWF file might be cached, I deliberately remove a "../" from the link to it. It no longer works, meaning that it really is being linked to successfully.

I then make a copy of the MP4 file in the very same directory, writing

so.addVariable('file','pickles.mp4');

The result works perfectly.

So it's almost as if there's a file directory syntax oddity here: "../../" works for SWF but not for MP4. But this is nuts: directory navigation is "filename agnostic".

A simple kludge would be to duplicate the two MP4 files. After all, hard drive space costs nothing. (I even have a laptop with a half-terabyte drive. Crazy.) But this is aesthetically most displeasing, and while I'm happy to know nothing about Javascript and Flash, I do like to think I understand what "../" means.

Ideas?

As you say, in the underlying operating system, of course the directory structure works normally. I don't know anything about Flash (happily!) but I wonder if this "messy" site is actually accessing server scripts? In which case it's perfectly possible that some bit of well-meaning program is curtailing attempts to reach "up" the directory tree. If you ask the server for "../../x" from level 1 in the document tree, the worst that can happen is a 1000 pound fine for the browser user, but if a file name gets passed to a server script, the script needs to check that it is a valid file name, and a sloppy way of doing this might be to remove "../.." from the argument. You might see what happens if you write ".././.." instead... ?

Right now the pages don't run any scripts on the server, but they certainly do run scripts on my hard drive's mirror thereof, which of course is tantamount to the same thing. I commented out two scripts of which I know nothing; doing so neither fixed my problem nor changed the behavior of the page in any other way that I noticed.

(One problem with external attempts, e.g. via wget, to capture sites is the amount of stuff one tends not to get. I already know that the CSS files call other CSS files [something that wget ignores] and I don't think that anything is making calls to Javascripts I'm not aware of, but don't know for sure.)

(Odd how the Japanese half of the site is -- by express institutional policy -- all in quaint old Shift JIS. Neither of my regular text editors bothers to support this; I therefore installed the excellent Geany, which is happy with it.)

PS something very odd is happening in the directory tree. I've just noticed that some little graphics aren't displaying.

(It's one of those web pages with dozens of tiny graphics to "enhance" the page [cf your average auction page], each with alt="", so one hardly notices their absence.)

Screwy.

Well I dunno, really.

I noticed that some little graphics in remote directories also weren't displaying. (It's one of those web pages with dozens of tiny GIFfies to "enhance" the page [cf your average gimmickry-filled auction page], each with alt="", so normally I hardly notice their absence.) Also, what I thought were odd sizes of lettering, as if the page wasn't seeing one or more of the stylesheets. (It starts by calling ten stylesheets, all but one of them via includes, and then adds a couple more.)

I thought about that while in the shower. Something to do with file/directory permissions, perhaps? So I went to the top of the relevant directory tree, and made everything below it read+write (as I think it was before).

No effect.

Then I copied the whole lot onto a USB flash memory thing, and viewed the result. Same (little graphics missing).

All of this was via my cheapo-cheapo Ubuntu "netbook". I pulled out the flash memory whatnot and stuck it into the missus's opulent Mac. This time the page displayed with good lettering and all the little graphics.

However, I still can't run an MP4 file unless it's in the same directory. (I tried moving it to the parent directory, etc., each time of course adjusting the link. No go.) Meanwhile, when I call the same MP4 file from my "English" page, it's happy to oblige even if the MP4 file is elsewhere.

Very odd.

Now I'm utterly mystified.

The "English" page is provisionally here. You'll see "Video comment" in two places; clicking either should display one or other video. There's a mouseover for the photo at the bottom but no other jiggery-pokery. There are lots of other links, none of which will work except the little button with Japanese characters at the top right; this takes you to the "Japanese" page. (Scare quotes as the content of both is almost identical.)

If you'd like to go there directly, the "Japanese" page is provisionally here. There are two graphics missing (their gimping yet to be done); I've given conspicuous red backgrounds to the blanks. Immediately above each of these red rectangles is a text link similar to "Video comment" in the English page, though in Japanese. Clicking either should display one or other of the same videos you see on the "English" page. For me, it doesn't, and I've no idea why. There are lots of other links, none of which will work (certainly not the one misleadingly titled "English" at the top right) except one in green on the left, "information in English".

There's a <!-- --> comment at the foot of each page crediting the source of the "lightbox" stuff, which I only hazily understand. The Flash stuff, of which my ignorance is complete (and fatally so?), is JW FLV Player.

One MP4 is here and the other is here. They're about 7.8MB each. Incidentally, you'll notice that they have different aspect ratios; I thought that a "lightbox" would obscure the difference and this is why I used it instead of a less gimmicky and less troublesome "embedded" display.

If you'd like to experiment with what I've uploaded -- please do! -- then wget would only get you a small portion of it; scraping around for such bric-a-brac as stylesheets linked by "@include" would be as tiresome for you as it has been for me. So with the exceptions of the MP4 files (linked immediately above), I've zipped up the whole lot for you in "whole_lot.zip" (just under 1MB).

Help greatly appreciated!

The Japanese version is one directory deeper, have you edited all file paths to reflect that? What happens if you put both pages on the same "level"?

I know their relative positions.

I quote from http://hoary.org/testing/gis_upload/gis/ja...in/gakusei.html --



Note the plain "yuri.mp4". Hmm. come to think of it maybe I could try underlining that, as it were, by instead saying



(Note the single dot.) But useful though dot-slash is for other purposes within my own computer, I've never heard of it being necessary on the web, and I'm too sleepy now to want to experiment.

I quote from http://hoary.org/testing/gis_upload/gis/en/student.html --



So the one that has the elaborate path (up, down, down) to the MP4 gets it but the one that shouldn't need a path doesn't get it.

You write:


but then you write:



When I test it's indeed the version with the mp4 in the same directory as the Japanese web page that doesn't work.

It works when I give the Japanese page's script a full URL from my HD root.

It also works with a relative URL when the HTML, MP4, JS and SWF files are all in the same directory.

Christian, thanks to your help, I now have a solution. All these materials are together for the Japanese page. For the English page, all but the page itself are up above in the "video" directory.

Yes, this means that four files are (I'd have thought) needlessly duplicated. And two of the four add up to close to sixteen megabytes. This is disgustingly kludgy. I hate myself for perpetrating this. But hey, it works. (I tell myself that these days hard drive space costs nothing and everyone has infosuperhighway-breadth of band, so the mindless duplication of megabytes doesn't matter at all.)

The story updated:

Yes, I copied all this stuff into the directory of the Japanese page. And, wonder of wonders, it all worked there.

I then adjusted the paths within the English page so that not only the MP4 files were up-down-down in the Japanese directory but that everything needed was. (And believe me, while I know squat about Javascript and Flash, I do understand dots and slashes. I made no mistake.) Same old nonsense: the Flash player reported that each MP4 file didn't exist or access to it was denied.

I then copied the MP4 files and the two other video related files to the "video" directory, and got the English page to point to this. It worked!

If that worked, you may ask, why not get the Japanese page to point there too, and avoid the file duplication?

That's where I was yesterday. That simple and aesthetically pleasing solution "simply" doesn't work. I've no idea why not. I suspect some very, very odd bug in the Longtail material. However, I have no appetite for investigating that right now.

I now have an improved solution.

For the "Japanese" page, put the two MP4 files, the SWF file, and the JS file all together in the same directory (that of the page itself). That's the only way they work for/with it.

Q1. Why can't they be elsewhere? (I've no idea.)

For the "English" page, point to the the directory of the "Japanese" page for the MP4 files. (Not needing to duplicate these saves close to 16MB.) But don't point there for the SWF or the JS file -- video won't work if one or more of those files is are there. Instead, duplicate those two files. Both can be above, in a "video" subdirectory.

Q2. Why can't they all be in the directory of the "Japanese" page? (I've no idea.)
Q3. Granted that there are bizarre constraints, why should these be (or seem to be) different depending on the web page? (I've no idea.)

Now that it all works, my curiosity has abated somewhat. I turn to various other real-world issues.

(Except that it doesn't all work. See new thread.)

May I suggest you document all this for the benefit of others working on the site?

Oh yes, my new, improved web pages are replete with

<!-- comments in HTML -->
/* comments in CSS */
// comments in Javascript

in which I attempt to explain the apparently senseless.

Alas my new, improved web pages neither fully satisfy me nor (on a non-negligible number of computers) actually do what they're supposed to do (see other thread); because of the latter, as yet they only exist within the computer on which I type this, in a USB memory stick, and on a CD-ROM that can be thrown into an office shredder for all I care.

Done.

Looking around the answers to other bug reports on Longtail's site, I get the impression that there are known "issues" with relative URIs. If the authors can't fix these, I wish they'd at least highlight them and thereby save the time of people like myself.

Paths aside, it's a neat little player, though: it does what it has to in a minimal space.