Hi Chao, No you can’t do that easily. Tuner can only interpret specific file format in order to consume it. You’ll need to have .car or chn format to deploy to endpoint tuner.

Regards

Andy

First things first, what is the use case you are having here, is there any specific requirement for not publishing the channels on to a central server/transmitter.

So you want to copy files from the data center server not having the master transmitter to other workstations.

Is there any feasibility to host a separate transmitter on the datacenter server itself so that you can replicate the content from datacenter server to other workstations?

Hi Chao, there’s a profs tool called “Downloader” under FSRK (http://www.bmc.com/support/reg/field-services-resource-kit.html) which can do what you described below without having to create package every time there’s more data added to the server. But, this approach would require the Tx to be hosted on the data center server to grab the files in a folder. I don’t think this would help you, but you can consider having this tx to only host this plugin and nothing else.

Regards,

Andy

A transmitter is very essential in case you need to host any content for replication.

Sounds like you might look into content replicator.

Content Replicator 8.2.00 (22987 KB)

Replicates directories of content

Current versions of the content replicator only work through the transmitter. There used to be a standalone version, but I am pretty sure that this is no longer available.

Quite interesting!

So in that case it would be a peer-to-peer package copy through UDP...

Its definitely no longer supported.You'd have to go way back to 4.6.1

http://products.marimba.com/Archive/461/

and I don't recall it being able to transfer directly to a tuner. I still believe it has to go through a transmitter. It was originally designed to be embedded into various products or processes.

The way the product works overall is based on a manifest. This manifest contains one or more  meta data entries  around files, registry keys, environment variables, service entries and states, etc.

When the tuners request files from the transmitter it requests MD5 checksums that uniquely identify the file. sometimes if a newer manifest has the same path to a file but the MD5s are different, the tuner will send both MD5s in the request to the TX. The TX in turn will see if it has both MD5s/files, if so it will attempt to do a diff on the files and send the diff result and the instructions to the endpoint tuner. That way bandwidth is conserved.

The tuner MESH/P2P functionality still requires a manifest but the tuners will communicate locally requesting the MD5/files from the local tuners. If no local tuner responds, it goes to the transmitter for the file.