October 31, 2006

Want to help shape the next version of Flash Media Server

I'm trying to stay positive here and that we WILL see another version of Flash Media Server. Due to the complete lack of new material about FMS on Adobe's site nor at the huge MAX event in Las Vegas (and other Max events around the world), it's a bit tough.

But anyways, the product manager of Flash Media Server, Steve Wolkoff, has decided to let you post on his blog what you would like to see in the next version. So, go tell him. Let's pray that it doesn't take them as long as it did to get to FMS from FCS though..

I have to say though, we (FMS community) have sent tons of opinions and ideas to him, to have to again start from scratch and write them all down is a bit frustrating. I would hope that it wouldn't have been too much effort to say something like "this is what we have received so far," (and list them) "any votes for these items or anything else to add?". I think that would be a bit more helpful to the cause and shows initiative and respect towards all that have worked hard to see FMS grow and improve. Although I do appreciate the fact that he is now publicly asking. So once again, go hassle him :)

Posted by Graeme at 11:43 AM | Comments (7)

Ask an FMS Guru #16: How do I get the metadata "duration" to be added into the FLV?

This is an easy but slightly obscure problem to fix, most probably wouldn't be aware of it unless coming across it themselves in the past.

The question: When I encode the video and save it on the server, then later playback the FLV I notice the "metadata" is missing (duration in particular)?

The answer:

Upgrade. One of the older versions of 1.5 was missing the duration value when creating FLV files.. I can't remember which one. Upgrading to the latest build of 1.5 (if you can find the upgrade files somewhere) or using FMS2 will get you the duration value in the FLV files.

On a related note, the first version of Sorenson Squeeze 4 also had messed up metadata, a lot of people were relying on Burak's FLV metadata injector actually. Something to keep in mind perhaps.

Posted by Graeme at 03:26 AM | Comments (0)

October 30, 2006

I can't stop watching my fish...

I don't know what it is but I can't stop watching my fish..

Click the pic for the full rez version

Just recently while re-renovating my office I decided to add in an aquarium to sort of give the work area a bit of life to it. Up until now I've just been surrounded by books and book cases above me with books leering down at me saying "hurry up and read me!!" or something like that.

So, along with removing every bookcase in the room and tearing off the bookcase above me on the wall, in goes an aquarium. For any of you that have an aquarium I'm sure you already understand this but it's not easy to have a large aquarium just hanging around. First up is a strong desk to put it on. I managed to get the legs part for free from a friend, which are metal and very strong, there was no top. I ended up cutting up some 3/4 inch plywood into 2 equal size pieces to fit into the corner of my office and match up with not only the depth of the desk, but also the height.

To add onto that, an aquarium is a bit tough to manage but that in itself intrigues me because I like nature and ecology. I got a 29 gallon tank, two types of gravel for it (small and large gravel for the plants), 3 ornaments that you can see in the pic (a log, boat and ruins that has an air stone). Then over the last few days I've been stocking it with a few small fish (3 neon tetras and 3 blackskirt tetras) and live plants. I chose live plants because not only do they look better, but they are much better for the system. Being that it is a closed system, other than when water changes are made, it's tough to maintain safe levels of certain chemicals etc. The live plants will help along with that and to me just seem more natural.

All in all though, I just can't stop watching them play and swim around. I was talking to the guy at Petsmart, where I go to get most of my stuff, and he was mentioning too how theraputic it is to just relax and watch the tank. It's very relaxing and definitely the best addition have made to the office so far (even beats my new 23 inch apple monitor..). So maybe thats it.. I just need to relax a lot :)

If you have the space and a bit of time for the maintenance, I definitely recommend getting an aquarium. If it's your first time though, don't start small because they are actually harder to maintain.

Posted by Graeme at 05:35 AM | Comments (2)

October 17, 2006

Consulting for Flash Communication Server/Flash Media Server

It just so happens that last week we had about 5 new people send in emails or comments of some sort asking if we do just consulting for Flash Media Server and/or Flash Communcation Server. Odd timing.. but to set the record straight:

Oh yes, in fact that is our speciality. I find at least 90% of my day is working with FMS and Flash with the other 10% going to server side coding with databases.

So if you were wondering before, now you know for sure. We live and breath FMS/FCS here, and consulting is just one aspect of the job :)

