Tvheadend

Prof Yaffle wrote:

Build it from source using git checkout <hash> - that allows you to move to a specific version before you compile. Clone it as per the instructions, then checkout that specific version immediately before running configure or Autobuild.sh.

Thank you very much for your help. Compiled version v3.9.2178 and was able to scan and watch 4.8E, 13.0E and 28.2E using usals. Tomorrow will try the repository version again and use the same configuration.

Some of the rotors, like the SG2100 ( https://www.satcruiser.com/PubFiles/SG_2100.pdf ) have a built-in table of satellite positions (page 7). Would that be possible to align to this? Note that Samsung Smart TVs that are equipped with sat tuners do support this, and allow you to select the satellites from a menu in an easy way.
I tried the setup depicted above, and the rotor is supposed to have 2,5°/s speed at 18V, so even the rate should be similar, but it turns to an unknown position instead.

Is there a way to measure the voltage applied to the rotor? I'm not convinced it has 18V btw. Haven't seen any such circuitry on the Cine S2 card that would transform 12V to 18V. Of course I may be wrong...

Sorry Guys but Long time no Post, I'm in my 3rd year of uni and have very little time

o o wrote:

Another thing that would be nice to know is if Garys system is working well with the latest build.

Sorry I never got back to you (see above) but my rotor is not working with the latest master. it did stop working in the last 2-3 months so something was changed along the way breaking my system. (this could be either the software or even my rotor as I've had one rotor stop working all together on me during the summer and needed replacement.) there is also the wind factor for me as I think my dish has been blown out of alignment as well. guess i'm going to need to loan a set top box to check if its my rotor before I confirm anything really. I'll post once I know though.

Levente Cseh wrote:

I tried the setup depicted above, and the rotor is supposed to have 2,5°/s speed at 18V, so even the rate should be similar, but it turns to an unknown position instead.

it sounds like your site lat/long is incorrect Are you using the values in the pictures or your own?

Is there a way to measure the voltage applied to the rotor? I'm not convinced it has 18V btw. Haven't seen any such circuitry on the Cine S2 card that would transform 12V to 18V. Of course I may be wrong...

All dvb-s devices have the 12-18v built in as this is the way the LNB is switched between polarisations.

I'm Just going to point out that the code Is probably broken and i cannot findout until later this week when I go up to my parents house and check the setup.

I'm using my own coordinates of course.
Will wait for your fix, and I'll give a try next week. Do you plan to include it in a forthcoming release?

Hello again,
I seem to be having the same problem as Richard- USALS is working for me in 2178, but not in 2218.
The dish moves to the wrong position in 2218. I have rechecked my dish alignment and 0 position is still correct at 0.
I've also tested with a satellite meter which has USALS built in, and the rotor will move to the correct position.

Both latitude and longitude are correct, and I've left 'zero sat position' at 0. But, I can make the rotor move to the correct
position if I enter -12 in the 'zero sat position' which is roughly half of my longitude.

Any ideas?

Thanks,
Phil.

Can't find any logic till now. Installed the repository version again and same problems. Then compile the latest version, no success.
Back to 2178 version and stopped working properly. So sometimes it works, stops, throw away configuration and if lucky it works again for a while.
Build version 1499 en 1526 moves my rotor to the right position but then I have error "comet failure [e=Cannot read property 'getById' of null]" (which I haven't seen before). Never the less transponder is being scanned succesfully. Though BBC HD at Astra 28.2 takes quite a while.
Next problem is that in Xbmc client (and also Vlc) I can watch television at my fixed dish and at rotor the Hotbird but other transponders and sat from rotor are giving me issues like "comet failure [e=Cannot read property 'getById' of null]
2014-12-12 10:06:56.000 subscription: No transponder available for subscription "192.168.1.46 [ xbmc | XBMC Media Center ]" to channel "BBC One HD" ".

When I connect my set top box it works well and very good signal. Same with fixed compiled version of mythtv.

Anyone a proposal which build to try? :-)

Read one of Philip's previous post after his remark. So used version 3.9.1567 and everything was working much better. No errors anymore like "comet failure".
Also know now why I got "No transponder available for subscription". When switching to another satellite the rotor doesn't move because it keeps busy with epg scan. Disabling EIT epg scan for all muxes prevents this and don't get errors "No transponder available for subscription". So to use mux scheduler? Suppose epg scan should unsubscribe automatically when changing satellite/transponder?!
Then only problem which remains (at least in my setup) is that while switching channels/satellite with rotor it moves to the correct position but status remains "testing". After I do an active scan at same mux then it works again. This happens frequently.
Is the above known?
Greetings, Richard

I think that the best way to solve this in latest tvh is to create a new issue - https://tvheadend.org/projects/tvheadend/issues . Add a "good log" and "bad log" there with identical starting position and identical streaming to compare timings and diseqc commands. I need log for "--trace linuxdvb,diseqc" .

Jaroslav Kysela wrote:

I think that the best way to solve this in latest tvh is to create a new issue - https://tvheadend.org/projects/tvheadend/issues . Add a "good log" and "bad log" there with identical starting position and identical streaming to compare timings and diseqc commands. I need log for "--trace linuxdvb,diseqc" .

Thank you very much for your help. Reported it as bug #2548 and hopefully printed the log files well. To me as non-expert it seems like diseqc rotor usals goto changed.

Me again,
should 'zero sat longitude' really be part of USALS setup? I thought that the main point of USALS was to align you dish and rotor to true south, and the rotor/software would take care of the rest once you enter your correct long/lat?
I mean, I've aligned my dish to the nearest true south satellite in Finland, but that isn't 0 on the rotor. Or am I talking scooby doo again?

Regards,
Phil.

For USALS, I changed the formula in the recent code to follow Enigma2 code. It's in v3.9-2234-gad16b3d . Report errors in https://tvheadend.org/issues/2548 .

Thanks Mr.J,
you are formula 1 guy.

Will checkout.

Br,
Phil.

I've just updated to latest and it seems to be running better for me. My dish has been knocked off by the wind though so cannot get a lock and will need to get that sorted at some point.

Gary Brown wrote:

I've just updated to latest and it seems to be running better for me. My dish has been knocked off by the wind though so cannot get a lock and will need to get that sorted at some point.

Unfortunately, I forgot to remove some "debug" code which gave wrong results. The fixed version is v3.9-2237-g388f57e .

Jaroslav Kysela wrote:

Unfortunately, I forgot to remove some "debug" code which gave wrong results. The fixed version is v3.9-2237-g388f57e .

It seems to be fixed for me [[https://tvheadend.org/issues/2548#note-12]]
Great and compliments!
Curious how it will work for Philip, Gary and all others.

had another go with tvheadend today, updated to latest git this afternoon

I inserted the following code at line 364 of linuxdvb_rotor.c (I set site longitude=0 and latttide=0 in USAL options)
This turns my dish perfect. however what I have noticed is the first time I start tvheadend, and click on a service it will not tune in, i have to stop and start it again for it to work. At some point i will dig out my dreambox 800 , put a new image on it and try usals on that.

int integer = (int) lr->lr_sat_lon;
uint8_t angle_1=0;
uint8_t angle_2=0;
int fraction = (int) (((lr->lr_sat_lon - integer) * 16.0) + 0.9) & 0x0f;

if ((lr->lr_site_lon==0) && (lr->lr_site_lat==0)) {
//if (fraction==15) fraction--;
switch(fraction) {
case 1:
case 4:
case 7:
case 9:
case 12:
case 15:
fraction--;
break;
}
if (lr->lr_sat_lon < 0.0) angle_1 = 0xD0; // West is a negative angle value
else angle_1 = 0xE0; // East is a positive angle value

integer = abs(integer);
angle_1 |= ((integer / 16) & 0x0f);
integer = integer % 16;
angle_2 |= ((integer & 0x0f) << 4) | fraction;
printf ("Sending Direct DISEQC 0x6E Command with angles %01x %01x\n",angle_1,angle_2);
for (i = 0; i <= ls->lse_parent->ls_diseqc_repeats; i++) {
if (linuxdvb_diseqc_send(fd, 0xE0, 0x31, 0x6E, 2,
angle_1, angle_2)) {
tvherror("diseqc", "failed to send USALS command");
return -1;
}
usleep(25000);
}
}
else

Trevor Tate wrote:

had another go with tvheadend today, updated to latest git this afternoon

I inserted the following code at line 364 of linuxdvb_rotor.c

What does not work for you with enigma2 USALS code in latest tvh ? Do you have tried it ?

Just playing with the new commits from today as well. Have a V-Box on order, but not here as yet so can't verify what is actually working, just watching trace and seeing what commands are sent. Noticed some things.

Just set up a couple sats with GOTOX. Entered all the Position, Longitude, Rate correctly as far as I can tell. Here is how it's working.

One sat 101W another 107.3W actually port 1 and port 2 on a diseqc switch.

Channel tuned on 107.3W. Select another on same sat. Says already positioned on 107.3W doesn't send gotox just tunes. Perfect.

Select channel on 101W. Sends gotox. Seems to calculate a time, tunes. Perfect.

Select another channel on 101W. Doesn't say already positioned. Sends gotox. Waits Max rotor movement time then tunes. So Max time to change channels on that same sat.

Select channel back on 107.3W. Sends gotox, but doesn't seem to calculate. Waits Max time then tunes.

So getting better. It would really help to not have to wait for max rotor time when changing channels on the same sat. Not sure why it works on one sat and not another. Seems weird that the message says positioned @ 107.3W as it always gives that even if I change Longitude in config. Are you relying on NIT data to figure out what satellite you are positioned on? NIT data will often be incorrect or missing. Relying on Longitude entered into config by the user would be the only way to really keep track. You are going to have a separate satconfig and separate network for each position, so one should be able to safely assume channels in the same network don't need gotox sent again. Just tune. Channels in the same MUX don't even need to tune, just swap PIDs.

Jaroslav Kysela wrote:

What does not work for you ......

• http: /comet/poll?boxid=35401848648b012eb340c6caa14fa03573fb7c21&immediate=0{{Host=192.168.1.50:9981,Connection=keep-alive,Content-Length=58,Origin=http://192.168.1.50:9981,X-Requested-With=XMLHttpRequest,User-Agent=Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Ubuntu Chromium/37.0.2062.120 Chrome/37.0.2062.120 Safari/537.36,Content-Type=application/x-www-form-urlencoded,Accept=*/*,Referer=http://192.168.1.50:9981/extjs.html?,Accept-Encoding=gzip,deflate,Accept-Language=nl-NL,nl;q=0.8,en-US;q=0.6,en;q=0.4,de;q=0.2,Cookie=ys-api/mpegts/service=(removed the rest -> see log)
• access: 192.168.1.46:<no-user> [SATWRE*], conn=0, chmin=0, chmax=0, profile=ANY, dvr=ANY, tag=ANY

Instead of restarting tvheadend can do a mux scan at this frequency and then it works.....for a while....and have to do the same at other frequencies.
Di I miss something or should report it as a bug

Version v3.9-2250-gd9bb16e should rely only on the position values from the rotor configs. Previously the NIT tables were used to get the orbital position for a network.

OK testing 2250. It's calculating wait time both ways now. However it's now sending GOTOX everytime no matter if the channel is on the same sat or not.

Ron L wrote:

OK testing 2250. It's calculating wait time both ways now. However it's now sending GOTOX everytime no matter if the channel is on the same sat or not.

It should be fixed in v3.9-2252-g1145484 .

Still sending gotox everytime. I'm testing it over HTTP at the moment if that makes a difference.

Ron L wrote:

Still sending gotox everytime. I'm testing it over HTTP at the moment if that makes a difference.

I found another minor bug in the position cache code - v3.9-2253-g70c65a3 it out.

Yes, that was it. Only sends gotox when switching to a channel on a different sat now. The grace period seems to be calculating very realistic wait times now too. I think you have a winner