Access All Content Metadata as CSV

Each night the Digital Broadcaster outputs the Content data table as a CSV file and saves it in the /vol1/database_backups folder. This version provides more detail than the REST service offers.

  1. On a PC or Mac connected to your TelVue Princeton™ server’s network, navigate to /vol1/database_backups.
  2. Save the content_file_<date>.csv to a local drive if you like, where <date> is today’s date.
  3. Use Excel, or similar spreadsheet software, to open content_file.csv and analyze the data.


  1. Bob Hassinger says:


    Looking at this page about accessing content metadata as CSV you talk about “On a PC or Mac connected to your TelVue Princeton™ server’s network, navigate to /vol1”. I do my development from home. Is it possible to set up so I could get to that file from outside the local network (e.g. via the Internet)?


  2. rbrooks says:

    Bob, great question.

    Our hot folders are exposed over two protocols: FTP and Samba. Samba is a suite of several LAN protocols, like NetBIOS and SMB, that allow UNIX/Linux machines to network with Windows machines. When you browse to our box’s shared folders in Windows Explorer on your LAN, you are browsing it over Samba (really NetBIOS). Exposing NetBIOS/SMB through the firewall is highly insecure, and we don’t endorse it, so I won’t recommend that here. NetBIOS and SMB protocols were designed for LAN-use only, so they contain no inherent protection against Internet-based compromises, which can lead to someone accessing resources on your local network.

    There are essentially three ways you can access the hot folders on your Princeton Server from outside your network (ordered most-secure to least):

    • Secure: VPNRecommended – Creates a highly-secure encrypted tunnel through your firewall, then allows you to browse your remote network resources as if they are local.
    • Less Secure: FTPRecommended
    • Not Secure: NetBIOS/SMBNot recommended

    Setting up these types of things is beyond the scope of my blog comment here, but a Systems Administrator (assuming you aren’t one) should know how. Each of the methods outlined above will require some configuration changes to your router. Google can provide some good information on VPN setup. Some routers have VPN features built-in. You may want to Google for something like “vpn endpoint” along with the make and model of your router. That’s should tell you if it has VPN endpoint features. Or, check the documentation for the router, which can be found on the manufacturer’s site.

    If you go the FTP route, look into port forwarding, in other words, opening a hole in your firewall to permit FTP traffic to flow the Princeton Server. Again, you will need to log in to the configuration pages of your router using a web browser. Look for something like “Port Forwarding” under a “Firewall” section perhaps. You basically add a new “Forwarding Rule” and tell it to forward port 21 (the port FTP operates through) to your Princeton Server’s IP address or hostname. If you do go this route, be aware that FTP is definitely less secure than a VPN. FTP passwords are transmitted over the Internet in plain-text, interceptable by anyone with the right tools. To mitigate this, you can also tell your router to only allow certain client IP’s through on FTP port 21. For example, you would set up a rule that says, “Only my IP x.x.x.x of my router at home is allowed to access port 21.” You can also set these restrictions using the local firewall on the Princeton Server. Go to “Firewall Rules” under the “Config” tag. I would definitely recommend you take these extra precautions. I have had FTP passwords “lifted” before and it is no fun. 🙂

    Good luck with it. HTH (Hope this helps.)

  3. Bob Hassinger says:

    Thanks. That gets me to more questions (of course 😉 )

    As it happens I do know a bit about all that – managed and did system programming on DEC VMS systems for many years and have some level of Unix/Linux management familiarity. I do have a very good understanding of system management, what I know and don’t know, and what to do and not do.

    As to having “System Administrator” access – I am not quite sure how to answer – I do have the “Admin” role in the PSG software, but it is not clear if I have root/superuser/whatever access, or any at all at the OS level. I am not sure if anyone except the PSG support folks have that. I have an idea that I do have an account of some sort at the OS level, but I would need some help tracking it down at this point. Also, from home, outside the LAN, I have not sorted out how to telnet into the server. I am not sure if I could log in with privileges (root/superuser) from outside anyway, at least absent a VPN. But then again PSG support seems to be able to get in, so there should be a way.

  4. rbrooks says:

    Bob, you are correct in that TelVue does not provide shell access (command-line / Telnet / SSH) to our products. But, everything I describe does not require that. There is a default user in the system that always exists called psguser. You can always access the /vol1 folder over FTP via this user. You will see this user in the “Users” page of the Config tab. You’ll notice that you cannot delete that user, but you can change its password. Whatever you set that password to is also the FTP password.

    Regarding your question about PSG Support and remote sessions… Generally our Support Department remotes into our servers first by remote-controlling a customer’s desktop machine (via HTTP port 80), then SSH’ing into our server, over the LAN, from there. Firewalls (routers) all come configured to disallow all inbound connections to boxes on the LAN. In other words, all boxes are unexposed to Internet by default. But, all firewalls have port-80 (HTTP) open for outbound connections, by default, so that machines on the LAN can browse the Internet. (Actually, nearly all firewalls come with all ports open for outbound connections.) These browser-based remote-desktop systems, like the one our Support Dept uses, leverage this fact by tunneling all of their data packets through Port 80 outbound on both ends: the customer end and our end – with a tunnel server, hosted by the remote-control software manufacturer, in between facilitating the traffic. So, with no changes to a customer firewall, and no exposing of machines to inbound Internet connections (which would be dangerous), we can remote-control a customer’s desktop machine (with their permission), and subsequently our machines, with no changes to the firewalls on either end. Once inside their network in this manner, we can securely shell into our Princeton Server(s). My point is, that our boxes on customer LAN’s are not exposed to the Internet in any way, by default. In the case of our Support sessions, there is a temporary, voluntary, and secure “reverse-tunnel” set up over port 80. This happens when you click a certain link in one of our “Remote-Session Invitation” emails. That’s the “voluntary” part I was referring to. We cannot remotely access our products without our customers grating us access by clicking a “Initiate Remote Session” link in an email.

  5. John32 says:

    @rbrooks: Not all firewalls allow outbound port 80, more and more corporate networks are using proxies now, There is a test at that checks outbound ports, I’ve ran this test in many corporate environments and almost half the setups I’ve tested block outbound port 80 by default for their employees.