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

Linux based Home Media applications

Discussion in 'TiVo Home Media Features & TiVoToGo' started by lrhorer, Jul 8, 2012.

  1. Jul 8, 2012 #1 of 41
    lrhorer

    lrhorer Active Member

    6,924
    0
    Aug 31, 2003
    San...
    I decided to start this thread because while there are not a huge number of people running applications such as Galleon, pyTivo, or HME for Python under Linux, there are still some of us, and perhaps a few lurking in the bushes who would consider dipping their toe into building a Linux server because of the speed, simplicity, expanded feature set, and stability of a Linux server. Others, perhaps may be thinking of hacking their Linux-based NAS boxes so they can run one of the aforementioned apps.

    Basically, anything related to Linux and a networked TiVo is open for discussion, here. Anything related to specific features of one of the popular HMO or HME applications is probably better suited to one of the application specific threads elsewhere in the forum, but if your need is to write a script for handling downloaded videos or for starting pyTivo automatically at boot time, running an application under wine, or even getting a greenfield Linux installation set up for use with a TiVo, this is the place to be.

    There are several members of this forum who have extensive experience with *nix based systems, and I invite them to participate. I am sure they will be happy to offer assistance to TiVo owners with limited (or no) Linux experience. While I am no Linux expert, I do have some experience with the OS and with interfacing it to TiVo DVRs, and I will be happy to offer my own help as far as I am able.

    So, anyone who is interested or needs help with any aspect of Linux and TiVo, speak up!
     
  2. Jul 8, 2012 #2 of 41
    markmarz

    markmarz Member

    94
    0
    Feb 3, 2002
    Chicago, IL
    Just want to be the first to express my gratitude for this thread. I'm sure I'll be a frequent supplicant. In time, perhaps a resource as well.
     
  3. Jul 8, 2012 #3 of 41
    lrhorer

    lrhorer Active Member

    6,924
    0
    Aug 31, 2003
    San...
    'Just couldn't resist, could you? :)

    Yep. That's the idea. I have to say it really is satisfying to hear of people who benefit from my suggestions, and I think many others are the same. It's not unlikely that one day your expertise may well exceed mine, and that will be just fine by me.
     
  4. Jul 9, 2012 #4 of 41
    Stormspace

    Stormspace Electrocuted by TiVo

    5,171
    0
    Apr 13, 2004
    Hartsville, SC
    I think what would really help people using linux are installation scripts for pyTiVo and that do all the grunt work for you. I'm running an old version of the program and have resisted upgrading simply because I don't want to have to spend an hour or two reconfiguring the interface. As it stands now I have only the media server part working and most of the time in order to recognize new shows on the server I have to restart the service.

    All of this might have been addressed in later versions, but I haven't seen a place that details what's now involved in the installation or configuration of pyTivo.

    Good thread though, I'll be following it.
     
  5. Jul 9, 2012 #5 of 41
    lrhorer

    lrhorer Active Member

    6,924
    0
    Aug 31, 2003
    San...
    I don't know of any that have been puslished, but then installation under Linux is distro dependant and also highly personal. For pyTiVo, HME for Python, and vidmgr, it's pretty trivial though, except for the dependance based init scripts, if any. I have a couple of update scripts that I use, and if you will give me a couple of days or so, I can spiff them up for general distribution. Perhpaps someone else will contribute, as well.

    Note the CONFIGURATION of pyTivo, etc., is beyond the scope of this thread, and is handled by other, platform independant utilities. Installation under Linux is another matter, however, and fits very nicely in this thread.
     
  6. lrhorer

    lrhorer Active Member

    6,924
    0
    Aug 31, 2003
    San...
    OK, here is the first script. It is designed to upgrade to the newest version of vidmgr, whenever Jeff may decide to release one. It could also be used to partially install vidmgr the first time. Using this script requires the following:

    1. HME for Python must already be installed in the <Target> directory.
    2. At least one version of vidmgr must be downloaded into the <Source> directory.
    3. While in the <Source> directory, issue the command

    Code:
    tar -xzvf jbernardis-pytivo-video-mgr2-XXXXXXX.tar.gz
    where XXXXXXX is the version number of the downloaded revision of vidmgr.

    4. In the following script, update the value of SourceDir to <Source>
    5. Update the value of TargetDir to <Target>/vidmgr
    6. Run the script.

    Code:
    #! /bin/bash
    
    # Modify the following three lines to match your local system and software
    TargetDir="/usr/share/pyhme/vidmgr/"
    SourceDir="/RAID/Server-Main/Downloads/TiVo_Upgrade/pyHME"
    AppName="vidmgr"
    
    LastDir=""
    SourceTemp=""
    
    while read NewDir
    do
    	[[ $NewDir -nt $LastDir ]] && SourceTemp=$NewDir
    	LastDir=$NewDir
    done < <( find $SourceDir -type d -name "$AppName" )
    SourceDir="$SourceTemp/"
    if [[ -n $SourceTemp ]]
    then
    	cp -r "$SourceDir"* "$TargetDir"
    	[[ $? -eq 0 ]] && echo Files Copied
    	[[ $? -eq 0 ]] && /etc/init.d/pyHME restart && echo HME for Python restarted
    else
    	echo Source directory not found.  Vidmgr not upgraded.
    fi
    echo
     
  7. lrhorer

    lrhorer Active Member

    6,924
    0
    Aug 31, 2003
    San...
    Next is the script that actually runs HME for Python.

    pyHME:

    Code:
    #! /bin/bash
    PIDFILE=/var/run/pyHME.pid
    RUNDIR=/usr/share/pyhme
    LOGFILE=/var/log/pyhme.log
    cd $RUNDIR
    /usr/bin/nohup /usr/bin/python2.6 $RUNDIR/start.py > $LOGFILE &
    echo $! > $PIDFILE
    exit 0
    This creates a file in /var/run named pyHME.pid that contains the PID of the running HME for Python process and a log file named pyhme.log in /var/log containg HME for Python's stdout stream. It puts the program into the background and divorces it from the parent script, allowing the app to run even after the terminal which spawned it is gone. It's parent process then becomes PID 1, the system init app.

    To automatically run HME for Python at startup on a Debian based system employing dependency based booting, one can create a file such as the following in /etc/init.d.

    /etc/init.d/pyHME:

    Code:
    #! /bin/sh
    ### BEGIN INIT INFO
    # Provides:          pyHME
    # Required-Start:    $remote_fs $syslog $network $pyTivo
    # Required-Stop:     $remote_fs $syslog $network $pyTivo
    # Default-Start:     2 3 4 5
    # Default-Stop:      0 1 6
    # Short-Description: HME Services
    # Description:       Provides HME services for TiVo
    #
    ### END INIT INFO
    
    # Author: Leslie Rhorer
    
    # Do NOT "set -e"
    
    # PATH should only include /usr/* if it runs after the mountnfs.sh script
    PATH=/sbin:/usr/sbin:/bin:/usr/bin
    DESC="HME Services"
    NAME=pyHME
    DAEMON=/usr/share/pyhme/$NAME
    DAEMON_ARGS=""
    PIDFILE=/var/run/$NAME.pid
    SCRIPTNAME=/etc/init.d/$NAME
    
    # Exit if the package is not installed
    [ -x "$DAEMON" ] || exit 0
    
    # Read configuration variable file if it is present
    [ -r /etc/default/$NAME ] && . /etc/default/$NAME
    
    # Load the VERBOSE setting and other rcS variables
    . /lib/init/vars.sh
    
    # Define LSB log_* functions.
    # Depend on lsb-base (>= 3.2-14) to ensure that this file is present
    # and status_of_proc is working.
    . /lib/lsb/init-functions
    
    #
    # Function that starts the daemon/service
    #
    do_start()
    {
    	# Return
    	#   0 if daemon has been started
    	#   1 if daemon was already running
    	#   2 if daemon could not be started
    	if [ -e "$PIDFILE" ];
    	then
    		PIDVAL=$( cat $PIDFILE )
    		ps -ef | grep $PIDVAL | grep -qv grep && return 1
    		rm $PIDFILE
    	fi
    	start-stop-daemon --start --quiet --pidfile $PIDFILE --exec $DAEMON || return 2
    }
    
    #
    # Function that stops the daemon/service
    #
    do_stop()
    {
    	# Return
    	#   0 if daemon has been stopped
    	#   1 if daemon was already stopped
    	#   2 if daemon could not be stopped
    	#   other if a failure occurred
    	if [ -e $PIDFILE ];
    	then
    		PIDVAL=$( cat $PIDFILE )
    		rm -f $PIDFILE
    		kill -15 $PIDVAL 2> /dev/null
    		return "$?"
    	else
    		return 1
    	fi
    }
    
    case "$1" in
      start)
    	[ "$VERBOSE" != no ] && log_daemon_msg "Starting $DESC" "$NAME"
    	do_start
    	case "$?" in
    		0|1) [ "$VERBOSE" != no ] && log_end_msg 0 ;;
    		2) [ "$VERBOSE" != no ] && log_end_msg 1 ;;
    	esac
    	;;
      stop)
    	[ "$VERBOSE" != no ] && log_daemon_msg "Stopping $DESC" "$NAME"
    	do_stop
    	case "$?" in
    		0|1) [ "$VERBOSE" != no ] && log_end_msg 0 ;;
    		2) [ "$VERBOSE" != no ] && log_end_msg 1 ;;
    	esac
    	;;
      restart)
    	#
    	# If the "reload" option is implemented then remove the
    	# 'force-reload' alias
    	#
    	log_daemon_msg "Restarting $DESC" "$NAME"
    	do_stop
    	case "$?" in
    	  0|1)
    		do_start
    		case "$?" in
    			0) log_end_msg 0 ;;
    			1) log_end_msg 1 ;; # Old process is still running
    			*) log_end_msg 1 ;; # Failed to start
    		esac
    		;;
    	  *)
    	  	# Failed to stop
    		log_end_msg 1
    		;;
    	esac
    	;;
      *)
    	echo "Usage: $SCRIPTNAME {start|stop|restart}" >&2
    	exit 3
    	;;
    esac
     
  8. lrhorer

    lrhorer Active Member

    6,924
    0
    Aug 31, 2003
    San...
    For upgrading / installing pyTivo, the essentially the same script used for vidmgr can be used, after updating the SourceDir, TargetDir, and AppName variables.

    In my installation, for example, the values for the three are:

    SourceDir="/RAID/Server-Main/Downloads/TiVo_Upgrade/pyTiVo"
    TargetDir="/usr/share/pyTivo"
    AppName="lucasnz"

    Once again, simply download the git tarball into <Source>, and untar the file. William uses a slightly different directory format for his git, so if you are using his fork, you should have:

    Code:
    AppName="wmcbine-pytivo-*"
    The script, when run, will find all directories under <Source> that match the string $AppName, select the newest, and copy all the files in that directory to <Target>.

    In the gits, the configuration files are named XXXX.dist. That way, when the script runs, the default configuration should not overwrite your custom settings. The first time the software is installed, the user should run the command

    Code:
    cp XXXX.dist XXXX
    and then edit the resulting configuration file accordingly.
     
  9. lrhorer

    lrhorer Active Member

    6,924
    0
    Aug 31, 2003
    San...
    This is the script I use to run pyTivo. Note it is nearly identical to the one that runs HME for Python, except that it redirects both stdout and stderr to the log file.

    pyTivo:

    Code:
    #! /bin/bash
    PIDFILE=/var/run/pyTivo.pid
    RUNDIR=/usr/share/pyTivo
    LOGFILE=/var/log/pyTivo.log
    /usr/bin/nohup /usr/bin/python2.6 $RUNDIR/pyTivo.py > $LOGFILE 2>&1 &
    RetVal=$?
    if [[ RetVal == 0 ]]
    then
         echo $! > $PIDFILE
    else
         rm -f $PIDFILE
    fi
    exit $RetVal
    The init script is also very similar:

    /etc/init.d/pyTivo:

    Code:
    #! /bin/sh
    ### BEGIN INIT INFO
    # Provides:          pyTivo
    # Required-Start:    $remote_fs $syslog $network
    # Required-Stop:     $remote_fs $syslog $network
    # Default-Start:     2 3 4 5
    # Default-Stop:      0 1 6
    # Short-Description: pyTivo Multimedia Server
    # Description:       Provides the pyTivo video server for TiVo
    #                    
    ### END INIT INFO
    
    # Author: Leslie Rhorer
    #
    # Please remove the "Author" lines above and replace them
    # with your own name if you copy and modify this script.
    
    # Do NOT "set -e"
    
    # PATH should only include /usr/* if it runs after the mountnfs.sh script
    PATH=/sbin:/usr/sbin:/bin:/usr/bin
    DESC="pyTivo Multimedia Server"
    NAME=pyTivo
    DAEMON=/usr/share/pyTivo/$NAME
    DAEMON_ARGS=""
    PIDFILE=/var/run/$NAME.pid
    SCRIPTNAME=/etc/init.d/$NAME
    
    # Exit if the package is not installed
    [ -x "$DAEMON" ] || exit 0
    
    # Read configuration variable file if it is present
    [ -r /etc/default/$NAME ] && . /etc/default/$NAME
    
    # Load the VERBOSE setting and other rcS variables
    . /lib/init/vars.sh
    
    # Define LSB log_* functions.
    # Depend on lsb-base (>= 3.2-14) to ensure that this file is present
    # and status_of_proc is working.
    . /lib/lsb/init-functions
    
    #
    # Function that starts the daemon/service
    #
    do_start()
    {
    	# Return
    	#   0 if daemon has been started
    	#   1 if daemon was already running
    	#   2 if daemon could not be started
    	if [ -e "$PIDFILE" ];
    	then
    		PIDVAL=$( cat $PIDFILE )
    		ps -ef | grep $PIDVAL | grep -qv grep && return 1
    		rm $PIDFILE
    	fi
    	start-stop-daemon --start --quiet --pidfile $PIDFILE --exec $DAEMON || return 2
    }
    
    #
    # Function that stops the daemon/service
    #
    do_stop()
    {
    	# Return
    	#   0 if daemon has been stopped
    	#   1 if daemon was already stopped
    	#   2 if daemon could not be stopped
    	#   other if a failure occurred
    	if [ -e $PIDFILE ];
    	then
    		PIDVAL=$( cat $PIDFILE )
    		rm -f $PIDFILE
    		kill -15 $PIDVAL 2> /dev/null
    		return "$?"
    	else
    		return 1
    	fi
    }
    
    
    
    case "$1" in
      start)
    	[ "$VERBOSE" != no ] && log_daemon_msg "Starting $DESC" "$NAME"
    	do_start
    	case "$?" in
    		0|1) [ "$VERBOSE" != no ] && log_end_msg 0 ;;
    		2) [ "$VERBOSE" != no ] && log_end_msg 1 ;;
    	esac
    	;;
      stop)
    	[ "$VERBOSE" != no ] && log_daemon_msg "Stopping $DESC" "$NAME"
    	do_stop
    	case "$?" in
    		0|1) [ "$VERBOSE" != no ] && log_end_msg 0 ;;
    		2) [ "$VERBOSE" != no ] && log_end_msg 1 ;;
    	esac
    	;;
      restart)
    	log_daemon_msg "Restarting $DESC" "$NAME"
    	do_stop
    	case "$?" in
    	  0|1)
    		do_start
    		case "$?" in
    			0) log_end_msg 0 ;;
    			1) log_end_msg 1 ;; # Old process is still running
    			*) log_end_msg 1 ;; # Failed to start
    		esac
    		;;
    	  *)
    	  	# Failed to stop
    		log_end_msg 1
    		;;
    	esac
    	;;
      *)
    	echo "Usage: $SCRIPTNAME {start|stop|restart}" >&2
    	exit 3
    	;;
    esac
     
  10. lrhorer

    lrhorer Active Member

    6,924
    0
    Aug 31, 2003
    San...
    The following only applies if the user is employing dependency based booting on a Debian or Debian derivative system. If one is employing legacy (manual) boot script ordering, it does not apply, and of course it does not apply to any distro that is not Debian based, although the scripts themselves should work with just about any distro.

    Notice in the LSB header of the /etc/init.d/pyHME script there are two lines:

    Code:
    # Required-Start:    $remote_fs $syslog $network $pyTivo
    # Required-Stop:     $remote_fs $syslog $network $pyTivo
    This tells insserv that the script in question should not be run until after the "pyTivo" service is up and running. I don't actually know that this is strictly necessary in this case, but there might be some unexpected results if one tries to run vidmgr or jukebox before pyTivo, upon which they depend, is active. It also makes sure HME for Python is shut down prior to shutting down pyTivo when the sytstem is shutting down or rebooting. I'm pretty sure this is not necessary in this case, but it is a good practice in general.

    In order for this to work properly, one must register pyTivo as a service. To do so, one simply edits the file /etc/insserv.conf and adds the line

    Code:
    $pyTivo		pyTivo
    This tells insserv the script /etc/init.d/pyTivo implements the pyTivo service. When ordering the boot scripts, then, update-rc.d and insserv make sure the /etc/init.d/pyHME script is run after the pyTivo script and is shut down prior to pyTivo being shut down.
     
  11. lrhorer

    lrhorer Active Member

    6,924
    0
    Aug 31, 2003
    San...
    Both pyTivo and the TiVos themselves have web interfaces. Consequently, as most of you know, a web browser can be used to control them. In particular, pyTivo has a web interface that not only allows one to configure pyTivo, but also to push videos from the server to a TiVo or to download videos from a TiVo to the server. Similarly, the TiVos themselves allow downloading of videos to the host machine via secure HTTP using a browser. There is a utility out there, however, that allows a person writing a script (or an app like kmttg, as a matter of fact) to automate web operations. That utility is curl. Strictly speaking, curl is not a Linux app, because there are ports for other Operating Systems, including DOS/Windows. I mention it here, however, because there is a Linux port, and I think those of us running Linux servers may well want to implement curl to handle various aspects of Home Media.

    In short, curl will take a CL argument and pass it to any web server. This means essentially anything that can be done using a browser can also be done using curl. For example, I wrote a web application that itself uses curl to control pyTivo. From anywhere in the world, I can log in to my sever and view almost all of the videos on the server. From there I can select one and have pyTivo push the video to one of my TiVos. The command used to implement this is:

    Code:
    curl -d "File=$DirName%2F$MetaFile&Command=Push&Container=$Share&tsn=HD+Theater" http://raid-server:9032
    Where $DirName is the fully qualified file name of the video to push and $MetaFile is the fully qualified file name of the metafile.
     
  12. lrhorer

    lrhorer Active Member

    6,924
    0
    Aug 31, 2003
    San...
    If one redirects the stdout and stderr of pyTivo to a log file, after a while that log file can grow quite large and unweildly, as is the tendency with log files. Many Linux distros include the logrotate utility for this very reason.

    When logrotate runs, it checks its configuration directory (typically /etc/logrotate.d) for target applications to manage. Each managed application will have its own configuration file. In this case, one might create a file named "pyTivo", with its configuration options. Given the nature of pyTivo's output and the nature of what it does, it is probably sufficient to keep no more than 1 - 2 weeks of logs, and it is probably not necessary to compress the logs. Due to the way logrotate works, this means deleting the previously saved log file, renaming the current log file, and creating a new, empty log file.

    Because logging of pyTivo is accomplished by redirecting stderr and stdout, the application does not open and close the log file every time it needs to write, but rather the file is opened and kept open until the application is terminated. Thus, even if an external process like logrotate renames the log file (or even deletes it), the application continues to write to the same file. Thus, the old log file will continue to grow, even though it has a new name (or even has been deleted), and nothing will ever be written to the new log file. This is good in that even if the application is currently writing to the log file, renaming the file doesn't interrupt or corrupt the logging. It is bad, of course, in that logrotate hasn't really done anything very useful at this point.

    In such cases, it is necessary to stop and restart the application so that it will stop writing to the old log file and start writing to the new one. Well, that is simple enough.

    First of all, logrotate provides a directive for just such a purpose. It is called "postrotate". When logrotate encounters this directive and its terminator, which is named "endscript", it executes all the commands between the two markers sequentially. One could then just put something like this in the config file:

    Code:
    postrotate
         /etc/init.d/pyTivo restart
    endscript
    This will certainly work, but there is a bit of a hitch.

    The second thing is that using this elementary approach is liable to kill pyTivo while it is right in the middle of sending a show from the server to a TiVo. That wouldn't be very nice, although depending on one's viewing habits it probably would not happen all that often. One way around this would be to send pyTivo a signal that tells it to shut down gracefully after it is done transferring all its current jobs. I do not know if William has implemented or would be interested in implementing a trap in his code to handle this sort of signal, however. If he reads this and responds in the affirmative, then there is a fairly slick way to handle the situation. Not knowing if that is or ever will be the case, then, we have to handle it in a little more of a brute force fashion. The following script will check to see if pyTivo is transferring any files, and if so wait 60 seconds to check again and do so continuously until it isn't transferring anything, and then restarts the application.

    Edit 11/06/2012: I ran across what is effectively a bug in the following routine this morning. If one of the transfer processes hangs (or one runs Jukebox, turns off the TV, and forgets about it), the script below could loop forever. I've added a timer that kills the process aftrer 6 hours. If that isn't long enough, increase the value of the Trans_Elapse variable.

    logcheck:
    Code:
    #! /bin/bash
    VideoDir=/RAID
    PIDFile=/var/run/pyTivo.pid
    InitFile=/etc/init.d/pyTivo
    Trans_Elapse=360
    
    check_transfer () {
            lsof | grep -f "$PIDFile" | grep -q "$VideoDir"
    }
    
    check_transfer
    Test=$?
    while [[ $Test == 0 ]]
    do
            echo Found $( date )
            sleep 60
            Trans_Elapse=$(( $Trans_Elapse - 1 ))
            [[ $Trans_Elapse == 0 ]] && break
            check_transfer
            Test=$?
    done
    "$InitFile" restart
    Of course, the $VideoDir, $PIDFile, and $InitFile variables would need to be adjusted to match the individual parameters of the user's system. With the above script in place in /usr/share/pyTivo/logcheck, the logrotate config file could be:

    Code:
    /var/log/pyTivo.log {
    rotate 2
    weekly
    postrotate
            /usr/share/pyTivo/logcheck
    endscript
    }
    Now, there are a couple of vulnerabilities to this approach I need to mention. The first is this creates a bit of a race condition, where between the time the script decides pyTivo isn't busy and the time the init script kills the current instance of pyTivo, pyTivo could possibly start transferring a video. Given this period of time is at most a few milliseconds, it's quite unlikely, but it is possible. Perhaps the most likely thing is a push to one of the TiVos is scheduled, but has not yet actually started to transfer when pyTivo is killed, and the Tivo then looks for a non-existent pyTivo server. The good news is this would be an exceedingly rare occurrence, and it would only happen at the very beginning of a transfer, not half-way through or almost at the end.

    The other vulnerability has to do with the user creating multiple shares on a system. The $VideoDir variable points to the highest directory where all the shares are found. Thus, in my system, all the shares are subdirectories of the /RAID mount point. I have /RAID/Recordings, /RAID/Music, /RAID/DVD, etc. All of the files are either somewhere in /RAID/xxx[/yyy/zzz...] themselves or are symlinks pointing to files in /RAID/xxx[/yyy/zzz...]. Thus, although the `lsof` utility finds a fair number of open files throughout the system (see below), the filter `grep -q "VideoDir"` insures that only files somewhere in /RAID are considered to be ones being transferred by pyTivo. If the user has multiple pyTivo shares configured and any of them are not in the subdirectory tree of a single parent directory, then those files will not be noticed by the script. For example, if my share were not /RAID/Recordings, /RAID/Music, /RAID/DVD, etc. but rather /Recordings, /Music, /DVD, etc, then no single value of $VideoDir will suffice to catch all the shares except for "/". The problem with using "/" as the filter, however, is while it will without question produce a positive result if any file is being transferred, it will in fact always produce a positive result because pyTivo always has a number of files open that are not transferring videos:

    Code:
    RAID-Server:/etc/logrotate.d# PIDFile=/var/run/pyTivo.pid
    RAID-Server:/etc/logrotate.d# VideoDir=/
    RAID-Server:/etc/logrotate.d# lsof | grep -f "$PIDFile" | grep "$VideoDir"
    python2.6  9129       root  cwd       DIR                9,2      4096          2 /
    python2.6  9129       root  rtd       DIR                9,2      4096          2 /
    python2.6  9129       root  txt       REG                9,2   2617520   10616897 /usr/bin/python2.6
    python2.6  9129       root  mem       REG                9,2    165744   10619143 /usr/lib/libexpat.so.1.5.2
    python2.6  9129       root  mem       REG                9,2     61856   10725091 /usr/lib/python2.6/lib-dynload/pyexpat.so
    python2.6  9129       root  mem       REG                9,2     80712   10379349 /lib/libresolv-2.11.3.so
    python2.6  9129       root  mem       REG                9,2     22928   10379368 /lib/libnss_dns-2.11.3.so
    python2.6  9129       root  mem       REG                9,2      9456   10379508 /lib/libnss_mdns4_minimal.so.2
    python2.6  9129       root  mem       REG                9,2     85920   10725101 /usr/lib/python2.6/lib-dynload/datetime.so
    python2.6  9129       root  mem       REG                9,2     51728   10379285 /lib/libnss_files-2.11.3.so
    python2.6  9129       root  mem       REG                9,2     22256   10725086 /usr/lib/python2.6/lib-dynload/_heapq.so
    python2.6  9129       root  mem       REG                9,2   1527584   10642137 /usr/lib/locale/locale-archive
    python2.6  9129       root  mem       REG                9,2   1437064   10379360 /lib/libc-2.11.3.so
    python2.6  9129       root  mem       REG                9,2    530736   10379373 /lib/libm-2.11.3.so
    python2.6  9129       root  mem       REG                9,2     93936   10617266 /usr/lib/libz.so.1.2.3.4
    python2.6  9129       root  mem       REG                9,2   1693344   10617102 /usr/lib/libcrypto.so.0.9.8
    python2.6  9129       root  mem       REG                9,2    349248   10618803 /usr/lib/libssl.so.0.9.8
    python2.6  9129       root  mem       REG                9,2     10648   10379361 /lib/libutil-2.11.3.so
    python2.6  9129       root  mem       REG                9,2     14696   10379372 /lib/libdl-2.11.3.so
    python2.6  9129       root  mem       REG                9,2    131258   10379355 /lib/libpthread-2.11.3.so
    python2.6  9129       root  mem       REG                9,2    128744   10379356 /lib/ld-2.11.3.so
    python2.6  9129       root    0r      CHR                1,3       0t0        580 /dev/null
    python2.6  9129       root    1w      REG                9,2     13697    4661339 /var/log/pyTivo.log
    python2.6  9129       root    2w      REG                9,2     13697    4661339 /var/log/pyTivo.log
    Making sure pyTivo is not killed while it is transferring content from shares in directories that have no common ancestor other than / requires special handling.

    Note a graceful shutdown of pyTivo will avoid this vulnerability, but not the first one above, or at least not directly.
     
  13. lrhorer

    lrhorer Active Member

    6,924
    0
    Aug 31, 2003
    San...
    <moved from the pyTivo thread>

    The first script, contained in the directory pointed to by the $DAEMON variable in the second script, is what actually runs and daemonizes pyTivo, setting up the log file and the PID file, spawing pyTivo as a detached process in the background, and returning a value that reflects whether this process was successful or not. It can be run by itself to start pyTivo, provided of course pyTivo is not already running. This file can easily be modified to meet changing situations specific to pyTivo.

    The second script is the init script, which should be much more static than the pyTivo script, merely calling the daemon script and putting the result into the startup logs.

    Doing it this way makes things more modular and more future-proof, allowing for there to be changes in the particulars of the pyTivo daemon without having to monkey with the init script while also allowing for there to be future changes to insserv or the init process without having to deal with any particulars of the pyTivo daemon. It also can make trouble-shooting one or the other much easier.
     
  14. Soapm

    Soapm Active Member

    1,564
    0
    May 9, 2007
    So close,...
    Whoops... Didn't notice you brought my question over and answered it. Thanks...
     
  15. Soapm

    Soapm Active Member

    1,564
    0
    May 9, 2007
    So close,...
    Ok, I made the first script a file in the pyTivo directory then altered the second script to point to that file. It works but I still get the same results, I have 9 in my movies folder until I restart pyTivo.

    I'm can't even figure out what's common about the 9 that show up but it's consistently the same 9 shows???
     
  16. justen_m

    justen_m Cheesehead

    7,924
    16
    Jan 14, 2004
    Boise, ID
    Any chance this thread could be perma posted as an FAQ?
     
  17. lrhorer

    lrhorer Active Member

    6,924
    0
    Aug 31, 2003
    San...
    It's been a while, so I'm fuzzy on the details, but I seem to recall something similar happening to me in the past. I'm not certain, but I think it had to do with zero length files, or maybe broken symlinks. Are any of the video files or metafiles in any of your shares zero length or otherwise corrupted?

    Another guess would be files with problematical file names. Do any of the file names (including directory names) on any of your shares have a name with any of the following characters:

    : \ ' " ` ? & /

    A leading period ( "." ) could also cause trouble.

    Symlinks to non-existent files can also be trouble. (In fact, IIRC, I think that is what caused my trouble.) Do an `ls -l` in all of your shares to make absolutely certain there are no symlinks and if there are, make absolutely certain they are not broken.

    Also, you are not specific whether this is in the NPL or under vidmgr. Are you running vidmgr? If so, are the results there the same as in the NPL? If you aren't running vidmgr, you might consider running it if for no other reason than troubleshooting this issue. Also, it occurs to me it might help with diagnosis if you run pyTivo in debug mode. Set "debug = True" in the config file, restart the server, and try to duplicate the issue. Look at the log file, and perhaps reproduce it here.
     
  18. lrhorer

    lrhorer Active Member

    6,924
    0
    Aug 31, 2003
    San...
    It has been stickied in this forum.
     
  19. windracer

    windracer joined the 10k club

    11,580
    3
    Jan 3, 2003
    St. Pete, FL
    This probably belongs in one of the old Galleon threads and not this one, but ...

    I don't think the resolution line is necessarily the error. What version of Galleon are you using? You could also try to turn on debugging so there's more information in the log that might help determine the cause of that "event opcode 10."
     
  20. lrhorer

    lrhorer Active Member

    6,924
    0
    Aug 31, 2003
    San...
    Hey, that's kinda cool.

    It would be easier to read your logs if you did not use a tiny font and wrapped them in code tags:

    Code:
    19:43:07,426  INFO [Acceptor] HDApplication - Received resolution event: ResolutionInfo[current=Resolution[width=640,height=480,aspectNumerator=1,aspectDenominator=1],supported=Resolution[width=1280,height=720,aspectNumerator=1,aspectDenominator=1]Resolution[width=704,height=480,aspectNumerator=40,aspectDenominator=33]Resolution[width=640,height=480,aspectNumerator=1,aspectDenominator=1]]
    19:43:07,426  INFO [Acceptor] AppHost - unknown event opcode : 10
    19:43:18,810  INFO [Acceptor] AppHost - connection to receiver closed
    
    Have you checked your system logs for an event right about the same time?

    The log you posted looks to me like input to log.txt. Have you checked wrapper.log?
     

Share This Page