Open SaulGoodman1337 opened 1 year ago
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?
what does this show http://192.168.0.112:8875/desc.xml
What was not correctly exported? what does this show
http://192.168.0.112:8875/desc.xml
All good. I think that some new version of Satpi has settled.
<root configId="0">
<specVersion>
<major>1</major>
<minor>1</minor>
</specVersion>
<device>
<deviceType>urn:ses-com:device:SatIPServer:1</deviceType>
<!-- filled in by server -->
<friendlyName>SatPI Server (192.168.178.4)</friendlyName>
<!-- filled in by server -->
<manufacturer>Marc Postema</manufacturer>
<manufacturerURL>https://github.com/Barracuda09/SATPI</manufacturerURL>
<modelDescription>SatPI is a SAT>IP Server for Linux</modelDescription>
<!-- filled in by server -->
<modelName>SatPI Server (192.168.178.4)</modelName>
<!-- filled in by server -->
<modelNumber>SatPI/1.6.2.100~g9b31903 Enigma</modelNumber>
<!-- filled in by server -->
<modelURL>https://github.com/Barracuda09/SATPI</modelURL>
<serialNumber>1S81A31231000007</serialNumber>
<!-- filled in by server -->
<UDN>uuid:50c958a8-e839-4b96-b7ae-001dec16a6bd</UDN>
<!-- filled in by server -->
<UPC>123456789012</UPC>
<iconList>
<icon>
<mimetype>image/png</mimetype>
<width>48</width>
<height>48</height>
<depth>24</depth>
<url>/assets/images/icons/sm.png</url>
</icon>
<icon>
<mimetype>image/png</mimetype>
<width>120</width>
<height>120</height>
<depth>24</depth>
<url>/assets/images/icons/lr.png</url>
</icon>
<icon>
<mimetype>image/jpeg</mimetype>
<width>48</width>
<height>48</height>
<depth>24</depth>
<url>/assets/images/icons/sm.jpg</url>
</icon>
<icon>
<mimetype>image/jpeg</mimetype>
<width>120</width>
<height>120</height>
<depth>24</depth>
<url>/assets/images/icons/lr.jpg</url>
</icon>
</iconList>
<!-- filled in by server -->
<presentationURL>http://192.168.178.4:8875/</presentationURL>
<!-- filled in by server -->
<!-- filled in by server -->
<satip:X_SATIPCAP>DVBS2-8,DVBC-8</satip:X_SATIPCAP>
<!-- filled in by server -->
<!-- filled in by server -->
<satip:X_SATIPM3U>/channellist.m3u</satip:X_SATIPM3U>
<!-- filled in by server -->
</device>
</root>
But I have attached a debug log here. Here I have started a scan via TVheadend. The continues errors are also very disturbing. I ALWAYS have that when I switch to a channel. The switching times are sometimes 10 seconds or more. I see in the log also very many broken pipes...
@SaulGoodman1337
You could try to compile a regular build of SatPI (so no debug version)
With:
make ENIGMA=yes LIBDVBCSA=yes ICAM=yes
I can do that, but what's the point? I have the problem since I have this receiver (6 weeks) and have until the day before yesterday used a regular build of satpi.
Ok, what does cmd top
say for CPU usage?
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?
Ok, and memory usage?
Mem: 255672K used, 1364324K free, 66976K shrd, 8836K buff, 145024K cached
looks good.
You could maybe try to disable in TvHeadend the RTP/AVP/TCP transport support
just to see if that changes the behavior
You could maybe try to disable in TvHeadend the
RTP/AVP/TCP transport support
just to see if that changes the behavior
same behavior :(
the behavior here doesn't seem right to me either, does it?
Fri Feb 3 04:23:23.9178 2023 [ src/input/dvb/Frontend.cpp:801] Frontend: 4, FE_READ_STATUS: Resource temporarily unavailable (code 11)
Fri Feb 3 04:23:24.0336 2023 [ src/input/dvb/Frontend.cpp:801] Frontend: 4, FE_READ_STATUS: Resource temporarily unavailable (code 11)
Fri Feb 3 04:23:24.1425 2023 [ src/input/dvb/Frontend.cpp:801] Frontend: 4, FE_READ_STATUS: Resource temporarily unavailable (code 11)
Fri Feb 3 04:23:24.2502 2023 [ src/input/dvb/Frontend.cpp:801] Frontend: 4, FE_READ_STATUS: Resource temporarily unavailable (code 11)
Fri Feb 3 04:23:24.3597 2023 [ src/input/dvb/Frontend.cpp:801] Frontend: 4, FE_READ_STATUS: Resource temporarily unavailable (code 11)
Fri Feb 3 04:23:24.4677 2023 [ src/input/dvb/Frontend.cpp:801] Frontend: 4, FE_READ_STATUS: Resource temporarily unavailable (code 11)
Fri Feb 3 04:23:24.5750 2023 [ src/input/dvb/Frontend.cpp:801] Frontend: 4, FE_READ_STATUS: Resource temporarily unavailable (code 11)
Fri Feb 3 04:23:24.6825 2023 [ src/input/dvb/Frontend.cpp:801] Frontend: 4, FE_READ_STATUS: Resource temporarily unavailable (code 11)
Fri Feb 3 04:23:24.7896 2023 [ src/input/dvb/Frontend.cpp:801] Frontend: 4, FE_READ_STATUS: Resource temporarily unavailable (code 11)
Fri Feb 3 04:23:24.8969 2023 [ src/input/dvb/Frontend.cpp:801] Frontend: 4, FE_READ_STATUS: Resource temporarily unavailable (code 11)
Fri Feb 3 04:23:25.0148 2023 [ src/input/dvb/Frontend.cpp:801] Frontend: 4, FE_READ_STATUS: Resource temporarily unavailable (code 11)
Fri Feb 3 04:23:25.1376 2023 [ src/input/dvb/Frontend.cpp:801] Frontend: 4, FE_READ_STATUS: Resource temporarily unavailable (code 11)
Fri Feb 3 04:23:25.2474 2023 [ src/input/dvb/Frontend.cpp:801] Frontend: 4, FE_READ_STATUS: Resource temporarily unavailable (code 11)
Fri Feb 3 04:23:25.3567 2023 [ src/input/dvb/Frontend.cpp:801] Frontend: 4, FE_READ_STATUS: Resource temporarily unavailable (code 11)
Fri Feb 3 04:23:25.4655 2023 [ src/input/dvb/Frontend.cpp:801] Frontend: 4, FE_READ_STATUS: Resource temporarily unavailable (code 11)
Fri Feb 3 04:23:25.5742 2023 [ src/input/dvb/Frontend.cpp:801] Frontend: 4, FE_READ_STATUS: Resource temporarily unavailable (code 11)
Fri Feb 3 04:23:25.6867 2023 [ src/input/dvb/Frontend.cpp:801] Frontend: 4, FE_READ_STATUS: Resource temporarily unavailable (code 11)
Fri Feb 3 04:23:25.8009 2023 [ src/input/dvb/Frontend.cpp:801] Frontend: 4, FE_READ_STATUS: Resource temporarily unavailable (code 11)
Fri Feb 3 04:23:25.9080 2023 [ src/input/dvb/Frontend.cpp:801] Frontend: 4, FE_READ_STATUS: Resource temporarily unavailable (code 11)
Fri Feb 3 04:23:26.0320 2023 [ src/input/dvb/Frontend.cpp:801] Frontend: 4, FE_READ_STATUS: Resource temporarily unavailable (code 11)
Fri Feb 3 04:23:26.1383 2023 [ src/input/dvb/Frontend.cpp:801] Frontend: 4, FE_READ_STATUS: Resource temporarily unavailable (code 11)
Fri Feb 3 04:23:26.2460 2023 [ src/input/dvb/Frontend.cpp:801] Frontend: 4, FE_READ_STATUS: Resource temporarily unavailable (code 11)
Fri Feb 3 04:23:26.2470 2023 [ src/input/dvb/Frontend.cpp:809] Frontend: 4, Not locked yet (Timeout 3515 ms)...
Fri Feb 3 04:23:26.2475 2023 [ src/mpegts/Filter.h:138] Frontend: 4, Updating PID filters...
Fri Feb 3 04:23:26.2482 2023 [ src/input/dvb/Frontend.cpp:494] Frontend: 4, Opened /dev/dvb/adapter0/demux3 using fd: 37
Fri Feb 3 04:23:26.2518 2023 [ src/input/dvb/Frontend.cpp:500] Frontend: 4, Set DMX buffer size to 18874368 Bytes
Fri Feb 3 04:23:26.2531 2023 [ src/input/dvb/Frontend.cpp:516] Frontend: 4, Set DMX_SET_SOURCE with (Src: 3 - Offset: 32)
Fri Feb 3 04:23:26.3055 2023 [ src/mpegts/Filter.h:163] Frontend: 4, Set filter PID: 0000
Fri Feb 3 04:23:26.3265 2023 [ src/mpegts/Filter.h:163] Frontend: 4, Set filter PID: 0001
Fri Feb 3 04:23:26.3729 2023 [ src/mpegts/Filter.h:163] Frontend: 4, Set filter PID: 0016
Fri Feb 3 04:23:26.3942 2023 [ src/mpegts/Filter.h:163] Frontend: 4, Set filter PID: 0017
Fri Feb 3 04:23:26.4412 2023 [ src/mpegts/Filter.h:163] Frontend: 4, Set filter PID: 0018
Fri Feb 3 04:23:26.4419 2023 [ src/input/dvb/Frontend.cpp:439] Frontend: 4, Updating frontend (Finished in 3779 ms)
Fri Feb 3 04:23:26.4423 2023 [ src/output/StreamThreadRtcpBase.cpp:086] Frontend: 4, Restart RTCP/UDP stream to 192.168.178.2:50631
Fri Feb 3 04:23:26.4425 2023 [ src/output/StreamThreadBase.cpp:192] Frontend: 4, Restart RTP/UDP stream to 192.168.178.2:50630
Fri Feb 3 04:23:26.4428 2023 [ src/HttpcServer.cpp:217] Send reply in 3990 ms
Fri Feb 3 04:23:26.4428 2023 RTSP/1.0 200 OK
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
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. Did you check https://github.com/Barracuda09/SATPI/wiki/Using-SatPI-as-frontend-for-Tvheadend
That means TvHeadend is probably timing out before the reply is send. Did you check https://github.com/Barracuda09/SATPI/wiki/Using-SatPI-as-frontend-for-Tvheadend
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. but i still have a lot of continues errors on both tuners. DVB-C as well as DVB-S.
something is wrong here
Well there is a lot going on in the log you send (scanning on multiple frontends). This will interfere during logging text. This is not wise to log maybe al the time: https://github.com/Barracuda09/SATPI/blob/9b31903e434adbe18d2a4cd4711add834cfc0e6f/src/mpegts/NIT.cpp#L214-L228
I discovered something else interesting. If I only scan DVB-S, it works reasonably well. If I only scan DVB-C, it works reasonably well. If I start both at the same time, DVB-S runs into a timeout.
but continues errors I have constantly on all frontend.... -.-
Well there is a lot going on in the log you send (scanning on multiple frontends). This will interfere during logging text. This is not wise to log maybe al the time:
yes, but you want to have a logfile? Or what do you want to tell me with that?
Well it is also a remainder to myself.
I have to check this here is @nikolauzi11 having probably the same problem in (https://github.com/Barracuda09/SATPI/issues/181)
I have to check this here is @nikolauzi11 having probably the same problem in (#181)
yes, that smells kind of similar. I hope you get this fixed. until then, thank you very much!
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. I would give the softpid filter a chance. can you revert the commit #9870875 for the current branch to test?
Hi @SaulGoodman1337
Thanks for testing!
You could checkout that commit yourself in the master branch with:
git branch -f beforesoftpid 93aee95
git checkout beforesoftpid
make ENIGMA=yes LIBDVBCSA=yes ICAM=yes
Now the correct commit before
Hi @SaulGoodman1337
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.
@SaulGoodman1337
No unfortunately there is no icam support in that commit
Then I go back to the newer version for now. But I can tell you that it runs better by far. Thanks
just tried to cherrypick the icam stuff into the before branch, but can't build it.
src/mpegts/PAT.cpp: In member function 'mpegts::TSData mpegts::PAT::generateFrom(FeID, const TransformationMap&)': src/mpegts/PAT.cpp:87:20: error: 'pid' was not declared in this scope tmp[1] = 0x40 | (pid & 0x1F) >> 8; ^~~ src/mpegts/PAT.cpp:87:20: note: suggested alternative: 'id' tmp[1] = 0x40 | (pid & 0x1F) >> 8; ^~~ id src/mpegts/PAT.cpp:89:13: error: 'scrambled' was not declared in this scope tmp[3] = (scrambled & 0x3) << 6 | (payloadOnly & 0x3) << 4 | (cc & 0xF); ^
~~~~ src/mpegts/PAT.cpp:89:38: error: 'payloadOnly' was not declared in this scope tmp[3] = (scrambled & 0x3) << 6 | (payloadOnly & 0x3) << 4 | (cc & 0xF); ^~~src/mpegts/PAT.cpp:89:65: error: 'cc' was not declared in this scope tmp[3] = (scrambled & 0x3) << 6 | (payloadOnly & 0x3) << 4 | (cc & 0xF); ^~ src/mpegts/PAT.cpp:96:22: error: 'version' was not declared in this scope tmp[10] = (0xC0 | ((version & 0x1F) << 1) | (currIndicator & 0x01)); ^~~ src/mpegts/PAT.cpp:96:47: error: 'currIndicator' was not declared in this scope tmp[10] = (0xC0 | ((version & 0x1F) << 1) | (currIndicator & 0x01)); ^~~~~ src/mpegts/PAT.cpp:113:6: warning: unused variable 'pmtPid' [-Wunused-variable] int pmtPid = 0x0100; ^~make: *** [Makefile:211: obj/mpegts/PAT.o] Fehler 1
Hi @SaulGoodman1337
Could you please try the latest commit, to see if this solves the issue.
Hi @SaulGoodman1337
Could you please try the latest commit, to see if this solves the issue.
nope, sorry....same behavior
Could you make a log once more
Could you make a log once more
Of course, it's in the appendix. I started Satpi here, did "clear all statistic" in TVHeadend and then started a scan directly. here are still a lot of continunity errors.
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
Hi @SaulGoodman1337
Could you please check last commit? This should revert most of commit https://github.com/Barracuda09/SATPI/commit/98708753109d3e6744edc8dc7b9aeb8f6b60f416 for DVB frontends.
Hi @SaulGoodman1337
Did you reboot the receiver at some time?
Much better ! However, SatPI dies multiples times. now at the scan 4 times. currently I help myself here with a script.
#/bin/bash
while true; do
if pgrep satpi > /dev/null
then
echo "satpi running"
else
echo "starting satpi"
LD_PRELOAD=/home/root/libdvbcsa.so /usr/bin/satpi --http-path /usr/share/satpi/web
fi
sleep 3
done
but as you can see still not perfect. i'm getting desperate :(
but as you can see still not perfect. i'm getting desperate :(
Me too
[ 2446.899971] vmap allocation for size 28315648 failed: use vmalloc=
to increase size. [ 2446.908320] vmalloc: allocation failure: 28311552 bytes [ 2446.913586] RtspServer: page allocation failure: order:0, mode:0xd2 [ 2446.919935] CPU: 2 PID: 3395 Comm: RtspServer Tainted: P O 4.1.45-1.17 #1 [ 2446.927862] Hardware name: Broadcom STB (Flattened Device Tree) [ 2446.933807] [ ] (unwind_backtrace) from [ ] (show_stack+0x10/0x14) [ 2446.941566] [ ] (show_stack) from [ ] (dump_stack+0x80/0x94) [ 2446.948803] [ ] (dump_stack) from [ ] (warn_alloc_failed+0xdc/0x120) [ 2446.956736] [ ] (warn_alloc_failed) from [ ] (vmalloc+0xd8/0xe4) [ 2446.964321] [ ] (vmalloc) from [ ] (dvb_demux_do_ioctl+0x404/0x724) [ 2446.972173] [ ] (dvb_demux_do_ioctl) from [ ] (dvb_usercopy+0x84/0x18c) [ 2446.980366] [ ] (dvb_usercopy) from [ ] (do_vfs_ioctl+0x1c8/0x628) [ 2446.988121] [ ] (do_vfs_ioctl) from [ ] (SyS_ioctl+0x38/0x64) [ 2446.995442] [ ] (SyS_ioctl) from [ ] (ret_fast_syscall+0x0/0x3c) [ 2447.003065] Mem-Info: [ 2447.005360] active_anon:3544 inactive_anon:67 isolated_anon:0 [ 2447.005360] active_file:3143 inactive_file:5871 isolated_file:0 [ 2447.005360] unevictable:0 dirty:0 writeback:0 unstable:0 [ 2447.005360] slab_reclaimable:1384 slab_unreclaimable:2798 [ 2447.005360] mapped:3452 shmem:163 pagetables:646 bounce:0 [ 2447.005360] free:310535 free_pcp:1152 free_cma:3481 [ 2447.038490] DMA free:250900kB min:1024kB low:1280kB high:1536kB active_anon:2332kB inactive_anon:72kB active_file:3460kB inactive_file:5484kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:395264kB managed:361992kB mlocked:0kB dirty:0kB writeback:0kB mapped:1348kB shmem:136kB slab_reclaimable:5536kB slab_unreclaimable:11192kB kernel_stack:1344kB pagetables:364kB unstable:0kB bounce:0kB free_pcp:2420kB local_pcp:560kB free_cma:0kB writeback_tmp:0kB pages_scanned:0 all_unreclaimable? no [ 2447.082786] lowmem_reserve[]: 0 0 1212 1212 [ 2447.087079] HighMem free:991116kB min:512kB low:1400kB high:2288kB active_anon:11844kB inactive_anon:196kB active_file:9112kB inactive_file:18000kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:2717696kB managed:1258004kB mlocked:0kB dirty:0kB writeback:0kB mapped:12460kB shmem:516kB slab_reclaimable:0kB slab_unreclaimable:0kB kernel_stack:0kB pagetables:2220kB unstable:0kB bounce:0kB free_pcp:2300kB local_pcp:612kB free_cma:13924kB writeback_tmp:0kB pages_scanned:0 all_unreclaimable? no [ 2447.131709] lowmem_reserve[]: 0 0 0 0 [ 2447.135459] DMA: 334kB (UEM) 68kB (EM) 116kB (E) 332kB (UEM) 364kB (UE) 0128kB 2256kB (UE) 0512kB 01024kB 22048kB (UE) 604096kB (MR) = 250852kB [ 2447.149737] HighMem: 34kB (UMC) 68kB (UM) 116kB (M) 632kB (MC) 264kB (UC) 0128kB 2256kB (UM) 2512kB (UC) 21024kB (MC) 02048kB 2414096kB (UMRC) = 991116kB [ 2447.164992] 9056 total pagecache pages [ 2447.168769] 0 pages in swap cache [ 2447.172114] Swap cache stats: add 0, delete 0, find 0/0 [ 2447.177359] Free swap = 0kB [ 2447.180254] Total swap = 0kB [ 2447.183147] 778240 pages RAM [ 2447.186040] 679424 pages HighMem/MovableOnly [ 2447.190325] 369145 pages reserved [ 2447.193653] 4096 pages cma reserved [ 2450.582937] FE tune fe_handle=d5e4b400 [ 2454.296162] FE tune fe_handle=d5866400 [ 2472.437208] FE tune fe_handle=d5e45800 [ 2491.932930] FE tune fe_handle=d5e4b000 [ 2493.011368] FE tune fe_handle=d5e4b400 [ 2494.395499] FE tune fe_handle=d5866400 [ 2495.562850] FE tune fe_handle=d5ebcc00 [ 2496.981393] FE tune fe_handle=d5e45800 [ 2536.081292] FE tune fe_handle=d5e45800 [ 2541.880682] FE tune fe_handle=d5e4b400 [ 2542.808252] FE tune fe_handle=d5e4b000 [ 2543.817633] FE tune fe_handle=d5ebcc00 [ 2544.762664] FE tune fe_handle=d5866400 [ 2545.769740] FE tune fe_handle=d5dd7c00 [ 2552.655430] FE tune fe_handle=d5e7b000 [ 2562.988869] FE tune fe_handle=d5e4b000 [ 2571.647722] FE tune fe_handle=d5ebcc00 [ 2576.427008] FE tune fe_handle=d5e4b000 [ 2579.229390] FE tune fe_handle=d5dd7c00 [ 2581.698469] FE tune fe_handle=d5e4b400 [ 2586.069021] FE tune fe_handle=d5e45800 [ 2587.047233] FE tune fe_handle=d5866400 [ 2597.049582] FE tune fe_handle=d5ebcc00 root@vuduo4kse:~#
i think that is of interest. i'll try to lift that up
[ 2446.899971] vmap allocation for size 28315648 failed: use vmalloc= to increase size.
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. Like for example with Minisatip the buffer parameter. am I right?
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 should I maybe set up a VPN profile for you and you "make yourself a picture" of it?
so i have now tried your latest build and the whole thing works. thanks ! But it is so incredibly slow.... I have the problem that when a scan runs over the 16 tuners, I can no longer tune a station because it just takes too long. He then runs into a timeout. I think a parallelization makes here sense, right?
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