I have a simple server-side app that creates a Stream, creates a NetConnection,
and then plays a live stream from that NetConnection. I record the resulting
stream into a file, say "recordstream.flv"

When I get an UnpublishNotify, I stop recording. When I see
NetStream.Record.Stop, I create a File object that points to recordstream.flv,
and try to rename it to a different filename with File.renameTo().

This worked in FMS2, but not in FMS3. In FMS3, I get an error that the
renameTo() failed. Interestingly, copyTo() the same new filename works, so it
is not a directory protection issue or something like that. It appears that
FMS3 is forbidding me from fiddling with the file; File.canRead returns false
on the file. Is there any way to get FMS3 to release the file? Or should I give
up and just use copyTo()?

Hi,

What platform are you running on ? If the platform is Windows, then this is
most probably happening because Windows thinks that the file is still open
under FMS. What happens if you wait for a while before trying to rename the
file. Does that work ?

You can also verify whehter Windows thinks that FMS still has the file open by
trying the following :
1) If you haven't got it installed yet, install process explorer. You can find
it at :
http://technet.microsoft.com/en-us/s.../bb896653.aspx
2) Search for your file name. Process explorer will tell you which process is
still using the file.

thanks,
Mo



[q]Originally posted by: dhalbert
I have a simple server-side app that creates a Stream, creates a
NetConnection, and then plays a live stream from that NetConnection. I record
the resulting stream into a file, say "recordstream.flv"

When I get an UnpublishNotify, I stop recording. When I see
NetStream.Record.Stop, I create a File object that points to recordstream.flv,
and try to rename it to a different filename with File.renameTo().

This worked in FMS2, but not in FMS3. In FMS3, I get an error that the
renameTo() failed. Interestingly, copyTo() the same new filename works, so it
is not a directory protection issue or something like that. It appears that
FMS3 is forbidding me from fiddling with the file; File.canRead returns false
on the file. Is there any way to get FMS3 to release the file? Or should I give
up and just use copyTo()?[/q]

[Q]What platform are you running on ?[/Q]Thanks for reply. No, it's Linux, so
that's why I found it so odd. It seems that File.renameTo() is making some
extra check about the file being associated with a stream. Normally a rename
should be just fine.

I have since restructured my code so that the problem is moot, but still, it's
an open question.

It seems that this might be a bug in FMS, which will need further
investigation. I have filled a bug detailing what you explained. That way we
can have resources allocated to it. The bug number for our internal bug
database is : 1935018.

Btw what is the build number for FMS and can you give the version (major and minor version) too.

[q]Originally posted by: mohammep
Btw what is the build number for FMS and can you give the version (major and
minor version) too.[/q]
It is FMS_3_0_1_R123, unpacked from the latest Development Server build a few
days ago, running on Scientific Linux 4.2 i686 (RHEL 4 clone).

Hi Dhalbert,

Thanks for the prompt response. Do you have a script handy which we can use to
repro the bug ? It would help to havethe script you are using or a code snippet
thereof which we can use to repro the bug.

thanks,
Mo

Hi, here's the essence of the code, as described in the original posting:

# Demonstration of failure of renameTo() on a recorded stream file on FMS3
# dhalbert

application.onAppStart = function() {
this.ns = Stream.get("recordstream");
this.ns.onStatus = onStatusHandler;
this.nc = new NetConnection();
this.nc.connect("rtmp://remoteserver/remoteapp");
var playResult = this.ns.play("remotestream", -1, -1, true, this.nc);
application.ns.record();
}

onStatusHandler = function(info) {
timetrace("onStatus: " + info.code );
if (info.code == "NetStream.Play.UnpublishNotify") {
application.ns.record(false); // Stop recording:
NetStream.Record.Stop will be sent
}

else if (info.code == "NetStream.Record.Stop") {
// application.ns.record(false) has done its work.
var file = new File("streams/remotestream/recordstream.flv");
trace("file.canRead: " + file.canRead);
trace("file.exists: " + file.exists);

var filename = "streams/remotestream/renamed.flv";
// file.copyTo(filename); // Works on FMS2 and FMS3
file.renameTo(filename); // Works on FMS2, gets "renameTo
failed" on FMS3
}
}

I belive this is not a bug as designed. In your code he specified stream rename
to as var filename = streams/remotestream/renamed.flv
and that why extra level is added, and probably your directory
streams/remotestream/streams/remotestream not exists
To rename to same directory you needs to specify var filename =
"/streams/remotestream/renamed.flv"
and everything works well.
By specifying leading / the level could be controlled. Please confirm.
Thanks.

Sorry, I was simplifying and sanitizing my sample program and made some typos.
I did not actually run the exact code above. I meant something like:

...
else if (info.code == "NetStream.Record.Stop") {
// application.ns.record(false) has done its work.
var file = new File("streams/_definst_/recordstream.flv");
trace("file.canRead: " + file.canRead);
trace("file.exists: " + file.exists);

var filename = "streams/_definst_/renamed.flv";
// file.copyTo(filename); // Works on FMS2 and FMS3
file.renameTo(filename); // Works on FMS2, gets "renameTo failed" on FMS3

I know the file is there because file.exists returns true.