Alpha/Beta releases for build 14 #65
Comments
|
What happened to build 13??? :) |
|
Just a quick note to whom it may concern: |
|
Hello @perexg... sorry to be annoying you but could you please try to make a new beta build with new commit from minisatip? @catalinii make some changes to improve the buffer issue on wan. thanks |
|
Hi @perexg thanks for the new build. It uses minisatip5 as far as I can see from a ps -ef call: 3367 root 0:01 minisatip5 -f -g -P 1 How can enable the minisatip7 version to be started at boot time? I found the config.default file in /etc that looks like: minisatip 0.5#MINISATIP5="yes" minisatip 0.7MINISATIP7="yes" Can I change it to minisatip7 also when booting from USB stick and not flashing the firmware to the internal flash storage? Please support a newbie. :-) Thanks |
|
Just merge the /etc/config.default with your /etc/sysconfig/config . The configuration file is not replaced when you upgrade to the new version. You should do it yourself (select new minisatip version and update arguments). |
|
To see some channels in Spain I need to change the LO1 / LO2 frequency to 9750/9750 on my DIGIBIT r1. -L --lnb specifies the adapter and LNB parameters (low, high and switch frequency) eg: -L *:9750-10600-11700 - sets all the adapters to use Universal LNB parameters (default) Which modifier should I use with minisat7? Thanks |
|
It's same source code. Check 'minisatip7 --help'. So -L like you described. |
|
@perexg first of all thanks for the new build.... remember the old continuity problems with minisatip5? i am still getting those... i will try this night with -B flag to see if i have improvements any other sugestions will be welcome. |
|
Works perfect @perexg !! |
|
tried this night with -B 10000 and -B 20000 and still have: 2017-04-27 12:02:37.455 TS: DVB-S 30/12245.34H/Sport TV 1 HD: H264 @ #6433 Continuity counter error (total 1) don't know if you remember but this issues como from: |
|
Try to resolve this with @catalinii in catalinii/minisatip#326 . He wrote that the code is not much tested. I think that he will require some logs to check where is the problem . Assuming, that you don't have this problem when client/server is on the local network. |
|
@perexg thanks i will ask him to have a look on this and if we have problems i get back to you |
|
@estimadarocha, @perexg: Just for reference, I have had issues with 0.5 producing cc errors as well. Reported them here at the time. I have never been able to resolve them. Running axe-fw with minisatip 0.3 version ever since. Anyways, if you should need additional logs or tests, please just let me know... |
|
@m4tt075 did you try the 0.7? @perexg i know you split your time on different projects (great job on tvheadend) but i really hope you have a few left for this. today i make some more tests that i think that will help us getting closer to the problem... Like i said before and at least for me the most part of the cc errors are when i try to send streams to external network (wan). So until the new build with minisatip 0.7 i was not able to do something like this: satipaxe ----> minisatip ----> tvheadend (on dedicated server) with this setup the cc errors almost disappear, so i believe (and after a lot of information exchange with catalinii) that real problem is somehow related with kernel and hardware itself on Inverto, digibit, grundig. catalinii think that hardware it self have a limitation of about 4-5MB/s on lan because tcp use of resources and memory, saying that he also believes that sending a stream over wan to a destination 40-50ms away that this limit decreases to 1MB/s on tcp. This don't happen with udp however he also find issues with packet drops without kernel reporting... old kernel???? By the way if i make something like this: minisatip (with local dvb card) ----> tvheadend (on dedicated server) also 0 cc errors, so even i am a newbie on this i really believe we are looking to the wrong place, because if minisatip standard work the problem can't be own minisatip, right? |
|
Hi, if I remember right, I managed also to get around 7MB (for all 4 tuners) in lan (udp) by running: make DVBAPI=0 DVBCSA=0 DVBAES=0 DVBCA=0 . This disables tables and enable the codepath from https://github.com/catalinii/minisatip/blob/0.7/stream.c#L908 which basically just dumps what is received form the DVR device to the network. Few other notes:
Thanks |
Do you see any 'CC Errors' increase in the webui (http://axe-ip:8080) ? If the CPU usage (see top in command-line - satip-axe box) is bellow 90%, then everything should be ok.
I don't know about this. The 0.5 was heavily tested with tvheadend which opens many transpoders in the scan phase - no noticable delays between tunings.
I'm using the TCP data mode in 0.7 and I'm able to stream 2 full muxes (around 12MB) through the local lan now. I need to verify 0.7 code more - I found another issue yesterday and looking to the code, there are other things which should be re-added (axe_skippkt code was removed for example). |
|
About axe_skippkt, this will be fixed in 0.7.5.
Basically I am allowing the data to pass thru just after the new PAT is
received. This is a system wide solution as DVB is also affected by it.
Just to confirm, are you able to use 12MB on rtsp over tcp with the binary
compiled in the latest axe image ?
Thank you
…On Fri, Apr 28, 2017 at 4:57 PM, perexg ***@***.***> wrote:
with this setup the cc errors almost disappear, so i believe (and after a
lot of information exchange with catalinii) that real problem is somehow
related with kernel and hardware itself on Inverto, digibit, grundig.
Do you see any 'CC Errors' increase in the webui (http://axe-ip:8080) ?
If the CPU usage (see top in command-line - satip-axe box) is bellow 90%,
then everything should be ok.
minisatip 0.5 have a small issue closing the streams which is visible on
axe, which takes about 3-4 seconds (fixed in 0.7).
I don't know about this. The 0.5 was heavily tested with tvheadend which
opens many transpoders in the scan phase - no noticable delays betwen tuning
About the faster code path theoretically it can be implemented even if the
dvbapi is compiled inside of minisatip but only if it is disabled at
runtime.
I'm using the TCP data mode in 0.7 and I'm able to stream 2 full muxes
(around 12MB) through the local lan now. I need to verify 0.7 code more - I
found another issue yesterday and looking to the code, there are other
things which should be re-added (axe_skippkt code was removed for example).
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#65 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AH0gEQL9dfCkk6QnfqMKgo9EEL_d1_vJks5r0Y3JgaJpZM4I3rUQ>
.
|
Yes. My fixes / changes are in https://github.com/perexg/minisatip/commits/axe7 . I'm looking for the high CPU usage for the full mux streaming and it seems that the culprit is small writev() calls for the TCP socket. |
|
Does it work better if you compile without tables (the make I have wrote in
my earlier post ) ?
…On Fri, Apr 28, 2017 at 6:25 PM, perexg ***@***.***> wrote:
Basically I am allowing the data to pass thru just after the new PAT is
received. This is a system wide solution as DVB is also affected by it.
OK. Just to confirm, are you able to use 12MB on rtsp over tcp with the
binary compiled in the latest axe image ?
Yes. My fixes / changes are in https://github.com/perexg/
minisatip/commits/axe7 .
I'm looking for the hight CPU usage for the full mux streaming and it
seems that the culprit is small writev() calls for the TCP socket.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#65 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AH0gERCZBUigu_vsBMTBJd3f-SW7Bxfkks5r0aJ4gaJpZM4I3rUQ>
.
|
|
The binary is already without this junk :-) configure --enable-axe --disable-dvbca --disable-dvbcsa --disable-dvbaes --disable-netceiver |
|
Ohh. It seems that --disable-dvbapi is missing. Retesting.. |
|
Feel free to push the changes once you are done.
Thanks
…On Fri, 28 Apr. 2017, 18:45 perexg, ***@***.***> wrote:
Ohh. It seems that --disable-dvbapi is missing. Retesting..
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#65 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AH0gEVcmW5DSSL3u0aFxW19gvv0qLw7Uks5r0ac_gaJpZM4I3rUQ>
.
|
|
OK. New version is available (only minisatip7 fixes/changes) for download. I can stream 3 full muxes almost without errors through RTP/TCP data transfer mode. If you use only RTP/TCP data transfer mode, you can set buffering to these values -b 4042752 -B 10000 . |
|
environment: satipaxe to tvheadend (on dedicated) tell me if you need some logs 2017-04-28 17:19:20.578 TS: DVB-S 30/12322H/RTP 2: MPEG2VIDEO @ #5152 Continuity counter error (total 1) |
|
Provide log with '-llllllllllllllll', I'm using 'ssh -t root@satipbox minisatip7 ARGS | tee out.txt' . Also, kill the minisatip in box before any tests and create /tmp/nosatip file (touch /tmp/nosatip) to avoid minisatip respawn. Also, do all tests only with one service (channel). |
|
@perexg webinterface is up after Looks for now that diseqc position AB-BA-BB are not working in tvheadend althoug satip webinterface correctly shows position switching from 1-4. Will do further testing. My setup is 4x diseqc 1.0 astra19.2 astra 23.5 astra 28.2 with positions AA BA BB. |
|
@perexg Thanks for the last version. With this i even don't get CC errors in TVH while epggrab. This is the first time! Thanks again! |
|
@walterav1984 : Yes, it seems that @catalinii removed some code for standard diseqc config... |
|
@walterav1984 : Try satip-axe-201705041725-14.tgz . |
|
@perexg Thanks for the diseqc fixes, however I was partly incorrect about its misbehavior because I was debugging it while another user was also using the same Digitbit Telestar device at the same time using a other satellite position on the same tuner than I was. For now it seems to switch between Astra 19.2 23.5 28.2 using 3 diseqc 1.0 AA BA BB positions. AB is not in use. I'll try the satip-axe-201705041725-14.tgz and keep you updated when I have 3x full mux testing application. |
|
@perexg: Ok, now UDP works. RTPoverTCP - LiveTV starts shortly and then stops .... A longer test will follow. Results tomorrow. (CC-Error from RTPoverTCP Test.) |
|
Note that 'CC errors' in the above table (minisatip status page) are 'CC errors' in the axe hardware (on the signal demodulator side). It has nothing to do with the packet/data loss in minisatip or the network connection. You should check the client stats for this (and notice that the errors accumulate - thus the final client will see all 'demodulator + minisatip + network' TS packet loss). |
|
Thank you for the information. Thank you perexg. |
|
@perexg: TVH crashed twice in the last couple of hours, which is unusual. Not sure this is related with the FW update or 0.7. though. I have activated debug logging (START, STOP, CRASH) on the server now to track potential issues. Will keep you posted. |
|
@m4tt075 i can confirm the same behaviour... my tvheadend is now also dear or live locked... you should try to use debug for Dead or Live Lock https://tvheadend.org/projects/tvheadend/wiki/Debugging as @perexg sugested. by the way i have done that for my self but the gdb appears to also crash: |
|
@perexg with the last satip-axe-201705041725-14 the best settings still -b 4042752 -B 10000 and the use of RTP/AVP/TCP (embedded data) on tvheadend? |
|
@estimadarocha, @perexg: You are right. My system is not crashing either, but dead or live locked. The log is full of "too much queued table input data (over 2MB), discarding new" lines, which do not seem to harm, but locks. No hints in the log. I cannot run gdb on my Synology NAS though without jumping through major hoops. Hope @estimadarocha's is sufficient... |
|
@perexg returned back from satip-axe-201705041725-14 to satip-axe-201704301818-14 this afternoon cc errors started again and i catch a ton of them on tvheadend... after the revert it seens better but i need to mention i also update tvheadend from 4.3-33 to 4.3-44 dunno if this helped also. Indeed i have logs from 2 satipaxes's can you have a look on them? they are huge like 500mb and 1gb. thanks for all the hard work on this... |
|
Before you report CC errors, check if CC value in minisatip's web (port 8080) is not increasing (reception issue) and if you turn 'Stats ON' (latest), the tt value must be under 900ms otherwise CPU in the box is busy and some TS packets may be dropped. Only logs with a description may be helpful - so if you see CC error in tvh/client, just give me log with lines 10 seconds before the CC error and 5 seconds after the CC error. Also, try to run minisatip without logging as first to see if the logging don't eat CPU which may be used for the packet delivery. |
|
I @perexg... and thanks for the quick answer... answering your questions: the cc errrors on 8080 did not increase and I was not even using loging when the issues start... I started after that and run it for a while.... when that happened i was with stats on and the tt never go higher than 200ms... About the log is too hard now say you the exact lines cause I don't remember the exact time I had errors on tvheadend.... but there where many.... Will try to catch again later this night |
|
@perexg i have been looking at this again and now i am almos sure thats nothing to do with hardware errors or reception... on 8080 the cc doesn't increase and the TT 99% of time lower than 100ms. this are the errors i got on tvheadend: 2017-05-08 15:25:48.089 TS: DVB-S 30/12245.34H/Sport TV 1 HD: H264 @ #6433: Invalid start code e3:81:60 i will start running the logs to see if we can find the origin? want me to run any special trace on tvheadend side? |
|
@estimadarocha : It's probably problem with the stream decrambling (wrong or late key or so). It does not seem to be related to satip-axe at all. If you have original card for the soft-descrambling, create a bug in the tvheadend's bugtracker and provide "--trace descrambler,capmt,cwc" logs. If you use a remote (not yours) card server, I cannot help. |
|
After upgrading from satip-axe-201607042257-12 to satip-axe-201705120938-14 one specific channel does not play using HTSP protocol (Kodi, VLC), and TVH gives below errors. I tried with minisatip7, minisatip5 and minisatip. If the channel is played in VLC using HTTP it's fine. 2017-05-12 20:52:23.395 parser: Polskie/11662V/Novela Tv: H264 @ #2061: PTS and PCR diff is very big (292419) 2017-05-12 20:52:25.666 parser: Polskie/11662V/Novela Tv: H264 @ #2061: PTS and PCR diff is very big (298294) 2017-05-12 20:52:28.022 parser: Polskie/11662V/Novela Tv: H264 @ #2061: PTS and PCR diff is very big (292009) 2017-05-12 20:52:30.264 parser: Polskie/11662V/Novela Tv: H264 @ #2061: PTS and PCR diff is very big (291801) 2017-05-12 20:52:32.598 parser: Polskie/11662V/Novela Tv: H264 @ #2061: PTS and PCR diff is very big (290106) 2017-05-12 20:52:34.842 parser: Polskie/11662V/Novela Tv: H264 @ #2061: PTS and PCR diff is very big (293202) Thanks. |
|
@nhsman : It's not satip-axe firmware issue, but an issue with new PCR code in the development version of TVH: https://tvheadend.org/issues/4336 . I put some related fixes to v4.3-62-gedb3919 , but if your problem persist, please, write a comment to the tvheadend's tracker. |
|
Already updated to v4.3-62-gedb3919 forgot to mention about it in previous post. The issue its still there. I have checked and the issue is just with one channel, the other channels from the same mux are ok. |
|
What should I do if I suffer from random continuity errors? I have Telestar Digibit R1 with the build 14 release candidate and the only thing I changed in the config is to have a static IP address. I haven't added any minisatip options. The R1 is connected to this LNB with all four cables. All for tuners are set to have first position for Astra 19.2E and second position for Astra 23.5 in Tvheadend. One suspicious thing is that the tuners have quite low SNR percentage in Tvheadend status, although their Signal Strength is around 100 %. These values were better with the previous device (Kathrein EXIP 414) and exactly the same LNB and cables. The continuity errors are seemingly random, it doesn't matter whether all four tuners are in use or just one. It can go an hour without an error and than the TV freezes for a moment several times a minute. Can I provide more information? I don't think there's anything special about the settings in Tvheadend, but here they are: http://imgur.com/a/zXi9v |
|
@ondrejmirtes : Enable RTP/AVP/TCP (embedded data) in the device config in tvh. It will fix the "lost UDP packets" on the local network. But if you see CC errors in the minisatip status page (http://satipaxeip:8080), then you should fix the reception path (LNB/diseqc/cabling). Each devices/tuners have different sensitivity. Just for a reference: I have SNR value around 100% for 23.5E. |
|
To all: upgrade to latest satip-axe-201705251044-14 . |
|
Saw this thread by chance & upgraded my Grundig GSS400 to the latest version. It seems to work well with minisatip7 but the info page showed roughly 1800 CC errors within 12 hours and 50M packets. Thanks for your effort! |
|
I have just upgraded to satip-axe-201705251044-14, deactivated minisatip 0.3 and activated minisatip 0.7. OTA EPG grabbing went through smoothly, but then my TVH backend dead-locked again. I will keep the firmware for the time being, but revert to minisatip 0.3. That is the only minisatip version that has been stable and reliable for me since months now... |
|
@m4tt075 : Your issue is not related to minisatip7. Report a bug in the tvheadend bugtracker and try to enter some tvh state info (backtraces for all threads). |
|
@perexg: I wish I could, but am running TVH on a Synology NAS (busybox). Have been trying to produce traces several times but failed as often. |
|
@perexg: I have managed to get some traces. Opened the ticket here: |
|
The last build satip-axe-201705251044-14 was pushed to git repo as build 14. Closing this issue now. |
satip-axe-201606052125-12 : http://s000.tinyupload.com/index.php?file_id=09305921237368855627
satip-axe-201607042257-12: http://s000.tinyupload.com/?file_id=76010383569268262995
satip-axe-201704251332-14: http://s000.tinyupload.com/?file_id=09610049347884937425
satip-axe-201704281541-14: http://s000.tinyupload.com/?file_id=87136955848410183622
satip-axe-201704301818-14 : http://s000.tinyupload.com/?file_id=99831436976501991768
satip-axe-201705031710-14 : http://s000.tinyupload.com/index.php?file_id=16483531869123084476
satip-axe-201705041725-14: http://s000.tinyupload.com/index.php?file_id=06599606906064565216
satip-axe-201705120938-14: http://s000.tinyupload.com/?file_id=62831890803152238184
satip-axe-201705251044-14: http://s000.tinyupload.com/?file_id=03787878807018547026
BUILD 14 FINAL CANDIDATE
The text was updated successfully, but these errors were encountered: