Tuning problems on my VU+ Duo2 4k with 1xDVB-S FBC and 1x-DVB-C FBC (16 tuner) #187
Comments
|
Are the tuners correctly identified in the 'frontend overview' tab in the webui |
|
i am not sure. What I know in any case is that the tuner configuration in the TVHeadend had to be set manually. What SATPI had exported as SAT>IP was not correct. Does that help you? I have attached three screens
|
|
What was not correctly exported? |
All good. I think that some new version of Satpi has settled. But I have attached a debug log here. Here I have started a scan via TVheadend. |
|
You could try to compile a regular build of SatPI (so no debug version) |
|
I can do that, but what's the point? |
|
Ok, what does cmd |
|
I thought that's what you were getting at. The cpu gets bored. when all 16 tuners are active, i have about 15-20% cpu utilization at peak. |
|
Ok, and memory usage? |
looks good. |
|
You could maybe try to disable in TvHeadend the |
same behavior :( the behavior here doesn't seem right to me either, does it? |
|
That is because SatPI is reading the fe status to fast, and for some reason the driver is giving this "error" I am more concerned about the reply time of 3990 ms |
what does that mean? |
|
That means TvHeadend is probably timing out before the reply is send. |
grace period was not set. set it and same behavior... the rest is set correctly |
|
I have now checked all the timeouts again and reset everything. The mux+epg scan doesn't seem to run into the timeout anymore. something is wrong here |
|
Well there is a lot going on in the log you send (scanning on multiple frontends). Lines 214 to 228 in 9b31903 |
|
I discovered something else interesting. but continues errors I have constantly on all frontend.... -.-
yes, but you want to have a logfile? |
|
Well it is also a remainder to myself. |
|
I have to check this here is @nikolauzi11 having probably the same problem in (#181) |
yes, that smells kind of similar. |
|
How do you start SatPI? could you give the full command line if so? |
|
LD_PRELOAD=/home/root/libdvbcsa.so /usr/bin/satpi --http-path /usr/share/satpi/web |
|
have you enabled logging to syslog in SatPI? |
|
yes, I disabled it and still the same behavior. |
|
Thanks for testing! You could checkout that commit yourself in the master branch with: Now the correct commit before |
|
I did the above, and that version seems better. I have had some issues the last month as well. I have to check this, as it should have had no side affects. |
|
much better. i was able to complete a scan without a single continues error. now i only have 0-10 continues errors when switching channels. |
Of course, it's in the appendix. |
|
Thanks @SaulGoodman1337 for you effort so far. Could you please also include commit 06b70b4 (the latest) this will not log MPEGTS Tables |
|
Could you limit the scan for only 4 DVB-S2 and 4 DVB-C to see if that make any difference? |
|
rather worse. furthermore, SatPI seems to die spontaneously during scanning. This was already noticed during the 11 o'clock scan.
|
|
with your latest commit :D :D |
|
Could you please check last commit? This should revert most of commit 9870875 for DVB frontends. |
|
Did you reboot the receiver at some time? |
|
Much better ! However, SatPI dies multiples times. now at the scan 4 times. but as you can see still not perfect. i'm getting desperate :( |
Me too |
|
|
i think that is of interest. i'll try to lift that up
|
|
ahaaaaa...size 28315648 byte seemed so familiar. i had specified a DVR buffer (MB) of 27MB. Now I ask myself the question, whether you have influence on the kernel buffer? 16*27MB is a lot. I have now set the DVR buffer to 3MB, started a scan and look... not a single continunity error. I think this only applies to the new build from today. The DVR buffer is set to 27MB only since yesterday evening. actually, however, I am even more confused than before :D |
|
so i have now tried your latest build and the whole thing works. thanks ! |
|
Sorry, i do not really understand what you mean here. Could you elaborate a bit more on parallelization in this contect? |
Splitting the tasks into threads like minisatip does. If I see it correctly, satpi processes one task after the other while minisatip, for example, is able to do things at the same time. In the TVHeadend this is quite nice to see when you start a scan. It is very slowly activated one tuner after the other. Some tasks could be processed in parallel. The problem is simply that when satpi is busy with other things, the tuning simply takes too long. do you understand? You should really take a look at my setup here and try something. You will quickly notice that satpi has reached its limits here. |
|
i'm really close to just throwing all this receiver shit out the window and not wasting my time with it anymore. As soon as there is somehow a tuner active, just nothing works properly. Sometimes I need 20 seconds until a channel was opened, sometimes it goes without problems. please do not feel attacked but it just pisses me off. I've tried so many receivers and with each device I've always had some kind of fucking problems. I could pull out my hair and scream at the same time. |
|
Well SatPI does use an thread for every frontend that is opened. I could not think of a reason why it should wait. |
|
Then I'm honestly at my wits' end. No idea what I should still do here. I guess it's not meant to be. |
|
You should maybe not use all frontends for tuning. Just to start with only 4 DVB-S2 and 4 DVB-C. Then set in TvHeadend |
|
Yeah but be honest, that sucks. If you have an interest in your software working with these devices, I can offer you vpn or I'll have them mail it to you. Otherwise I will put the project on hold. I sunk too much time into this topic and now as a family man time is precious. The two suggestions I can still make. |
|
Yes thanks, you can mail them to me, and I have a look. This is a spare time project for me as well. Don't make a lot of money of this (it only costs money to buy stuff actually) But why would you need all frontends to tune at once? Tuning needs a lot of PIDs to be opened which maybe to much for the receiver. |
|
This is actually not necessary, but even with only one tuner activated at a time, it does not work reliably. And I think I'm not alone with this. Yes I can totally understand with the time. I am of course also willing to make a donation |
|
I have here an Gigablue DVB-S2X and Vu+ DVB-S2 and DVB-C versions that work reliable with TvHeadend. The only problem are the drivers of Vu+ that are not working as I expect. With low bit rate PID (like scanning) it takes a long time to receive data from the frontends. |
|
I think we are talking at cross purposes. Satpi and minisatip also cause problems when I activate only 1 or 2 tuners. It seems to me that you have to do something different with these boxes than you do so far. Probably... I'll leave the assessment up to you. |
|
Yes send me an mail, we first discus there further on a solution. |
Have a wonderful good day Marc,
I have once again changed the receiver because I need DVB-C and I have chosen the Duo 2 4k.
Here I have 1xDVB-S FBC and 1xDVB-C FBC installed with a total of 16 tuners.
Now I have a few problems here.
the scan does not work. I start in the TVheadend a MUX scan or EPG scan comes out of the DVB-S tuners just no data.
tuning itself I also have problems. Sometimes it must retune a few times before it works.
I unfortunately have absolutely no idea where to start here and therefore I would pray you for help. gladly I can also set up nen remote access so you can look at it yourself.
thank you
The text was updated successfully, but these errors were encountered: