VidMGR

No, it's not. The point of VidMGR is to initiate "pushes", a special type of transfer, from the TiVo rather than from a browser. If your goal is to watch videos while they're transferring, then you should use the standard pyTivo "pull" interface at the bottom of the Now Playing list.

Click to expand...

Well, I wouldn't quite put it like that. Watching videos while they are transferring with a pull is no problem. There may be a brief delay before one can start viewing, is all, when transferring high bit rate or 720p .mpg files. Personally I find this less annoying than pauses while in the middle of viewing the material. I eliminate both, however, by recoding everything to h.264 before storing it on the hard drive.

Now, in the case of a pyTivo transfer, the stream generally is coming in at an acceptable rate

Click to expand...

Well, that depends. Even with an S3, 720p content just does not transfer fast enough if it is coded as .mpg, and anything whose average bit rate exceeds 17 Mbps also generally does not transfer quite fast enough if it is coded as .mpg. With the THD, the issue is even worse.

Certain types of files don't require transcoding: MPEG-2 program streams (as you discovered), h.264 MP4 files, and a subset of VC-1 WMV's. In this case, pyTivo can give the exact size, so you won't get the warning message, because the TiVo can see that the file is coming in as expected.

Click to expand...

Again, that's not always true. Indeed, with most .mpg pushes, I get at least a minute or two of buffering before the program will start, even if I have both tuners disabled. Mp4 pushes are another matter, and along with the space savings, that is why I recode all my videos to h.264 in a .mp4 container.

Perfect! I'm able to run these scripts while root in /etc/init.d, the daemons are running and vidmgr looks great.

But on reboot the daemons are not running. Afraid I'm pretty ignorant about linux .. is there something obvious that needs to be stated for a newbie? I don't fully understand how to get daemons running on boot re /etc/init.d and so on.

BTW as part of lrhorer's setup, I did edit /etc/insserv.conf to add:

Code:

$pyTivo pyTivo

Should that remain in /etc/insserv.conf and is there something analogous for your scripts?

But on reboot the daemons are not running. Afraid I'm pretty ignorant about linux .. is there something obvious that needs to be stated for a newbie?

Click to expand...

To add the init scripts to boot, I do this:

$ sudo update-rc.d pytivo defaults
$ sudo update-rc.d pyhme defaults

Those two commands will add the start/stop links to your init.d scripts under the default runlevels. If you have it installed on your system, you can also use sysv-rc-conf to customize which services start at which runlevels.

I run my programs on my NAS which is debian based and I use the same scripts and procedures as windracer. Without close inspection they appear to be identical - apparently these scripts have made the rounds

Both of these commands give complaints, but pytivo does come up on reboot; pyhme does not. Took a look with sysv-rc-conf and saw only pytivo was activated for runlevels 2-5. I activated pyhme with sysv-rc-conf, but it didn't fix it.

After boot, with pytivo daemon running & pyhme not, I started pyhme manually and vidmgr is happy.

Here's the errors reported by update-rc.d pytivo defaults; in my naive interpretation it's due to not specifying every possible invoke argument in the switch statement which I assumed was okay else you'd have problems.

I'll go ahead and start screwing with the scripts but I'll probably get myself in trouble since I don't know the language. Hoping that there's something obvious to you; figure there must be or you'd have similar problems.

I run my programs on my NAS which is debian based and I use the same scripts and procedures as windracer. Without close inspection they appear to be identical - apparently these scripts have made the rounds

Click to expand...

As if I needed more evidence, this nails it that I must be doing something wrong!

Just FYI, the double quotes in the find statement are not necessary unless there are special characters (like the wildcard character * or a space) in the name being sought. In this case `find . -name config.ini` is just fine. The config.ini file in /usr/bin/kmttg is not relevant to any issues you may have here.

There's a few things I'm not clear on in your scripts (well, more than a few but these seem to be setup related):

1. both refer to mountnfs.sh script re path; I've left the path unaltered

Click to expand...

