Although it is uncommon, you may run across assets that you're not able to download or share from the web interface. When a user clicks on the download button, an error pops up, "Some of your assets may not download."
This error indicates that the asset has a Location status of "Unknown". Identifying this may not be obvious at first but after looking at this attribute, you may find that it is the cause of an issue you're experiencing. Possible issues that occur as a result of this are:
- You can't download an asset. When you look at the Action menu, the "Download" option isn't there or causes an error.
- Repurposing, Zoom, or other actions are not present or cause errors.
If you're having one or more of these issues, looking at the "File Info" tab on the asset while in Detail view can confirm whether or not this is the cause. If an asset cannot be found by NetX, it will report the location as "Unknown".
Currently, the known cause of this issue is a mismatch between the physical path of the asset on the repository and the path as listed in the database. This issue has a number of causes: deletions made directly to the NetX repository, problems during asset reorganization or renaming, etc. If you experience this issue on a few assets, you can reimport the assets in question to resolve the problem. If you see this on a large number of files, please contact Support for assistance.
Investigating unknown assets (on-premise only)
You may want to pursue an investigation on your own — perhaps you're curious, or perhaps you'd like to expedite the Support process. This section walks you through how a NetX Engineer would start the investigation.
First, it's important to emphasize that if you have a number of "location unknown" assets, it's really best to pick one and then investigate that one example. Nearly always, what happened to one, happened to all of your lost assets. We start on an asset with the "Unknown" location status:
Next, scroll up and obtain the Asset ID:
And the Path:
The root issue with an "unknown" status asset is that the path here does NOT match a file on the file system.
So, the very next thing to do is to look at the file system and see if it's there. If it's not there, and you have the file handy, you can simply copy it back, and then restart NetX. This will immediately resolve the issue.
However, the story may not end there. You may want to dig deeper and figure out what happened. To do that, it's good to understand the underlying data model. The path above resides in the "image" table in the database. Using the Asset ID, you can perform this SQL query on your database (using MySQL as an example):
mysql> select path,status from image where image_id = 14;+----------------------------------------------------------------------------+--------+ | path | status | +----------------------------------------------------------------------------+--------+ | file:///netx/8.9/netx/repository/Lost/04-albuquerque-solar-eclipse-670.jpg | 0 | +----------------------------------------------------------------------------+--------+
Sometimes a lost asset is caused by a mismatch between the Operating System character set and the database character set. NetX highly recommends using UTF8 and Unicode wherever possible; this should help avoid character set issues. However, many databases — even when set to UTF8 — do not fully support 4-byte characters. Digging into the database and looking at the files system can sometimes expose a character set mismatch.
However, sometimes the story doesn't end there. Sometimes, there may have been some unforeseen interruption in the movement of the file within NetX. That is, as the asset is moved within the NetX folder structure, the files are correspondingly moved on the filesystem. So if there is some sort of failure or interruption in this move process (maybe the server crashed, for example), then there could be a situation where the database record and the file system path are not aligned. For a situation like this, the asset_path_journal can be useful. Here's the schema:
mysql> desc asset_path_journal;+-------------+------------+------+-----+---------+-------+ | Field | Type | Null | Key | Default | Extra | +-------------+------------+------+-----+---------+-------+ | journal_id | bigint(20) | NO | PRI | NULL | | | asset_id | bigint(20) | YES | MUL | NULL | | | path | text | YES | | NULL | | | timestamp | datetime | YES | | NULL | | | file_length | bigint(20) | YES | | NULL | | +-------------+------------+------+-----+---------+-------+
Basically, every time NetX moves the path in the image table, it records that path in this table as a journal. In fact, if NetX finds an asset with a path that has no corresponding file system file, then NetX will attempt to "recover" the file by scanning past paths; if it finds a file in an older path, it will update the image path and effectively resolve the issue internally.
Here's an example of how to query this table for a specific asset ID:
mysql> select * from asset_path_journal where asset_id = 14;+------------+----------+---------------------------------------------------------------------+---------------------+-------------+ | journal_id | asset_id | path | timestamp | file_length | +------------+----------+---------------------------------------------------------------------+---------------------+-------------+ | 14 | 14 | /netx/8.9/netx/repository/Sync/test2/test11/one_thousand/0001.txt | 2016-11-27 12:15:49 | 4 | | 20 | 14 | /netx/8.9/netx/repository/Sync/Test3/474989-statler-and-waldorf.jpg | 2016-11-27 15:49:32 | 64304 | | 25 | 14 | /netx/8.9/netx/repository/Lost/04-albuquerque-solar-eclipse-670.jpg | 2016-12-08 13:04:21 | 25997 | +------------+----------+---------------------------------------------------------------------+---------------------+-------------+