Flathead U Tutorial: Filtering Based on Metadata Values

Posted by Michael Carusi on Wed, Apr 24, 2013 @ 03:53 PM

Tags: tutorial, Xinet, how to, Xinet How To, Portal, Xinet Training, online DAM training, metadata

Filtering Based on Metadata Values from FlatheadU on Vimeo.


Like all great universities, Flathead U offers summer courses long after everyone has put their learning caps away until September. We know that it's just as fun to continue education. Our latest update to the Flathead U discusses filtering based on metadata values. If the value matches the users primary group on an asset or folder, then the user can see and search for it. Any asset that doesn't have a matching value is filtered from view. This video has a lot to talk about, so kick back and enjoy learning!

Who's On My Portal Server?

Posted by Sean Kenny on Thu, Oct 01, 2009 @ 01:37 PM

Tags: Xinet, how to, Xinet WebNative Portal, Pageflex, Xinet How To, Portal, PHP, Portal 3.0


Sometimes it would be nice to know who is actively logged into your Xinet Portal Server. Unfortunately there is not a current tool offered to retrieve this information...until now!

Using a simple php script it's actually possible to scrape the current php sessions that have been created and obtain a list of users that have active php sessions in Portal.

A little background on this....

On Portal servers php stores it session data inside of th session directory /tmp, this is specified by the session.save_path ini variable. All session files start with the prefix "sess_". Inside of a session file you will find a plethora of serialized text data, that php is managing with its session functions. Although this serialized information is highly unreadable, is is still possible to pick some key data out of it, without needing to go through a deserialization process.

So basically for each user logged in via Portal, a corresponding session file will be created inside of the /tmp directory. Contained within this file will be useful information including the username. So at this point all we need to to is create a php script that will read all the php session files located on the server and displays the count of usernames that it finds!

php code that does this looks like the following:


//create an empty array to house our users in
$users = array();

//loop through all of the sesssion files found in the php session temporary directory
foreach(glob('/tmp/sess_*') as $session_file){

    //get the contents of the sessions as a string
    $session_data = file_get_contents($session_file);
    //with a regex mine out the username contained within the session data
    preg_match('/USERNAME.*?"(.*?)";/', $session_data, $matches);

   //get the matched pattern out of the first grouping of the pattern
    $session_user = $matches[1];

   //if the found value is not empty then create the key for the array and/or increment the user count (users can be logged in multiple times)
    if ($session_user) $users[$session_user]++;

//now that we have done the heavy lifting proceed to display the result with a simple foreach iteration over the users array that we have populated...


<H1>Active Portal User Sessions</H1>


<?php foreach($users as $username=>$count): ?>
<LI><?= $username ?>(<?= $count ?>)</LI>
<?php endforeach; ?>


If You install this php code on your Portal Server you would get the following output.


This successfully displays all users currently logged into the Portal server.

As you can see, inspecting php sessions is a very useful technique for finding Xinet Portal user information, and using this technique it is possible to provide enhanced user tracking functionality.

New Video featues in Xinet v16

Posted by Brian Dolan on Fri, Jul 03, 2009 @ 08:29 AM

Tags: video, reel, Xinet, how to, Xinet WebNative Portal, DAM Systems, Portal, NAPC, NAPC blog

As the Holiday weekend starts up for us all, lets close the week out and chat a bit about all the cool things that are coming to the masses soon.  Xinet is going to be releasing version 16 of it’s suite of tools including a new, faster version of Portal, a unified web interface for all administration, easier tools and setup for PDF Image replacement, greatly enhanced video capabilities, basic web based markup and annotation tools and a whole bunch of other “under the hood” improvements.  Currently, NAPC is testing beta 2 of version 16 and we’re all pretty impressed with it so far.  One of the biggest features I’m excited about is the enhanced video features.  Let me esplain (as Ricky would say).

Xinet, in the new soon to be released version of video in Suite 16, has greatly enhanced how users in Portal interact with video assets.  In the current release of Video 2.0 in Xinet, it is possible to stream many video formats, create keyframes at a preset interval, and really, thats about it.  With the new version, you’ll be able to do much, much more.  First and foremost, the ability to create what I would call mini-reels, is now available as a basket plugin in Portal.  This is how it works:

1)    User logs in to a Portal site and identifies the files they want to work with.  Those files could be video files of various formats, InDesign files, static picture files, just about anything you can have in Xinet.
2)    The user would then add those files to a shopping basket.
3)    Once in the basket, the user would click the basket plugin named “Video Generation”
4)    This brings up a new Web 2.0 type of interface to arrange the assets into whatever order makes sense to the end user.  Asset arrangement is made simple by using drag and drop in a web browser-me likey!
5)    Once in the correct order, the user can set the ‘in and out’ times of the files based on keyframes generated by Xinet or by hours:minutes:seconds.
6)    The user can also set basic fade outs from clip to clip as well.  Gives it a nice touch!
7)    Once the files are arranged in the correct order and the in/out times are set, a new video file can be generated from those assets in either a Quicktime, Windows Media, or Flash format.
8)    The server then generates the appropriate file on the Xinet file system and once done, it gives the end user the ability to download the file to their desktop.