Well, that is a comment that is in the System V skeleton file, but it is a good idea to leave it there. What it is saying is that (in a default Debian system) /var is not properly available for reading and writing until after the mountfs.sh script is run during boot. Any application writing to /var should not be initialized until after mountfs.sh is run and should be shut down before /var is umounted. If the System V headers are intact and the system is correctly using dependency based booting, this will automatically be addressed properly, but it is a good idea to keep the note handy so one correctly assigns the dependencies. This is salient to the majority of daemons, because daemons usually write either to /var/log/syslog or to their own file in /var/log.

2. both scripts 'Read configuration variable file if it is present'; there is no such dir on my system

Click to expand...

Um, I'm just about absolutely certain there is a /etc/default directory on your system. Debian would have an exceedingly hard time running without it. If you mean no /etc/default/phyHME or /etc/default/pyTivo file, then that's right, there won't be. Again, this is a comment from the skeleton file. (You can take a look at the skeleton at /etc/init.d/skeleton. It is intended as a template for all init files in /etc/init.d.) If no such file as $NAME exists in /etc/default, nothing happens, either good or bad. If it does exist, then it is sourced as part of the init script. Any commands, variables, whatever from the named file are inserted into the script at that point. Since the file does not exist, nothing gets inserted. It's an easy and straightforward way to keep the init files uniform across many installations and invariant from release to release while at the same time allowing for great variability of the init configurations both from installation to installation and in general as time passes.

/var/log/pyTivo.log & /var/log/pyhme.log & /var/log/pyhme.err do not exist. Neither do /var/run/pyHME.pid or /var/run/pyTivo.pid.

Click to expand...

They won't until the scripts run successfully. The .pid files are created near the bottom of each $NAME run file. You can see the next to last line is

Code:

echo $! > $PIDFILE

That writes the PID of the application to the /var/run/pyTivo.pid or /var/run/pyHME.pid file, as the case may be. The system variable "$!" contains the PID of the most recently run command in the script. The variable $PIDFILE is assigned at the top of each script, and is the name of the file where the PID of the daemon is kept.

The .log and .err files are created when the applications write to what would normally be stdout and stderr. These streams are re-directed by the run scripts when nohup is invoked. (Actually, the .err file redirection is disabled in the scripts I posted.)

This insures that the specified services remote_fs, syslog, network, and pyTivo have had their init scripts run at boot time before pyHME is started and that in this case pyHME is stopped before those same four services are stopped whenever a runlevel is entered that shuts down any or all of those services. Typically this would be during shutdown or perhaps when dropping to single user mode. Usually, any dependent daemons are shut down before the services upon which they depend are shut down, but there can be exceptions. An obvious one is where an init script does not start a daemon, but rather initializes some utility that then terminates. In that case, the Required-Stop line would have noting in it beyond the colon. The two lines labeled Default-Start and Default-Stop contain the runlevels where the scripts are started and stopped. Usually, unless the service is a system default, the union of the two lines will contain every number from 0 - 6. There should never be a duplicate between the two. If the service is a system default, then the Default-Start line will have an S in it and the Default-Stop line will be empty. This means the service is started only at boot time, before any runlevel is entered.

In any case, to simplify, registering pyTivo as a service and then specifying it as a Required-Start and Required-Stop makes sure the update-rc.d utility creates the init links so that pyTivo is started before those scripts are run and that they are stopped cleanly before pyTivo is shut down. I'm not sure, strictly speaking, that it would cause a huge problem if vidmgr or jukebox tried to do something with pyTivo not loaded, but the action would most certainly fail. Other HME for Python apps could not care less.

I've rechecked the installation of all 4 scripts and see nothing left out, but clearly something's not right. A clue would be much appreciated!

Click to expand...

As I mentioned above, with both utilities unloaded, what happens if you run the run files directly? If they both work, then unload them again and run the init files, first with `/etc/init.d/<utility> start` and then with `/etc/init.d/<utility> stop`.

Those are not valid System V dependency-based init scripts, I'm afraid. At a bare minimum, every System V init script is required to have the following, with each line modified to fit the script parameters:

Without this header, insserv cannot proplerly assign the link names in the /etc/rcX.d directories. Non-dependency based booting can live without the headers, but non-dep booting can get very manual and can easily wind up with dependency conflicts if one is not very careful.

