stephan94
Legit VIP
Yes with dcce2
TNAP-6 Image Discussion
- Thread starter EnoSat
- Start date
Yes with dcce2
Excellent!
Connect the MIO receiver and see what files are being used in that window when the receiver slows down. Try satfinder...etc and then check that window.
Connect the MIO receiver and see what files are being used in that window when the receiver slows down. Try satfinder...etc and then check that window.
Thanks to you I can now install Wireguard and start it on my SF8008, but when I choose one of the servers in the list I get this error:
Verify that Wireguard is installed in your image.
Via telnet : opkg wireguard-tools
lme
Legit VIP
Sluggish operation can be caused by memory or cpu drain. Most of the altered files in TNAP have been checked for memory leaks and other things that would cause operation problems. Of course that does not mean that TNAP is not the problem, but a bad file is not gonna magically work good on one receiver, then revert to performing badly on a different receiver. So we will keep looking.
Another option may be to introduce the unedited satfinder into the plugins where it can be downloaded or even make some test images with it installed as default. There seems to be some sort of consensus that satfinder is a problem, but that file has been checked pretty good for memory leaks and other things that would cause poor performance.
LME was nice enough to provide a cpu log in post #164 so let's look at it a moment.
The chart shown above shows the data from lme. CPU threshold for an alarm was set to 90, and the system never got close to that. A scan or something took place that spiked the cpu for roughly a minute, then the cpu settled back down. Memory stayed almost constant.
Another way to look at is by using a graph which is shown below:
A log is generated in this setup once every 10 sends or 6 times per minute. We can analyze a bit further and see about 4 minutes into the logging, and then roughly lasting a minute, the CPU usage spiked above 50%, reaching a maximum of 52.6%. Memory usage remained stable, fluctuating between 38.0% and 38.4%. There is nothing wrong with the TNAP file system if it is running like this. You are gonna have spikes when you do things. But you do not want to have spikes that keep climbing to infinity or overload once a certain task or task(s) starts. Here in this example, spikes happen, but they reach a peak and stabilize. They don't keep going up n up!
The chart shown above shows the data from lme. CPU threshold for an alarm was set to 90, and the system never got close to that. A scan or something took place that spiked the cpu for roughly a minute, then the cpu settled back down. Memory stayed almost constant.
Another way to look at is by using a graph which is shown below:
A log is generated in this setup once every 10 sends or 6 times per minute. We can analyze a bit further and see about 4 minutes into the logging, and then roughly lasting a minute, the CPU usage spiked above 50%, reaching a maximum of 52.6%. Memory usage remained stable, fluctuating between 38.0% and 38.4%. There is nothing wrong with the TNAP file system if it is running like this. You are gonna have spikes when you do things. But you do not want to have spikes that keep climbing to infinity or overload once a certain task or task(s) starts. Here in this example, spikes happen, but they reach a peak and stabilize. They don't keep going up n up!
Last edited:
I would like to see another cpu log after removing the PlutoTV plugin. See if things settle down even more. I haven't removed the PlutoTV plugin just upgraded to a newer version.
Haven't seen any cpu high warnings at all. But with the old plutotv in tnap6 nothing but high warning over 50% after signal finder use.
Haven't seen any cpu high warnings at all. But with the old plutotv in tnap6 nothing but high warning over 50% after signal finder use.
Any Plugins such as PlutoTV that are no longer useful should be dumped and discarded. They are easier to drop from a build than include in a build. On the flip-side, anything that needs to be added should be presented so it can be included.
An enigma2 image with multiple slots is open to mixing files. You have to be careful with mounts and pay attention to what is going on. Image file sizes should be checked, especially during backup to ensure the image is not undersized (small) or big (large). Current TNAP 6 images are close to 400MB when they are decompressed and installed in the receiver.
Backup sticks, pen drives, hard drives, usb drives...etc need to be of at least decent quality and properly verified to be in good working order. The image is almost always the first to be blamed when something does not work right. But indeed sometimes we throw everything including the kitchen sink at a so called fta receiver, then wonder why it does not work correctly. I gotta ask: Are you using your fta receiver as a fta receiver or are you using it as a glorified media box? Our receivers were designed to receive satellite signals with extra provisions to do little of anything else.
There have been reports of the BackupSuite plugin not working correctly, so let's look at it a moment. The BackupSuite basically takes the files installed in the receiver and compresses, then zips them. Nothing much more than that and certainly nothing magical. The BackupSuite plugin was well-written and well thought out. I admire both the creator and maintainers of BackupSuite, but at the end of the day, it does not have a lot to do as compared to some other things.
Here is a screenshot of the BackupSuite working in a MIO receiver. Note that the time to back this receiver up is about 5 minutes, and the file size highlighted in red is roughly 400 MB.
Shown above is roughly what you should have and how long it should take to backup the TNAP6 image. When you add skins, plugins, and a few other things, the file size is certain to rise, but it should not be above 600 MB and ideally should be somewhere between 400 and 500 MB.
Okay, now let's take a TNAP6 file system and throw everything in the kitchen sink at it. As a demonstration, I took the entire "all" folder from feeds and dumped it into the MIO's system files. But wait, that was not enough. So I got an unzipped image and included it in the system's files. Still not big enough, so I took a TNAP6 image unzipped it, extracted it so it was full decompressed, and installed it in the systems files folder along with the other "junk". Then I used BackupSuite to back the mess up (see below).
Notice the file size to backup jumped to a little over a Gig (=1023 MB), and took almost 25 minutes to complete? The point I am trying to make is: some people are running file systems that big and wondering why they have problems. To further complicate, someone decided it was a damn good idea to extend multiboot (4 images aint enough...we need more...lol) which complicates things even further.
A couple of things to remember.
Auto restore is a good thing but it is a two-edged sword. It is a great idea to start with a Freshly Installed image and only transfer lamedb files along with settings files. This does not have to be done every time, but it should be done at regular intervals. When you have problems, start with a Fresh Install which means carry nothing (no files at all) forward into it if you are really having a problem and think it is the image. Auto Restore is image specific! Sure it may work or at least look like it works when you take that backup from an OE Aliiance image and install it in OpenPLi. But looks can be deceiving. My advice is: Don't do it. Use Auto Restore only on image types it was created from.
Mounts and drives should be carefully inspected. If BackupSuite is taking a Long time, then you need to look closely at what you have, especially the drive being used for backup and the image size being backed up. The creators and Maintainers of BackupSuite did not put the log feature in there for nothing. And you can't pack an image full of pooh then expect it to perform properly. So check your backed-up image sizes. If it is enormous or even larger than it should be, find out why.
An enigma2 image with multiple slots is open to mixing files. You have to be careful with mounts and pay attention to what is going on. Image file sizes should be checked, especially during backup to ensure the image is not undersized (small) or big (large). Current TNAP 6 images are close to 400MB when they are decompressed and installed in the receiver.
Backup sticks, pen drives, hard drives, usb drives...etc need to be of at least decent quality and properly verified to be in good working order. The image is almost always the first to be blamed when something does not work right. But indeed sometimes we throw everything including the kitchen sink at a so called fta receiver, then wonder why it does not work correctly. I gotta ask: Are you using your fta receiver as a fta receiver or are you using it as a glorified media box? Our receivers were designed to receive satellite signals with extra provisions to do little of anything else.
There have been reports of the BackupSuite plugin not working correctly, so let's look at it a moment. The BackupSuite basically takes the files installed in the receiver and compresses, then zips them. Nothing much more than that and certainly nothing magical. The BackupSuite plugin was well-written and well thought out. I admire both the creator and maintainers of BackupSuite, but at the end of the day, it does not have a lot to do as compared to some other things.
Here is a screenshot of the BackupSuite working in a MIO receiver. Note that the time to back this receiver up is about 5 minutes, and the file size highlighted in red is roughly 400 MB.
Shown above is roughly what you should have and how long it should take to backup the TNAP6 image. When you add skins, plugins, and a few other things, the file size is certain to rise, but it should not be above 600 MB and ideally should be somewhere between 400 and 500 MB.
Okay, now let's take a TNAP6 file system and throw everything in the kitchen sink at it. As a demonstration, I took the entire "all" folder from feeds and dumped it into the MIO's system files. But wait, that was not enough. So I got an unzipped image and included it in the system's files. Still not big enough, so I took a TNAP6 image unzipped it, extracted it so it was full decompressed, and installed it in the systems files folder along with the other "junk". Then I used BackupSuite to back the mess up (see below).
Notice the file size to backup jumped to a little over a Gig (=1023 MB), and took almost 25 minutes to complete? The point I am trying to make is: some people are running file systems that big and wondering why they have problems. To further complicate, someone decided it was a damn good idea to extend multiboot (4 images aint enough...we need more...lol) which complicates things even further.
A couple of things to remember.
Auto restore is a good thing but it is a two-edged sword. It is a great idea to start with a Freshly Installed image and only transfer lamedb files along with settings files. This does not have to be done every time, but it should be done at regular intervals. When you have problems, start with a Fresh Install which means carry nothing (no files at all) forward into it if you are really having a problem and think it is the image. Auto Restore is image specific! Sure it may work or at least look like it works when you take that backup from an OE Aliiance image and install it in OpenPLi. But looks can be deceiving. My advice is: Don't do it. Use Auto Restore only on image types it was created from.
Mounts and drives should be carefully inspected. If BackupSuite is taking a Long time, then you need to look closely at what you have, especially the drive being used for backup and the image size being backed up. The creators and Maintainers of BackupSuite did not put the log feature in there for nothing. And you can't pack an image full of pooh then expect it to perform properly. So check your backed-up image sizes. If it is enormous or even larger than it should be, find out why.
lme
Legit VIP
I did a fresh flush of the image.
Aparentlly there is no more sluggishness after exiting signal menu, but the backup took more then it was estimated:
Attached are the backup log & cpumonitor log run until the finish of the backup process:
View attachment BackupSuite.zip
View attachment cpu_monitor.zip
The only plugins running are:
infobar
cpu-monitor
msn weather
I will remove Pluto, & see how the box will behave.
Aparentlly there is no more sluggishness after exiting signal menu, but the backup took more then it was estimated:
Attached are the backup log & cpumonitor log run until the finish of the backup process:
View attachment BackupSuite.zip
View attachment cpu_monitor.zip
The only plugins running are:
infobar
cpu-monitor
msn weather
I will remove Pluto, & see how the box will behave.
The estimated time to backup is just that --an estimate. It takes as long as it takes. For example, if you are using an usb 3 port and an usb 3 drive, then you will backup quicker than someone using usb 2.0
Remember, the TNAP6 image uncompressed is around 300-400 MB. Mine was I think 330 something MB and your screenshot already shows 500 MB? The larger the file is, the longer it takes to compress. The more files you have, the longer it takes to compress. So you can estimate how long it might take to compress 100MB, but if that 100MB has 10,000 files in it then compressing it will take a lot longer. And the estimate can be adjusted in the BackupSuite files to read correctly on your system. But then the estimate will be off on someone else's system. So it is just an estimate.
It might be a good idea to find where all of these files or why the image size is already so great. And it shouldn't take 30 something minutes to compress 500 MB, at leas we would think. You need to test your backup drive and find out where your extra weight in MB file size is.
Here is a graph of cpu and memory. Again, cpu rises up, then levels out. Neither the cpu nor memory is rising uncontrolled
.
lme
Legit VIP
Removing Pluto did not fix the sluggishness or the backup.
I noticed that the box become sluggish after i look in the "service list" menu. Also for few minutes the box is slow and mistaken inputs from the remote: pressing "menu" on the remote, the box displays channel list or nothing at all !
The sluggishness disappears after a while !!
Here is the pic of the htop: i noticed a red item !!
I noticed that the box become sluggish after i look in the "service list" menu. Also for few minutes the box is slow and mistaken inputs from the remote: pressing "menu" on the remote, the box displays channel list or nothing at all !
The sluggishness disappears after a while !!
Here is the pic of the htop: i noticed a red item !!
Your htop screen shows the image being backed up. Backing up the image takes resources.
Two things stand out here.
(1) Your image is too big and for no apparent reason.
(2) Your time needed to make a backup using the BackupSuite Plugin is entirely too long. Either you are backing up a ton of files, your disk is bad, or the connection between the disk is bad. Those three are the most likely or at least probable for the backup issues.
Two things stand out here.
(1) Your image is too big and for no apparent reason.
(2) Your time needed to make a backup using the BackupSuite Plugin is entirely too long. Either you are backing up a ton of files, your disk is bad, or the connection between the disk is bad. Those three are the most likely or at least probable for the backup issues.
stephan94
Legit VIP
here's the result with the MIO4K
Attachments
You don't want to run backupsuite while running cpu logger. I tried it didn't go good.
Plutotv most likely is not a problem. Probably just a fluke why things got better for me after upgrading it. I removed other plugins one at a time and ddn't see a change but after pluto I saw a change but like I say fluke.
lme
Legit VIP
I do not understand how tnap6 image size is so big & take so much time for backup to be completed, compared to tnap5.1., as I have the same amount of picons, channels & so on files. Didn't added anything else to version 6 versus version 5.1. Same number of plugins!
I just did a backup from version 5.1 & was estimated to take 7.5', but done in 5.4'! Version 6 estimates 61.44' but is still running past this number using same usb stick! Noticed different "backup suit" versions in the 2 versions ! Has anything to do with program ?
I will start to delete the plugins 1 by 1 & see what is the result. Hope I don't have to uninstall backup suit also because this will fix it!
lme
Legit VIP
This is acceptable compared with +/-55' !
Removed "CPU Usage Monitor", but it is still listed after it was removed !!!!
Thank you.
Of course it is listed after it was removed!!!
You may delete whatever you want from your receiver. But you cannot delete files from TNAP6 server.
To clarify:
This screenshot is your receiver. You may delete or add anything you wish.
This screenshot is TNAP6 Feeds. You cannot delete anything here.
To clarify further, When you have a Plugin or other item installed in your receiver, Then the same, identical item will not be shown in TNAP6 feeds. When you delete something in your receiver and an identical item exists in TNAP6 feeds, THEN that item will be shown as available to download and install. Bottom line: What you see in TNAP6 feeds is what is available for download. Items that are already installed in your receiver Will Not be shown in TNAP6 feeds. Items Not Installed Will BE Shown in TNAP6 feeds.