Here's a peek of what it'll look like:


This is huge everyone.  Think of it this way, if you have 30 second spots for a client for all of 2008, and they want to create a quick reel of all the ones that won awards (that you made of course!), they can quickly log in to Xinet via Portal, collect the assets, set the times and format and let Xinet make the file for them.  To be clear, this is not intended for broadcast but more for the web or computer screen aka small screen.  I think this is a huge leap forward for Xinet and since I used to work in the broadcast world, it’s pretty exciting for me as you might be able to tell!

On top of that, screen detection for keyframing is also part of the new release.  The current version can be set to sample a keyframe at a set interval say every 5 seconds or so regardless of scene change or not.  That can potentially add a bunch of useless keyframes into your database.  With the new scene detection functionality, you can set the admin preferences so it is “smart” and only creates keyframes when a scene actually changes with tolerance controls.  So, instead of keyframing a movie that is 1 minute long and getting 12 keyframes (when sampled every 5 seconds), you may only get 7 or 8 frames stored in the database. This can be very helpful!

Overall, we have a lot to look forward to with the upcoming release of version 16 of Xinet’s Suite of tools.

Enjoy the weekend all and as always, if you have any questions on any of this information, please give us a ring and we’ll be happy to help!  Want to see this new functionality for yourself???  Give your Account Manager a call and we’ll be happy to show you all the new stuff.

Happy 4th of July!

Brian Dolan

Exploring Portal Template Variable Arrays

Posted by Sean Kenny on Mon, Jun 29, 2009 @ 11:44 AM

Tags: Xinet, how to, Xinet WebNative Portal, Portal, PHP, Template

Portal has a variety of template variable arrays that contain the data used by the HTML template pages for display. When making custom Portal sites it becomes a common need to investigate the data found in these arrays via a PHP print_r statement like the following.

print "<pre>";
print "</pre>";

Through using this approach it becomes possible to display Portal’s template variables arrays directly in a web browser, which can be convenient for inspection and debugging. This article expands on alternatives and twists to this standard approach.

Alternative variable display functions

When exploring a variable's contents in PHP var_dump() and var_export() are common alternatives to the print_r() function. Each performs a similar task with a slightly different behavior. var_dump() prints slightly more informative (but less readable) information about the given variable’s data, while var_export() prints interpretable PHP code. The following table illustrates the output differences for these functions.