He is running Debian. After he logs in (assuming he does not log in as root) he can simply issue the `su` command to assume the mantle of root. Sudo is then not necessary. In a secure environment, disabling root logins, especially via ssh, is not really necessary. Preventing a su to root is blankly stupid, if you ask me. It's one of the things I really dislike about Ubuntu. Let the sysadmin decide what security is appropriate. The distro maintainers should keep their paternalistic noses out of it. [/rant]

It may not be absolutely necessary in this case, but since vidmgr and jukebox both depend on pyTivo being loaded, I prefer to make sure pyTivo is running before loading HME for Python and that HME for Python is stopped cleanly before pyTivo is shut down. With dependency-based booting, by far the best way to insure that is to register the service (in this case pyTivo) upon which the dependent apps depend.

in my naive interpretation it's due to not specifying every possible invoke argument in the switch statement which I assumed was okay else you'd have problems.

Click to expand...

No. The errors you encountered are due to the missing LSB tags at the top of the init headers in the init scripts. The Required-Start, Required-Stop, Default-Start and Default-Stop tags are required to be there, even if they are blank beyond the colons. Failure to have the proper tags will likely result in the links being named inappropriately, which in turn may cause the daemons to fail.

Those are all errors due to insserv not knowing what to do with the scripts. This will in turn cause the links to either be wrong or not be created at all. Take a look in /etc/rc2.d (runlevel 2, which is the default boot runlevel for Debian), for example:

The links in each runlevel are asserted in alphabetic order. Insserv has assigned pyTivo the name S04pyTivo, which means it will run prior to pyHME which has been assigned the name S05pyHME. Init will run the scripts with a "start" parameter whenever entering any runlevel from a runlevel where the script is run with a "stop", indicated by the name being KxxpyTivo. In those directories, pyTivo will have a higher number with the K prefix, so it is killed after pyHME.

I'm guessing maybe pyhme isn't activated because of the detected 'errors' in pytivo; this is the last error msg from update-rc.d pyhme defaults:

Code:

insserv: warning: script 'pytivo' missing LSB tags and overrides

Click to expand...

No. Other than assigning the link names in proper order, insserv doesn't really care what pyTivo does. It's possible running HME for Python before pyTivo is loaded will jam it up, but I'm not sure. If not, then simply having an error when running insserv won't stop it from coming up. If the links don't exist at all, though, then of course it won't ever come up. Ditto if there are errors in the scripts themselves.

The first task is going to be making sure the scripts work at all. Then we can worry about insserv.

It probably won't hurt if it isn't there at this point. It definitely will never hurt if it is there, as long as the pyTivo header is correct. The body of the init script itself could be a fracking mess, and insserv would never know it.

I'll go ahead and start screwing with the scripts but I'll probably get myself in trouble since I don't know the language. Hoping that there's something obvious to you; figure there must be or you'd have similar problems.

Click to expand...

I strongly suspect his system is not doing dependency based booting. It may have an older init version, or else he has legacy boot ordering enabled. Insserv will have dependency based booting disabled if there is a file named .legacy-bootordering in the /etc/init.d diretory. Absent that file, insserv will implement a boot order based upon the fields in the init script headers.

It might have been that line in insserv.conf. Anyway, glad it's all working for you!

Click to expand...

No, insserv.conf is only referenced when insserv is run, and that is only when update-rc.d is run. This will, however, happen whenever he upgrades or adds any boot-time system utilities, so I really suggest he gets his boot scripts straightened out. It could save him a lot of grief in the future. Non-dependency based booting is a lot less strict than dependency based booting, but it is also a great deal frailer and a lot harder to maintain.

No, insserv.conf is only referenced when insserv is run, and that is only when update-rc.d is run. This will, however, happen whenever he upgrades or adds any boot-time system utilities, so I really suggest he gets his boot scripts straightened out. It could save him a lot of grief in the future. Non-dependency based booting is a lot less strict than dependency based booting, but it is also a great deal frailer and a lot harder to maintain.

Click to expand...

Thanks for the detailed lessons; I'll go back to your dependency based booting code when I get a chance. I see the advantages and it'd be good to understand. Meantime it's all working, fragile though it may be. Thanks again to you & all!