Getting the reciever started, and rebooting


#1

Is it required to go into the Tvheadend interface and hit play after reboot, or should it just reconnect?

I have had to hit “Play” on a few different screens in random order before it ever seemed to start working; and I haven’t been able to figure out quite what the correct procedure is,

What does “Continuity error: X => Y” mean?

Any luck on opening the source code?

Thanks!


#2

What usually works for me is clicking the Play in either the Services tab or Channels tab if you mapped the service. What I’m not 100% sure is whether this needs to be done after rebooting. I believe it doesn’t need to be done across reboots. I have just power-cycled my Pi, and when it got back up, it was tuned into the correct transponder.

I’m not the sat expert, so I’m not sure what continuity error is, but our sat guy says “Don’t worry about them, that’s normal.” I think it happens when packets arrive in unexpected order or something like that.

I think it’ll be a couple of months before we can properly address this.


#3

So the ONDD does require the channel to be pre-tuned then? Yes, I seem to have noticed that it will at least sometimes reboot tuned, but I think if turned off it required intervention.

I’m anxious to see the code because I want to see if there’s some way for me to set this up so that it runs more reliably without intervention after power outages and such.

Can you give just a short description of how the ONDD actually gets the datastream from the device? It doesn’t seem to actually connect to tvheadend.

I’m getting a lot of those continuity errors, possibly because of weak signal? I seem to get less complete files when I see more of them anyway. I haven’t had a file complete for a few days now, and previously I was seeing about one article every 20 minutes or so.

Thanks for the prompt reply!


#4

I can’t tell you the nitty-gritty of how it works, but it does not require TV Headend. In fact, it can tune in on its own if passed correct command line arguments, but it doesn’t have built-in documentation so it’s a bit difficult to remember. Here’s what I’ve been told by the engineer that works on it:

ondd can tune direct, without the need for tvheadend. I
haven’t verified, but I have my doubts that tvheadend maintains a constant
tune.

The args are:
-f frequency to tune to in Mhz
-s symbol rate in ksym
-p Vertical or Horiontal
-t enable 22Khz tone

So for Galaxy 19 here which id 12.177Ghz Vertical, with a
universal LNB is:

ondd -f $((12177-10600)) -s 23000 -p V -t

So as you can see, the main advantage is that TVHeadnend does its share of work to stay tuned (or so it appears, anyway). Either way, as long as the tuner is tuned in, ondd can use the LinuxTV API to get the data. I believe this applies generally to any LinuxTV API client, but I’m not an expert in that domain.

Another interesting thing you may want to take a look at is the database ONDD uses to track downloads, which is located at /var/lib/ondd/ondd.db. It’s an SQLite database.


#5

Awesome.
I will test this. Eliminating the need for TVHeadend would be wonderful.

Thanks :smile:


#6

That’s one of the future goals for the archive manager, along with a mechanism to keep the tuner tuned in.


#7

Ok, after seeing some weird things (like I’m sure it wasn’t tuned in, then I see 4 new files the next morning, etc), I have a theory about TVHeadend and how it ‘maintains’ the tune.

I had idle scanning turned on in TV adapter settings. I think this gave me the illusion that TVHeadend actively tunes in when the tune is lost. If I disable this option, it immediately tunes out and never tunes back in unless I ask for a channel’s video stream.

While idle scanning is pretty effective, I’m not 100% sure it is tuned in all the time, so I think it’s worth keeping the channel on as often as possible.