print_r() var_dump() var_export()
[0] => Apples
[1] => Oranges
[2] => Pears
array(3) {
string(6) "Apples"
string(7) "Oranges"
string(5) "Pears"
array (
0 => 'Apples',
1 => 'Oranges',
2 => 'Pears',

Depending on your needs, these standard functions give a good set of options for displaying Portal template variable data for inspection and debugging.

Storing Portal variable information in a variable and/or file

Sometimes it is not always ideal to send Portal’s template variable data to the web browser for inspection and debugging. To help alleviate this issue the print_r() and var_export() functions both accept a second Boolean parameter that, when set as true, causes both of these functions to return a variable’s data from the function call instead of printing it. This allows for capturing a variable’s data in another variable and/or file for later inspection and debugging. The following snippet is an example of such an approach.

$portal_page = print_r($tmpl->variables['PORTALPAGE'], true);
file_put_contents('/some/directory/var_data.log', $portal_page);

The print_r() function is called with a second parameter set to true. This cause the print_r() function to return the $tmpl->variables['PORTALPAGE’] variable information to the $portal_page variable instead of printing it. The contents of the $portal_page variable are then written to an external log file. This data could then be viewed, searched, and stored at another point in time.

Storing variable information as XML

Using PHP it is also possible to store the portal variable information in your own XML format. This XML data could then be transmitted and interpreted by any type of program geared to help inspection and debugging of Portal’s template variable arrays. The following code example could be placed inside of any one of your site’s local.inc.php files. This code snippet checks known Portal template variables arrays, and inserts their data into a hierarchical XML data structure. This file is then saved as XML on the server in the same directory as the file being executed.


$var_trees = "<?xml version=\"1.0\" encoding=\"UTF-8\"?>";

//start the xml var trees hierarchical data structure
$var_trees .= "<var_trees>";

//check the known portal variables. If they exist generate an xml tree of the data
if ($volume_info != NULL) $var_trees .= var_tree('$volume_info', $volume_info);
if ($file_info != NULL) $var_trees .= var_tree('$file_info', $file_info);
if ($files_info != NULL) $var_trees .= var_tree('$files_info', $files_info);
if ($keywords_info != NULL) $var_trees .= var_tree('$keywords_info', $keywords_info);
if ($tmpl->variables['PORTALPAGE'] != NULL) $var_trees .=
var_tree('$tmpl->variables[\'PORTALPAGE\']', $tmpl->variables['PORTALPAGE']);
if ($links_info != NULL) $var_trees .= var_tree('$links_info', $links_info);
if ($spreads_info != NULL) $var_trees .= var_tree('$spreads_info', $spreads_info);
if ($_SERVER != NULL) $var_trees .= var_tree('$_SERVER', $_SERVER);
if ($_SESSION != NULL) $var_trees .= var_tree('$_SESSION', $_SESSION);

//close the xml var_tree hierarchical data structure
$var_trees .= "</var_trees>";

//store the xml data in an external xml file
file_put_contents(dirname(__FILE__).'/var_trees.xml', $var_trees);

//recursive function to generate nested xml data structure for a given variables data
function var_tree($key, $value){
$var_tree = "";
$var_tree .= "<var_tree label=\"".htmlentities($key)."\" >";
foreach($value as $key => $val){
$var_tree .= var_tree($key, $val);
$var_tree .= "</var_tree>";
$var_tree .= "<var_node label=\"".htmlentities($key)."\" value=\"".htmlentities($value)."\" />";
return $var_tree;
Creating a variable inspection and debugging tool using XML data

Taking this one step further, you can then utilize this developed XML format to create more advanced debugging tools. One quick example for this is a small Flex application that I quickly developed to interpret the previous example’s generated XML data. This debugger interface is automatically opened in a separate window when any portal template page embeds the {varviewer} template tag, which can be generated in your site’s local.inc.php file using a code snippet similar to the following.

$tmpl->variables['PORTALPAGE']['varviewer'] = 
"<SCRIPT TYPE='text/javascript'>winRef ="+
"window.open( '/VarViewer/templates/varviewer/PortalVariableViewer.html', 'varviewer',"+
"'height=450, width=750'); </SCRIPT>";

View the demo of this application HERE (user: blogdemo/pass: blogdemo). This XML variable debugger application has also been packaged as a House portal site named VarViewer that you can use and experiment with on your own portal server. You can download it HERE. This is a simple example, but illustrates the possibility of developing a more advanced and searchable Portal template variable arrays debugger.


There are a variety of ways to inspect and debug the Portal template variables. Using PHP’s built in variable display functions, and even custom data XML formats allows for a greater degree of flexibility when working with them. In the end these variables are an important to understand when trying to modify and extend Portal’s appearance and functionality, and using these techniques may help you during this learning process.

10Gb networking and DAM

Posted by Rob Pelmas on Wed, Jun 03, 2009 @ 09:56 AM

Tags: knowledge, how to, DAM Systems, Portal, workflow

We're a bunch of performance geeks here. We've been tweaking blocksizes, stripe, and interleave settings on disk since SGI first gave you access to 'em. Tuning and re-tuning SWAP size, location, type is in our blood. A few percentage points here, double digit gains there, all without more capex. Gotta love it.

Now, anytime a paradigm shift in technology comes out there's a steep cost differential to it, right? 10Gb networking had only a tiny little blip of time when it was out of reach of the masses, which is a refreshing change. You can kit out most servers with a card, an acceptable managed switch with a 10Gb port or two, for a very reasonably cost.

Why go to 10? Our desktops have had Gb cards for what seems like forever, and very fast CPUs. With just a couple 'power' users you could swamp the networking capabilities of a server. Of course, a handful of years ago disks could only cough up 150Mb/sec or so of sustained data, so network tended to not be the gating factor in server  performance. Modern disk starts at well over 300Mb/sec, and if you stripe or otherwise use some common sense design principles you can achieve multiples of that.

 Xinet and NAPC both use the 1 to 6 rule for users and performance: with 6 retouchers (or 'power' users), you can assume 1 of them will be accessing the server at one time. 12=2, 18=3. It's a rough rule of thumb, but one that seems to stand up over time. 12 heavy hitters can thus drain 120Mb/sec out of a server, which is the better part of 2 1Gb cards bonded together. Add in the other users, doing layout, OPI printing (yep, some folks still use an OPI workflow), and Portal access, you've got a saturated pipe. 10gb gives you a good 800mb/sec of access speed, which will sate all but the most demanding organizations needs for data.

Next of course, we can talk about teaming 10Gb interfaces! (insert evil chortle of delight here).


Xinet Automation in the Command Line

Posted by Robert Sullivan on Wed, Apr 15, 2009 @ 09:52 AM

Tags: database, Xinet, how to, workflow

Some people actually prefer to work from the command line in a terminal window.
I know! Can Ya' believe it!
There are somethings that just aren't in the GUI and there are some things you
can just do faster in a terminal window. That is assuming you can type faster
than me.

I had a client call in looking for a way to create a series of "Move Actions"
but wanted to do it as a batch somehow. I couldn't get him a 'batch create' for a
WebNative Venture action, but... command line creation fit the bill.

The idea was for remote users to have an Uploader Application and one of the
mandatory data fields was the client name. The Trigger set would do a 'Compare Action'
and then call a Move to-client-name, within the folder structure. So it's going to be
an automated filing system with Triggers for uploaded assets.

In the folder path: /usr/etc/webnative/actions/
are all of the default Venture action categories, (copy, email, move...) and any
custom action categories we can create ourselves. Within each specific category folder
are the scripts for that action and a settings folder that has a config file for each
action we create.

Here is a sample move action called: "Acme Widgets Incoming"

If I look at that setting from the command line it looks like this:
# cat "Acme Widgets Incoming"
desc=File asset in client folder Acme
It's pretty simple once you compare the GUI to the code settings.
desc is the description of the action
arg0, value, is the destination path we want to move the asset into.
arg1, value=O, is the 'Overwrite' selection.
This value could be 'A' for 'Append Unique Number' or 'F' for Fail
You just need to understand the argument options and the code translation. Now obviously
the different action categories will have other argument options, you just need to review
each one to know the 'value' to assign.

So back to my client's need to create multiple actions quickly. Consistency in the folder
structure and nomenclature is part of the key. All we do is create one 'master' move action
in the WebNative browser window. "Acme Widgets Incoming"
From the command line copy the master to the next client name and then edit the value path.

In the terminal window navigate to the action settings folder.
   cd /usr/etc/webnative/actions/move/settings
Copy paste the master setting to the new client name.
   cp "Acme Widgets Incoming" "Spacely Sprockets Incoming"
Edit the new setting "Spacely Sprockets Incoming" for the correct path-to-folder.
If you need to create a lot of actions that do the same thing to unique paths, this is the
quickest way to go. The command line is not for everybody but for those that know their way
around, its another powerful way to work with the Xinet Venture database. My client now has over
300 move actions, to file uploaded assets into the correct client folder automatically.
All done by lunch time..!
So what's for dessert?


So, how can Xinet help me do. . . . .?

Posted by Brian Dolan on Wed, Apr 01, 2009 @ 11:27 AM

Tags: Xinet, Elegant, knowledge, Dalim, Dialogue, Creative Banks, nTransit, how to

Being in the position that I’m in affords me the opportunity to travel and see many of our clients around the country.  I love working with all of you and you all have your own unique personalities as well as challenges in your respective environments.  Something I want to share with you all is a question I’m often asked, “How can I make Xinet do more for us?  I know it can do X, Y or Z but I only use it for (fill in the blank) and want to do more with it!”  Usually the next questions is, “How do your other clients do it and how are they using Xinet?”  Well, let’s start with the second one. . .how DO other clients work with Xinet.  This is a hard one since all of you use it for different reasons and have unique needs even though many of you are in the same business. 

So, how do I make it do the trick your asking?  Get to it already would ya!

A couple of things to think about before I can suggest anything:

1) Listen to your clients (internal and external)- You know your company and how it ticks better than us.  Yes, we at NAPC all have been around the industry for a long time and bring plenty of knowledge to the table but. . .you're the one hearing the conversations in meetings or through the hallways with questions like, "How can we share out assets to client X but not allow them to do or see Y", or "How can I automate the process of creating multiple PDF's from one print command?", or "How can I customize the interface so it looks like my clients brand?" or "Can I do . . ."  You get the point right???. . .if not, the point is you know your world better than we do so listen to your user community and then start thinking about how to solve their challenges with the tool set at hand. And if the current tool set doesn't accomplish the needed task, then there is most likely a plugin or a solution to make it do the trick like Creative Banks or Elegant or nTransit.  Xinet is an open product so customizations can be done and probably already have been.  Ask us-we'll be happy to help.

2) Be creative yourself- it's easiest to hear from someone that says yeah, we did this thing and it really rocks or ask us to replicate something that was done before but think about how to do "it" yourself.  You may be in IT or work in some IT capacity but that doesn't mean you're not creative!  You are-you just have to find the time to sit down and think about it. I know, I know, easier said than done as we're all super busy but if you want to really do something, you'll make the time. 

3) Is my idea even possible? Look, all technologies have their limits so if you want Xinet to make your coffee (not too strong of course!) AND fold your laundry, you might be pushing it.  So, this is a good time to ask NAPC as well as look at the Xinet manuals.  Seriously, look at the manuals.  I know a lot of you depend on NAPC for the knowledge to be handed to you and we don't mind that at all.  That's what we're here for!  Although, you might be better served by reading up on the technology you manage.  Right!?!?!?!?!?  You've all heard RTFM or to be politically correct I should say RTM but whatever, you get the point.  I've been to plenty of training classes, received lots of great advice from others in and out of the industry but my best resource to date has been the manuals.  Read up everyone!

So really, those ARE my suggestions.  Listen to your clients, be creative yourself in coming up with ways to solve the challenge and do your research by speaking with us and reading up on the Xinet manuals.  Seriously, you all will be waaaay better off in the end if you put the time into it.  Again, I know you're all busy but this is important stuff here right?!?!  Just like working out, which I do all the time! :), it takes dedication and Xinet is no different.

Also, after working the three steps above first, you'll be able to better answer your first question yourself,  "How can I make Xinet do more for us".  And if not, again, we're here to help with suggestions and industry knowledge to get you to where you need to be.

Bottom line, be proactive with learning this stuff . . .it'll really help you in the long run.

Oh yeah, one more thing on this subject, work closely with the people that have a hand in Xinet.  If you're more on the creative side of things, create the relationship needed to work together harmoniously with your IT staff.  Contrary to popular belief, they are truly there to help you, not hold you back even though sometimes it may seem that way.  And, if you're in IT, be open about this stuff and the ideas that may come your way.  Don't start with "No", think about it and be creative in helping solve the problem or challenge at hand by working closely with your clients.  Can I get a "Kum ba ya!"

Any way. . .two quick things before I get off my high horse. . .

1) Dialogue ES is around the corner.  If you're familiar with how Dalim's Dialogue currently works then you'll probably be happy to hear how it's evolving.  This week Dalim is releasing the internal beta so I'll get my hands on it and write another blog entry just on that subject later but some quick things to mention:
The interface has changed quite a bit.- this is good stuff guys and gals. . .totally revamped and much more slick.  Again, more to come later.  As far as functionality, it's totally rewritten from the ground up and now has a database behind it.  This can open up all kinds of possibilities, think about it.  Linear versus non-linear workflows.  So now, instead of having user a, b, then c approve or reject a document, it can be more of fluid approval process and not so much in a linear fashion as it is now.  Also, once a user approves or rejects the document, that action doesn't have to stop the process as it does now in a multi-user approval process.  In other words, if user a rejects the document, user b or c can still approve or reject it themselves versus how it is now.  In the current version, if a user in an approval workflow rejects the document, it's done, that's it.  No one else can approve or reject it using the built in approval tools.  That changes with ES.  New icons for statuses, new list views to easily see all users status, new interface, etc.  Lots more to come there.

Any way, thanks for taking the time to read our blog and I hope you all stay tuned for more from NAPC.  We're dedicated to making you successful!


For more info go to www.napc.com