First, look at this:
Program ("do_record"):
#!/bin/sh
tty
[ $# = 2 ] || exec echo "Arg count! Must be 2!"
set -e
cd /mnt/tmpfs
/full/path/to/gawk '
ARGIND > 1 { exit }
/device0/,/^$/ {
sub(/device0/,"TEMP")
if (/RecPath/) sub(/=.*/,"=" ARGV[3])
if (/Timelimit/) sub(/=.*/,"=" ARGV[4])
print
}' mount_NAND/data/sysconfig.ini /etc/group "$@" > .vrecsettings
egrep 'RecP|Time' .vrecsettings
export LD_LIBRARY_PATH=/media/ext/.osd-extended/programs/lib
exec /usr/local/bin/vrecorder temp
Now read this:
For reasons that will be explained shortly, I have decided to re-invent
the OSD's scheduler mechanism. There are two main parts to this effort:
1) Figuring out how to run "vrecorder" manually (I.e., from the command
line, without the GUI).
2) Developing a better way to change the channels on the cable box. In
fact, this was the primary motivation for this project, since the
Neuros-supplied "IR Blaster" stopped working for me about a year ago (due, I
think, to a combination of limitations in the Neuros/OSD implementation,
triggered by changes made by the cable company).
For 1), I wrote the above-listed shell script. The main trick was figuring
out how vrecorder works - namely, that you modify the .vrecsettings file,
then run vrecorder with a parameter of "temp". I assume that the original
design was that you could have multiple keys in the file and use whichever
one you wanted, but it looks like that functionality was never used (And I
have yet to test it). Incidentally, I figured out the file name
(.vrecsettings) by running "strings" on the vrecorder binary.
This script is designed to be run via ssh - hence the need to full-path some
things, and set LD_LIBRARY_PATH. The "tty" command displays "not a tty";
this was put in as a check to see what sort of environment you get when you
run via a non-interactive ssh. I use "plink" (part of the "putty" package)
on the Windows side to run the script. Note also that this may not be the
most elegant AWK script ever written, but it gets the job done. It could
probably be made non-GAWK-specific without too much work.
Finally, there is a whole other side to this - on the Windows side -
including doing the scheduling using "WinCron" - the scripting for this is
not shown here. However, here is the Windows "plink" command line which
runs the shell script on the OSD:
plink root@%host% exec /path/to/do_record %ofile% %seconds%
For 2), I found a neat little device at
http://usbuirt.com that replaces the
OSD's IR Blaster. The USBUIRT device costs about $50, and is much more
powerful (in every sense of the word) than the puny OSD IR Blaster. It is
Windows based - plugs into the Windows PC's USB port - and works very well.
You use a tool called "lrnhelper.exe" to learn the codes from your remote.
This process, once you figure it out, is much more comfortable than the OSD's
learning process. Then, you use the "uutx.exe" tool, from your scheduled
script, to send the codes to the cable box to change the channel.
One caveat about the USBUIRT device: It is poorly documented - in fact, the
shipped device contains no documentation at all. Everything (and there
isn't much) is on the web site. Further, even though I had a pretty good
idea of what I wanted to do and what it (the device) was, I would never have
figured it out without having exchanged about a half-dozen pretty detailed
and involved emails with the device's maker. But, note well, he was very
helpful and very timely in responding to my emails - generally responding
within a few hours time.
But, having said that, I also want to add that the USBUIRT device is a
*very* powerful device and does a lot more stuff than what I am currently
using it for (channel changing). Someday, I'll actually take the time to
figure out all the other uses to which it could be put.
Anyway, the whole system works quite well and I can once again record
anything on any channel, using a Windows-based scheduling system. It was
quite a bit of fun putting it all together. And, I can't begin to tell you
how much quicker and easier it is to manage my scheduled recordings using a
normal file editor, on the Windows platform, as compared to using the (slow)
clicky GUI on the OSD.
Note also that if you don't use the OSD's scheduler anymore (as is the case
for me), then you don't really care if the OSD's clock is kept accurate. I
mention this because a lot of effort has been expended over the years
working on schemes to fix the clock, and a lot has been written in these
forums about those efforts. So, this is now one less thing to worry about.
P.S. For completeness, here's a little bit about the other side of the OSD
- how to play files via command line, as opposed to by clicking the GUI. I
use the following bit of code in a (DOS/Windows) batch file:
plink root@%host% ^
export LD_LIBRARY_PATH=/media/ext/.osd-extended/programs/lib;^
/full/path/to/OSDstop;sleep 5;^
exec /usr/local/bin/vplayer --path ^
'/media/network/path/to/Video to Play.mp4'
Note that this is 5 lines in the batch file; note the use of the ^ line
continuation character. And here is the "OSDstop" script, which is needed
(as is the 'sleep 5'), in order to ensure that the OSD "screen" is visible
on the TV when the video plays:
#!/bin/sh
echo -ne "\x40" > /dev/neuros_ir
echo -ne "\x22" > /dev/neuros_ir
echo -ne "\x00" > /dev/neuros_ir
Show Posts