Need to get a hold of us? Contact us here:
http://www.solid-thinking.com or here: http://evo.solid-thinking.com, or talk to us live here at our live support.

Posted by Graeme at 03:44 AM | Comments (0)

October 10, 2006

FMS 2.0.3 EULA sez you can use dev version for free for commercial sites

I kinda wondered how they would even police this kind of thing a long time ago, but now it's official, you can use FMS2 for commerical projects for free!

There are a couple of restrictions on that usage. one being that you can't cluster them, or load balance them to create a huge network of dev FMS's. Makes sense, can't imagine somebody would bother doing that anyways. You only get 10 connections.

Anyways, this is great news!

You can get FMS here.

Posted by Graeme at 07:08 AM | Comments (1)

October 06, 2006

Ask an FMS Guru #15: What is the best way to handle the connected clients on the server side?

Wow.. this is such an open ended question I'm not quite sure where to start. Fortunately, I was able to get a bit of background information on the project and can hopefully offer a bit of direction for it here.

The question: What is the best way to handle the connected clients on the server side?

The answer:

Well, to bring this into a scope that I can handle in one post I'll quickly go over the goals of this particular developer.

First up, the application is a type of chat application and some users will be in private chats with each other along with a lobby area I think. The main goal here is to be able to tell only the users that are connected up together in one "private room" that somebody has logged off.

Now, I'm guessing that this developer has set it up so that all users are sitting in one application. In other words, all users that are connected to the application, whether they are in a private chat or not, are connected to this one application. The idea here is to make sure that we only tell the right people that we have left this private chat.

So perhaps first we'll look at how we would usually tell all users that a particular user has logged off.

On the server side we would put a function in the onDisconnect method. This will fire on the server side whenever somebody logs off. If we were in a one room chat I would probably just use the method broadcastMsg() of the application object.

Something like this on the server side:

application.onDisconnect = function(clientObj){
application.broadcastMsg("userLoggedOff", clientObj.userName);
}

Something like this on the client side:
nc.userLoggedOff = function(userName){
myText.text += userName + " logged off";
}

That's not too hard. But this particular developer only wants to tell certain people.

Now, there are tons of ways to do this. The best way is to have these private chats in their own instances of an application. That way it is foolproof that you won't be letting anybody else know. So, in this case, everybody would connect up to a common instance of the application for the lobby, and if there were private chats, then those people would disconnect from the lobby and go connect up to the private chat.

Of course, there are times when you want the user to also be able to monitor the lobby. So in this case, just don't disconnect them from the lobby and go connect them up to another netConnection to another instance.

The problem with that is that you will now use up another netConnection. Some people don't like that. The next option is to split up chats with Shared Objects.

So, each chat would be it's own Shared Object and people would just subscribe to whatever Shared Objects that pertained to whatever chats. This isn't a bad idea, but if there are enough in one application it could start to bog down a bit by taking up memory.

But in this case, how would you tell only certain users that a user has left the chat? This is where I can start to answer the part on how to manage clients on the server side.

When a client hooks up to the server the onConnect() method runs. This is where you can do your "client management" stuff. I most always create a whole new class for this and name it UserManager or something understandable like that. In here I would do the following:

1. Create a users object that lives in the server memory. This will hold the client objects (everybody who connects up) and anything else I want to remember about them.

2. Create a shared object that will hold the exact same information. This is good for debugging in the admin panel later

3. Accept the connection after doing whatever security checks you need to do

4. Most likely at this point I will set a variable to what room they are in.

By setting a variable for the client as to what room they are in, I can then control who gets what message. There are 2 ways to do this too (at least)

First up is to save the name of the shared object that pertains to the room they are in. That way, when they log out of the application, we just grab that value and make a send() call on the Shared Object. Everybody who is subscribing to that Shared Object will receive that call and nobody else. Or you could just loop through all the clients in the application and if the user has the same room name in their room variable, then make a call() call on the client object.

Keep in mind that Shared Objects run on different threads in the application than the application itself. So it is most likely more efficient to use the Shared Object approach.

I hope that gives some insight on how to mess around with client objects on the server side and what options there are to talking to them based on what is happening inside the application.

Posted by Graeme at 05:50 PM | Comments (0)