problem loading flv over network when accessing swf through html

[divillysausages]

hi all,

i have website that loads images and videos for my company. it's an internal thing that's meant to be shown in a network folder that people can access.

my problem comes when i try to load videos in. on my local machine, everything works fine, if you launch the swf directly from the network folder, everything works fine. the problem comes when you launch the html that the swf is embedded in. my netconnection is successful, but when i try to load the flv using netStream.play (using a local path like "videos/myVid.flv") if get a NetStream.Play.StreamNotFound error.

local paths work fine when loading images etc but not videos (even when i put the video into the images folder or vice versa). the only way i can get this working is if i put absolute paths into the video ( like "\\myServer\flash\videos\myVid.flv")

i'm thinking this is a sandbox problem. when you open the swf directly, it's running on the network, so it's ok to access network files, but when you open the html, it's being loaded to your local computer, and isn't able to do it? both times when i print out the sandbox type it's "localWithFile", but it just doesn't work in the browser. but then i don't get why xml loading and image loading works, but not video. i've also changed the export to localWithNetworking and tried Security.allowDomain("*") but nothing worked.

this works fine if the files are uploaded to a webserver, btw.

i've put up a zip file with the relevant files (though you'll have to stick in your own flv), though unless you have a network handy it's going to be a bit hard to test it.

any help or points in the right direction would be appreciated though
thanks

[Colin Holgate]

Your files work fine with my FLV and when I try to follow your instructions. Two days ago we had a situation that was almost like what you've described, except that the swf would work, the html work work (when opened directly, like "file:///Users/colin/Desktop/video%20bug/video_bug.html", but would not work when opened via http. If that is your real situation then you may have the same issue we had, which is that our server had its MIME type set wrong for handling FLVs.

[divillysausages]

hey colin, thanks for your reply
so opening the swf across the network, and opening the html across the network both work with a relative path set for the flv? hmm, it's a straight windows 2000 server, but i'll send an email to the tech guys on monday and see if they come up with anything. cheers for the tip 🙂

[Andrei1-bKoviI]

I think you should use an absolute path. As a matter of my experience, I was not able to load any assets with relative path. I think Flash translates relative paths to the html page location - not swf location - when embedded into html that is on a domain. Locally it translates relative to swf.

Hope it makes sense...

[divillysausages]

hey andrei1,
yeah i was thinking something like that - that when brought to the html page, is was essentially a local file trying to load network files, which wasn't allowed, hence messing around with the security settings. but, with your solution, then image and xml loading should be affected as well, as they both use relative paths as well

[Andrei1-bKoviI]

Hey,

So, what you are saying is that flv, images and xml are in the same directory and only flv is not able to play while other files load ok. Is my understanding correct?

[divillysausages]

pretty much. they're in different directories, but all are loaded via relative paths. even if i put the flv into the images or xml folder, i still get a Stream.Play.NotFound.
and only when opening the html file. and only over the network (internet is fine). at least it's specific 🙂

[Andrei1-bKoviI]

Hmm...

Did you try to compile the swf with network only plyback security?

Publishing settings/Flash/Local playback security/Access network only.

Also, did you try a full path? One thing about NetSteam is the protocol. Flash may not understand what you are really streaming unless it sees the protocol. Just a wild unsubstantiated guess ...