1. This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.

built debian server to host tivo hd recordings, next steps?

Discussion in 'TiVo Home Media Features & TiVoToGo' started by markmarz, Jun 2, 2012.

  1. markmarz

    markmarz Member

    94
    0
    Feb 3, 2002
    Chicago, IL
    Yes! The fog is clearing!

    I knew nothing about this; this explanation helps a lot.

    Great! But I'm unclear on whether or not I'm running an XDMCP session ever. I think this is the protocol that would be used by (say) X-Ming, right? If that's the case then I'd only have such a session if I kicked off X-Ming, I reckon. Tried grepping xdmcp variations from ps, no show.

    See above re XDMCP. Here's something I didn't notice before: the login (greeter?) screen has a menu option at the bottom of the screen which offers Console Login as an option. Great! That gives me half of what I need.

    How, after logging in on the console on the server, can I switch to a GUI session on the server? I tried logging out and that will pop up the initial greeter screen where I have this option. The Samba daemon (for example) still is happily running. But I imagine if I were to kick off a program from the command line, say pyTivo, then logging out would kill it. Right? Soon I'm going to attempt your init.d scripts for pyTivo and pyhme so they run as daemons. That'll probably open some questions on that thread!

    Indeed I did.

    I didn't. Tried grepping lxde, xde, kdm .. still same display as before. What I did was open a new Putty session using SSH, as usual. Then I kicked off X-Ming and then Leafpad, which displayed correctly on my pc. Then tried ps -ef | grep lxde and so on with no change. This I'm sure is not an essential point; something is running somewhere to support my X session!

    Thanks a million!
     
  2. markmarz

    markmarz Member

    94
    0
    Feb 3, 2002
    Chicago, IL
    BTW .. and this is amazing to me .. now at idle the server is pulling 25 watts :D, and when doing all I can imagine I'd want it to do at once .. ie, pushing an avi, syncing raid (using SnapRaid, my bad), and just for the heck of it adding a file through Samba on my windows client & pulling another at the same time .. it uses 35 - 40 watts with a momentary peak at 45. In other words, the energy bill is halved!!

    I might replace the 160gb boot drive with a solid state drive and should be able to chop off another 6 watts. Man, 19 watts for a server with 12TB+ ?! Woo hoo!! :up::up::up:

    Worth repeating!
     
  3. lrhorer

    lrhorer New Member

    6,922
    0
    Aug 31, 2003
    San...
    You certainly don't have to, but in some cases it can be convenient. For example, having multiple Xterms active using the tabbed terminal feature of KDE can be very handy. Cut-and-paste is much easier and more powerful under KDE than under Windows, etc.

    Well, it is one of them. X-Ming provides all the protocol support for X-Server operation, including XDMCP, X-Windows, etc. It allows you to import an X display into a window, export a DE into a window, replace the Windows DE with a foreign one, and so forth. The latter two are done via XDMCP. XDMCP stands for X Display Manager Control Protocol. Basically, it is a means of bringing a DM remotely. If the user is not going to log in to a DE, then he doesn't need a DM. If he doesn't need a DM, then he doesn't need XDMCP. Using ssh or PuTTY to log in to an X machine and export an X client to some other machine (not necessarily the machine from which the ssh / PuTTY session is spawned), then no DE, DM, or XDMCP is required or will be running on the local server for any sessions spawned from that Xterm. An X-server (in this case X-Ming) is required, however.

    Well, X-Ming is required for any X-server operations, not just XDMCP. It supplies the display(s) on the remote machine, whether for XDMCP, X-window client sessions, whatever.

    Oh, well, yeah, you won't. XDMCP is not an application, it is a protocol supported by most X-servers, plus it runs on the X-server, not the X-client machine. The DM and then the DE run from the client machine, at the behest of the XDMCP protocol running on the X-server.

    Yep.

    Yep, as well as options to spawn one of a number of different DEs (if installed) and the ability to spawn a DE from a different X-client machine.

    I think it gives you all of what you need, really.

    Well, it might be possible to run KDM, but there is no reason to do that. You already had KDM running, and simply exiting will take you back to KDM.

    That is an entirely different matter, and it won't make any difference if pyTiVo or anything else that has not been daemonized is run from a parent session. Killing that session will kill the child process, whether the parent is a text app or a GUI.

    To daemonize an app that is not a daemon binary (like SAMBA, FTPD, telnetd, etc.) requires two steps. The first is to spawn the app in the background, rather than the forground. This is very easy to accomplish. Simply add an ampersand (&) to the very end of the command line. This sequesters the app into a separate, non-interactive thread tree and returns console control to the parent. Note this won't work very well if the spawned app requires any input from the user.

    The second step is to use a detachment utility to spawn the app as a detached process. At a high level, what this does is prevent the spawned app from responding to signals from the parent app. At a low level what happens is the app is detached from the PID of the parent app and attached to the init thread (PID 1). The utility most often used to accomplish this is called `nohup`, which is short for NO-HangUP. It provides for a number of options, including automatic re-direction of stdout and stderr.

    In the simplest incantation, daemonizing pyTivo can be done by merely typing

    Code:
    nohup python pyTivo.py &
    Whether invoked from a GUI, an ssh text session, or an automated script, that session of pyTivo wil not terminate when the parent terminates.

    OK. That is precisely what I would recommend. The System V init utility provides some very powerful and elegant ways to handle the starting and stopping of system daemons. If you are at all familiar with modular scripting methods, then the init files will be a breeze. If not, then it can take a bit to understand the structure of these utilities, but the use of them is dead simple. One simply types the qualified name of the init file and then the single option start, stop, restart, or reload. Any time the init utility implements a runlevel change, the scripts are all invoked in appropriate order with the command tail appropriate to the runlevel being entered.

    No, no. It is an essential point to your stated intent. LXDE and KDE were NOT running. That is why nothing but the KDM reference showed up. I think this has in fact accomplished everything you really want to happen. If you spawn an XDMCP session from the Windows PC, or if you log in to the console on your Linux machine, you will see quite a few threads related to KDE (or LXDE, or both) running on the machine. Just spawning an X-window or ten won't.

    Really? Small bills, please. :D
     
  4. lrhorer

    lrhorer New Member

    6,922
    0
    Aug 31, 2003
    San...
    Go green.

    There's some cool stuff going on there, isn't there?

    Yeah that would work just fine. A USB thumb drive would save a bit more even and would cost less, too. The server performance would not suffer, and the UI performance would not be hideous.
     
  5. markmarz

    markmarz Member

    94
    0
    Feb 3, 2002
    Chicago, IL
    As usual you've given me a lot to absorb, but I'll study what you've given me and of course do some background reading as well. Can't tell you enough how grateful I am to you!
     
  6. markmarz

    markmarz Member

    94
    0
    Feb 3, 2002
    Chicago, IL
    You know I actually have installed Debian on a thumb drive and ran it from there fine. Only concern is I've been picking up .. right or wrong .. that thumb drives tend to be less reliable than ssd's, and even the latter has problems. It so happens that I had been storing a few movies on a 64gb thumb drive and when I tried to pull them off, I had read errors on a couple. There's also wear leveling considerations, etc etc. So I haven't yet come down on the ssd/thumb drive decision.

    I'll be reviewing your comments in another thread about backup strategies for the boot drive.
     
  7. lrhorer

    lrhorer New Member

    6,922
    0
    Aug 31, 2003
    San...
    That is quite correct, which is why if you do go with a bootable thumb drive, you want to make some changes to the Linux configuration. First of all, you want to have /var, /tmp and the swap plus any other directories that get written on a continual basis on the hard drive, not the thumb drive. Then there are certain other changes that need to be implemented to place certain Linux facilities either on the hard drive or in memory. Basically, you want to make sure the system is not writing to the media continuously.
     
  8. markmarz

    markmarz Member

    94
    0
    Feb 3, 2002
    Chicago, IL
    Yes, I'd like to move as much as possible to part of that 4GB of ram I'm not currently using. If I'm going with flash I'd rather avoid writing to a spinning hard drive as well. The more I do that, the less it makes sense to use flash.
     
  9. markmarz

    markmarz Member

    94
    0
    Feb 3, 2002
    Chicago, IL
    Also even if the boot drive is spinning 24 (though usually idle & spinning) hours a day .. which may be the case since for some reason it ignores my spindown command .. the rough average cost per day is 2 to 3 cents.

    Maybe I'm getting a bit crazy on the green side. Of course there's more to the cost than dollars and cents. But that's a whole other discussion. Mainly just trying to get some perspective.
     
  10. lrhorer

    lrhorer New Member

    6,922
    0
    Aug 31, 2003
    San...
    Well, using loop devices, it is possible to move all writes off any sort of drive. That's how a lot of embedded Linux systems do it. The down side is one looses any log information whenever the system crashes or gets rebooted. That in turn can make it devilishly difficult to troubleshoot kernel panics or other problems. OTOH, on a very stable system like a server, it is not at all an unreasonable thing to do, and in such a case the frailty of a USB drive is minimized. One can even boot from CD-ROM. It doesn't get cheaper than that, or easier to make backups.
     
  11. markmarz

    markmarz Member

    94
    0
    Feb 3, 2002
    Chicago, IL
    Both very interesting subjects to explore, thanks!

    Just one question re CD-ROM boots .. why would a backup of the boot drive be necessary? I'm presuming all write activity to the boot drive is suppressed, so there would be no adjunct files on some writable media to backup, right? If that's the case then you might backup the CD-ROM once for safety and never again. Unless you change things. Right?
     
  12. lrhorer

    lrhorer New Member

    6,922
    0
    Aug 31, 2003
    San...
    That's right. Of course, at about $0.10 a copy, I think you could afford at least two. :D
     

Share This Page