Notes on using HDHomeRun recorder under Ubuntu for lowest CPU usage when recording from HDHomeRun device

This article has been moved. Please click here to read it.

10 Comments

  1. Fred C. said

    The latest version, at https://github.com/malahal/hdhomerun_recorder, supposedly makes use of all tuners (some HDHR’s have three tuners). If it were turned into a software package, it would probably become very popular, but until then, your instructions provide some of the missing clues that non-programmers need.

  2. Malahal said

    I wrote the recorder script for my own consumption and used it to record kids programs in SD quality. Now almost everything is aired in HD, and my tuner seems to drop some network frames while recording HD channels. This happens with all my computers, so it has to be something wrong with my tuner box. I don’t record anything anymore, but I am willing to help who ever wants to use it.

    Originally I created this project at github. I wanted to make it easy to install by putting it in pypi, but I couldn’t finish it. Since people were trying to install from pypi, I just removed it from there couple days ago. I don’t know enough about python packaging to put it at pypi.

    About the hdhomerun_setup.py, it was originally written to work with hdhomerunfs (my other project!). Maybe, I should make both programs take similar config file and fix hdhomrun_setup.py to work with both.

    Also, if you change schedule file, just send HUP signal to the recorder instead of killing and restarting it (you will lose currently recorded program if you kill it). The details are at the beginning of the log file!

    I wish I have time to make all the changes that I have in my mind for this project, but I can’t!

  3. Malahal said

    You can actually start it like this (“man screen” for help):
    screen -S srecorder -dm ./hdhomerun_recorder.py

  4. Malahal, thank you for the comments. I don’t know what you mean by “send HUP signal to the recorder” – the first line in my log file says:

    2012-12-13 21:50:18,028: Main process PID: 1784, use this for sending SIGHUP for re-reading the schedule-file

    But I have no clue how you’d do that, and as long as I don’t restart it while it’s actually recording a program, I don’t seem to have a problem.

    Also, if that PID changes on every run then I would think it would make it kind of hard to use that in a batch file, even if I knew how. Just as a thought, would it be possible to add a line to the hdhomerun_recorder.py script that creates (or overwrites) a “reread.sh” bash script that would contain the command to send the HUP signal, so that any time you change the schedule you could then run reread.sh and it would send the proper command? That would help those of us who have no idea how to send a HUP signal. Granted you would have to make it executable before the first run but after that, if the file is overwritten the permissions should not change.

    As for the skipping frames on HD, I have found that the tuner sends a proper stream but the computer itself is very susceptible to too many processes running at once. For example, if I forget and leave a VNC window open to my media center PC, the video will be choppy. If I kill VNC then it clears right up. You might want to try doing

    killall vino-server

    from the Linux command prompt to make sure there are no active VNC sessions. Of course if you don’t use VNC, it may be some other process. I’ve also heard some people say that if you have too many switches between the HDHomeRun and the computer doing the recording it can affect quality, although my guess would be that it’s more an issue of the quality of the switches than the quantity. If your switches are only 10/100 I’d try replacing them with gigabit switches. We are running a gigabit network here and don’t seem to have have any problem with HD video quality as long as something else isn’t sucking up CPU cycles on the receiving computer.

    I understand being busy, but if you can find the time I’d sure like to see any improvements you have in mind for your program. The thing I like about it is that it is so “lightweight” and easy to install and configure, once you understand it. While I’d like to see a nice GUI (nothing fancy, just usable) for setting up or changing the recording schedules, the main thing for me is that it works and is not nearly as complicated (and probably not nearly as CPU intensive) as MythTV. It looks like you need a degree in computer science to set that thing up! So thanks for writing this, at least it makes recording possible on my Acer Aspire Revo, which is not exactly a high-powered computer.

  5. From the man page for screen:

    -S sessionname
    When creating a new session, this option can be used to specify a meaningful name for the session. This name identifies the session for “screen -list” and “screen -r” actions. It substitutes the default [tty.host] suffix.

    -d -m Start screen in “detached” mode. This creates a new session but doesn’t attach to it. This is useful for system startup scripts.

    Once you know that the program works, I’m not sure what the advantage would be in starting it that way, since the program doesn’t produce any output while it runs (except to the log file). What am I missing?

  6. Just as an experiment, and because no one else had done it, I created an unofficial HDHomeRun community in Google+ communities. You have to be logged into Google+, then in the left-hand menu click “Communities”, then enter HDHomeRun in the search box. I don’t know if anyone will use it but as I say, it was just an experiment to see if it could be done.

  7. Malahal said

    Sending HUP signal: “kill -SIGHUP “. Technically, “kill” command does not kill a process but sends a given signal. So it is just a matter of reading the first line from “log” file to get PID and then run “kill” command. It is quite possible that we can use pkill or killall, but that may require small changes to signal handling in the python recorder script though.

    screen -S name -dr: Since the recorder is not a daemon, you will have to use “screen” command as you are doing now. “-dr” options detaches the terminal for you automatically (will avoid Control-A followed by D to detach screen session in your instruction!). “-S” option is not needed, it just gives an identifiable name if you are running too many “screen” sessions!

  8. Malahal said

    My hdhomerun dropping frames for HD programming: I tried with 2 different routers, 3 different PCs (one laptop with fedora linux, one with windows7/MC, one WDTV). Swapped cables! I added a Gigabit switch as well. I also tested without any router or switch — I directly connected the hdhomerun to my laptop. Due to absence of DHCP, the tuner gets a static ip and you need to configure your PC to use static ip as well.

    It does record or live OK for most past, but drops frames at times. I also noticed that when ever it drops frames, I can’t detect anything wrong with video, but audio gets chopped!

  9. Malahal, I get it now. The “screen” command is one way to run the script in the background. I am doing something similar in my batch file, by invoking the script with the line

    ./hdhomerun_recorder.py &

    The & character at the end of the line runs the script as a background task. I don’t know which method is lighter on system resources, though.

    Thank you for the information on SIGHUP. It’s little things like that, that Linux users pick up along the way, that aren’t really known by those of us who primarily use a Linux desktop version such as Ubuntu, and only rarely interact with the command prompt.

    I’m wondering how you ever got the HDHomeRun configured to use a static IP address (or does it just pick one and force you to use a compatible one on the PC?). I’ve looked for the option to use a static IP on my HDHomeRun Dual and have yet to find it. In any case, I have seen the exact opposite of the problem you describe. In my case, the video gets choppy but the audio is fine. Usually when that happens. I am pretty sure some background process is running, I just don’t know what. Last night i recorded something that lasted two hours and the first hour was completely fine, while the second had video glitches. Since it was actually two separate programs back to back, it’s entire possible that the problem was with the source — since I didn’t see it while it was live, I just don’t know for sure.

    In any case it sounds like you have done everything you can to eliminate the possibility of a network issue. Thanks again for your comments!

  10. Malahal, one more question. In your main program there is a line (well, two lines actually) that looks like this:

    logging.info(“Main process PID: %d, use this for sending SIGHUP ”
    “for re-reading the schedule-file”, os.getpid())

    This is obviously what is placing the PID in the log. What I’d like to have it do at the same time is open a file called reread.sh and in it write these two lines:

    #!/bin/bash
    kill -SIGHUP %d

    Where %d will be replaced by the PID, as in the lines mentioned above. Then the file should be closed. Do you know offhand how to code that in Python? Seems like it shouldn’t take more than four or five lines tops, but it would probably take me hours to figure it out given my lack of familiarity with Python (in contrast, back in the day I could have done something like this in BASIC in no more than a minute. I miss BASIC!).

    EDIT: As a stopgap I figured out that this would work in reread.sh as long as the logfile format doesn’t change:

    #!/bin/bash
    pid=$(grep PID logfile | cut -d " " -f 6 | cut -d "," -f 1); kill -HUP "$pid"

    The idea is that in Midnight Commander, after making a change to schedule-file, all I’d need to do is double-click on reread.sh and that would take care of rereading the schedule, hopefully without interrupting any recordings in progress.

RSS feed for comments on this post

Comments are closed.

Follow

Get every new post delivered to your Inbox.

Join 136 other followers

%d bloggers like this: