Replies: 40 comments 43 replies
-
|
Hi @ddarek Could you give the contents of: |
Beta Was this translation helpful? Give feedback.
-
|
Hi, In this config I tried to use 1st four tuners. |
Beta Was this translation helpful? Give feedback.
-
|
I took a quick look into the XML file but I think you missed to enter the Channel Slot (UB) see: So 1420 would probably be Channel Slot UB: 1 (SatPI starts with UB 0) Hope this will resolve the problems |
Beta Was this translation helpful? Give feedback.
-
|
I have already verified it. The same result. |
Beta Was this translation helpful? Give feedback.
-
|
Ok, but in the SatPI.xml are all channel slots set to 0. If you try in frontend 0 -> Ch freq 1420 and UB 1 does that work on its own? |
Beta Was this translation helpful? Give feedback.
-
|
It works |
Beta Was this translation helpful? Give feedback.
-
|
Hi @ddarek Thanks and nice to hear your feedback. Well the UB starts in SatPI with 0 (zero) as the first SCR. This is as it is send via DiSEqc. Usually the documentation of the LNB start at 1 (one) for the first SCR. So this can be confusing. |
Beta Was this translation helpful? Give feedback.
-
|
I understand but it's not a case. I previously were using from 0. When I enable f1,f2,f3 with settings: All except F0 has fbclinked=true and send diseqc via root = true I start only one stream -> works ok on F0. It looks like single stream works, but in case of more than 1 it stops working Here's my current satpi.xml and logs. |
Beta Was this translation helpful? Give feedback.
-
|
Which LNB are you using? |
Beta Was this translation helpful? Give feedback.
-
|
I have 2 physical dvbs2 fbc tuners. |
Beta Was this translation helpful? Give feedback.
-
|
Sorry, I mean which type of Unicable LNB |
Beta Was this translation helpful? Give feedback.
-
|
EN 50494 |
Beta Was this translation helpful? Give feedback.
-
|
But every SCR is working separate on Frontend 0? |
Beta Was this translation helpful? Give feedback.
-
|
I don't understand. |
Beta Was this translation helpful? Give feedback.
-
|
What I mean is that if you configure, one by one for Frontend 0 like: |
Beta Was this translation helpful? Give feedback.
-
|
Yes, as I wrote before : |
Beta Was this translation helpful? Give feedback.
-
|
Hi @ddarek Could you please, give this version a try: |
Beta Was this translation helpful? Give feedback.
-
|
Hi, Yesterday I found also that scanning muxes don't work in tvheadend. I get "scan no data, failed". |
Beta Was this translation helpful? Give feedback.
-
|
I have found that (my) Vu+ receiver starts sending PID data sometimes very late, at least when get these pids: You could check this. It locks to the signal but data takes some time to receive. |
Beta Was this translation helpful? Give feedback.
-
|
Yes, it works but after some while |
Beta Was this translation helpful? Give feedback.
-
|
You're right. I have changed the timeout to 200ms and now scan was successfull |
Beta Was this translation helpful? Give feedback.
-
|
Ok, so it locks to the channel and data is received much later in wget? |
Beta Was this translation helpful? Give feedback.
-
|
Here is a log after starting this wget command: |
Beta Was this translation helpful? Give feedback.
-
|
Ok, increasing the timeout int TvHeadend fixes this? |
Beta Was this translation helpful? Give feedback.
-
|
Yes, on one mux I have increased value to 200 seconds and mux was scanned ok |
Beta Was this translation helpful? Give feedback.
-
|
This big delay has to do something with those pids. |
Beta Was this translation helpful? Give feedback.
-
|
Yes, the data rate is not big for those pids (0,1,16,17,18) only. I am still not sure were the problem exists it seems that the Vu+ is caching an amount of data in the driver, before sending it out |
Beta Was this translation helpful? Give feedback.
-
|
In oscam I have : |
Beta Was this translation helpful? Give feedback.
-
|
See for info on these pids: |
Beta Was this translation helpful? Give feedback.
-
|
Now a lot of services don't work. Scan is also not possible. It was successful once after increaing timeout but now it don't work. |
Beta Was this translation helpful? Give feedback.
-
|
It this compiled with LIBDVBCSA |
Beta Was this translation helpful? Give feedback.
-
|
It's a compilation you attached in this discussion thread |
Beta Was this translation helpful? Give feedback.
-
|
Ok, I am not 100% sure anymore I used LIBDVBCSA. Do you use OSCam? But the services that do not work, do they work in VLC or with wget? Add the correct pids for the service: For VLC use something like this in 'open network stream': |
Beta Was this translation helpful? Give feedback.
-
|
Is it something like this TvHeadend issue? |
Beta Was this translation helpful? Give feedback.
-
|
I don't think it's this issue. MaxPids didn't change anything. |
Beta Was this translation helpful? Give feedback.
-
|
Which version of TvHeadend do you use? |
Beta Was this translation helpful? Give feedback.
-
|
Hi @ddarek I have done some testing and have increased the timeout to 15 sec. (See png below) This is tested with
|
Beta Was this translation helpful? Give feedback.
-
|
Hi, I will check it this weekend :) I was using tvheadend version from feeds on openatv image. |
Beta Was this translation helpful? Give feedback.
-
|
Yes, I build it myself from git on x64. But the problem is that TvHeadend is tearing down the freq. scan before the PMT pids are read from SatPI. And SatPI reads them from the Vu+ driver which takes quite some time. I have made a test program that shows that the initial scan pids (0,1,16,17,18) can take up to 7 sec to get in the buffers for reading. I am still not sure were this delay is coming from. But my test program is quite simple and straightforward with less buffering etc. and that shows the same problem. By the way my Gigablue receiver, connected to the same setup, is taking about 3 to 4 sec. |
Beta Was this translation helpful? Give feedback.
-
|
Hi, |
Beta Was this translation helpful? Give feedback.
-
|
I have scanned all muxes I'm using with already mapped services. Couple ok, but the rest are failing. |
Beta Was this translation helpful? Give feedback.
-
|
Hi, |
Beta Was this translation helpful? Give feedback.
-
|
Some later muxes scans were successful. And screenshot with result: |
Beta Was this translation helpful? Give feedback.
-
|
Interesting is number of services. |
Beta Was this translation helpful? Give feedback.
-
|
You can increase both the timeout to 20 sec. I had the experiance that it worked better |
Beta Was this translation helpful? Give feedback.
-
|
For some reason it takes a long time to receive the PMT table data. |
Beta Was this translation helpful? Give feedback.
-
|
Yes, I noticed it too |
Beta Was this translation helpful? Give feedback.
-
|
Here after 2 sec it still did not receive the PMT... Strange.. |
Beta Was this translation helpful? Give feedback.
-
|
Did you try to decrease the PID request in Tvheadend to around 15? |
Beta Was this translation helpful? Give feedback.
-
|
I did scan with longer timeouts (20sec). |
Beta Was this translation helpful? Give feedback.
-
|
I aswell, have found it still difficult to scan reliable with Vu+ and DVB-S2. I do not know were this delay comes from or prevent it. |
Beta Was this translation helpful? Give feedback.
-
|
Yes
|
Beta Was this translation helpful? Give feedback.
-
|
With maximum pids=16 looks the same. |
Beta Was this translation helpful? Give feedback.
-
|
Mmmm... strange.. I if you set timeouts to very extreem, lets say 35 sec |
Beta Was this translation helpful? Give feedback.
-
|
With those settings it works the best: The result: I think Grace period did a lot. |
Beta Was this translation helpful? Give feedback.
-
|
Many thanks for you support and testing |
Beta Was this translation helpful? Give feedback.
-
|
Yes the scanning procedure is a bottle neck. I try to insert some delay's in SatPI for setting PIDs etc. to see if it improves the behaviour. Did you test without the option |
Beta Was this translation helpful? Give feedback.
-
|
Not today. I found also that manual setting pilot =off on some muxes helped. |
Beta Was this translation helpful? Give feedback.
-
|
I think that all those problems are caused by drivers bugs. |
Beta Was this translation helpful? Give feedback.
-
|
It has FBC tuners which is a nice feature. But indeed it seems a driver problem in Vu+ drivers. But something makes me think it should perform beter. |
Beta Was this translation helpful? Give feedback.
-
|
And maybe some setup or proc or sys file should/can be set to improve |
Beta Was this translation helpful? Give feedback.
-
|
You should not set 'Send full PLAY cmd' it is not necessary and does not improve the reliability |
Beta Was this translation helpful? Give feedback.
-
Hi,
I have a Unicable converter (1210/1420/1680/2040) connected to my DVB-S2 FBC tuner (connection a).
I have frontends 0-7.
0 and 1 are roots.
I set:
Frontend 0 : FBC Connection A, unicable, channel freq 1210
Frontend 2 : FBC Connection A, unicable, channel freq 1420, fbc linked
Frontend 3 : FBC Connection A, unicable, channel freq 1680, fbc linked
Frontend 4 : FBC Connection A, unicable, channel freq 2040, fbc linked
Is this config correct for unicable connected to A ??
With this configuration only 1 stream works on F0.
What am I doing wrong?
Beta Was this translation helpful? Give feedback.
All reactions