TNAP-4.1-Test Images for Edision MIO/MIO+

[el bandido]

Updates to the TNAP image are being made, Test versions of TNAP 4.1 are available to be downloaded. These images are tested to boot and function correctly, but some adjustments need to be made and a few more items need to be added. Efforts are made on TNAP images to enhance blind scanning of DVB satellites, and to make the receiver more useful for users in North America. Some features or items may be missing that are useful in Europe or other parts of the world.

You may access the TNAP 4.1 test images by installing the attached plugin, or by installing the same plugin located in the receiver's downloadable plugins under "extra" plugins as shown below. Installing the TNAP 4,1 flashimage plugin does nothing more than set the correct url in the receiver to download the 4.1 images. Select the Flash image menu in the receiver after installing the 4.1 flashimage plugin. (Ask if you need more assistance with this.)

Test images are test images. Comments or suggestions about making things better are welcome. Downloading and installing anything is done at your own risk!
Making a full backup of the current image is suggested before installing TNAP 4.1. Doing this allows foe a complete restore point. TNAP 4.1 may also be installed in a different slot as the receivers have 4 slots available for image installations.


17233 17234

17235 17236

[eelstrebor]

I just installed TNAP 4.1. I can't find a way to sync time.

[el bandido]

The SystemTime Plugin has been discontinued in TNAP 4.1. Time control has been made to be automatic, and does not require much input from the user. Currently there are no plans to add a manual time sync for the user, but we can probably add one if it is really needed. For now, run it like it is and see how the time works.

There will be time problems if the settings file is not cleaned!
SystemTime is built into TNAP 4.1 images which means that all references to time must be removed from the settings file that is located in /etc/enigma2 of the receiver's file system. Failure to remove the time references from the settings file will result in erratic time keeping!

Here is an old settings file that has been previously installed in TNAP images, and is also in TNAP 4.1:

config.epg.freesat=false
config.epg.netmed=false
config.epg.viasat=false
config.misc.hotkey.blue=MenuPlugin/scan/blindscan
config.misc.hotkey.green=Infobar/openServiceList
config.misc.hotkey.red=MenuPlugin/scan/positioner_setup
config.misc.useTransponderTime=false
config.misc.videowizardenabled=false
config.Nims.0.configMode=advanced
config.Nims.1.configMode=advanced
config.plugins.bitrate.background=#54111112
config.plugins.bitrate.show_in_menu=infobar
config.plugins.bitrate.style_skin=compact
config.plugins.bitrate.x=1647
config.plugins.bitrate.y=822
config.plugins.bitrate.z=10
config.plugins.SystemTime.syncNTPcoldstart=true
config.plugins.SystemTime.useNTPminutes=2880
config.plugins.SystemTime.wifi_delay=15
config.plugins.weathermsn.city=atlanta
config.plugins.weathermsn.degreetype=F
config.plugins.weathermsn.windtype=fts
config.skin.primary_skin=GlamourAuraFHD/skin.xml
config.usage.infobar_frontend_source=tuner
config.usage.setup_level=expert
config.usage.subnetwork_cable=true
config.usage.subnetwork_terrestrial=true
In the above example, we need to remove 4 lines of code. This can be done using telnet by entering the init 4 command to sleep the receiver, then navigate in to the settings file and remove the needed lines. Entering the init 3 command will restart the system.

Make sure the box has a good working internet connection, edit the settings file as shown above, then either reboot the box or wait wait for the time to sync, which should be about 30 minutes for ntp.

A lot of users will transfer their settings file automatically when updating or changing images. This is OK to do most of the time, but once some entries are put into the settings file, they will stay there until manually deleted. This is why sometimes a "Fresh Install" is suggested or recommended.

[Megatron817]

Yep I setup TNAP 4.1 clean without restoring settings and no time problem here. about 48 hours now. I did have to set the video refresh rate to 60Hz it was set at 50Hz to start with.

[el bandido]

TNAP 4.1 was shipped with the settings file shown in post#3, so you need to clean it.
I will try to update the images tomorrow where they have this settings file:

config.epg.freesat=false
config.epg.netmed=false
config.epg.viasat=false
config.misc.hotkey.blue=MenuPlugin/scan/blindscan
config.misc.hotkey.green=Infobar/openServiceList
config.misc.hotkey.red=MenuPlugin/scan/positioner_setup
config.misc.videowizardenabled=false
config.Nims.0.configMode=advanced
config.Nims.1.configMode=advanced
config.plugins.bitrate.background=#54111112
config.plugins.bitrate.show_in_menu=infobar
config.plugins.bitrate.style_skin=compact
config.plugins.bitrate.x=1647
config.plugins.bitrate.y=822
config.plugins.bitrate.z=10
config.plugins.weathermsn.city=atlanta
config.plugins.weathermsn.degreetype=F
config.plugins.weathermsn.windtype=fts
config.skin.primary_skin=GlamourAuraFHD/skin.xml
config.usage.infobar_frontend_source=tuner
config.usage.setup_level=expert
config.usage.subnetwork_cable=true
config.usage.subnetwork_terrestrial=true

Thanks for the 50Hz info.

[cyberham]

A good tip! I have those references in my settings file. I will clean and try the clock again.

Added: Have edited the settings file. I'll keep my Mio+ in Standby and see how the clock behaves.

[Pacman]

Thank you again for the post!������

[stephan94]

Hello ,
a small problem with this version 4.1 of TNAP.
when I want to get the list of satellites by pressing green,
I only get "current transponder".
is there a way to get the satellite list?

on the other hand the T2MI Plugin is again present
and when it is activated, the T2MI works perfectly

have a good day

stephan94

[cyberham]

Press the green button again. It should then show the list of satellites.

[el bandido]

Code lines that start with config.misc.useTransponderTime or config.plugins.SystemTime have been blackballed. These lines of code will automatically be deleted from the /etc/enigma2/settings file when using images that are dated 20210809 or later. I do not like to set up automatic deletes like this, but someone will always have a time issue due to loading old settings unless this is done. Anyone loading TNAP 4.1 image that is dated 20210809 or later should not worry about editing the settings file for now. This will not be changed unless it starts giving problems.

Updated images are available as shown here:
17248


There was never a time issue with TNAP 4.0 for users that put the receiver in standby while watching a terrestrial channel that had correct time. There should not be any time issues in TNAP 4.1 with correctly set internet connections when the receiver is put in standby if ntp is selected as shown here:
17249

config.ntp.timesync=ntp will be added to the default settings file for TNAP 4.1. This code line sets the receiver for ntp operation, but will probably be overwritten if settings are transferred from a previous image. It is important to check the receiver menu shown above and make sure the time settings are correct for your system!

[stephan94]

Press the green button again. It should then show the list of satellites.

Thanks for your advice cyberman,
Unfortunately this does not work.

another method to get the list of satellites?
because currently version 4.1, because of this problem, is not really usable for my needs.

have a good day

[el bandido]

Press the green button once gives the channels for the satellite you are tuned to.
Press the green button twice gives the satellite list.

We need to find out why your receiver does not do this.

[stephan94]

I am in Germany, I always put the menu in German language.
I wanted to make a video to show you the problem, so that
it is easier for you, I changed the language and I put the menu in English,
and suddenly, what a surprise, by pressing the green button, the list of satellites
appeared ?! it's great I will finally be able to work with version 4.1.
What does not solve this problem: why with the German language it does not work.
In all other versions since the start of TNAP, I have never encountered this problem.

and if everything works correctly I would soon delete version 4.0 because the T2MI does not work with it.

have a good day

Stephan94

[el bandido]

I see the problem now. Do not know what it will take to fix the problem today.

Your 4.0 image is old. You may install this 4.0 image with T2MI option: [Only registered and activated users can see links]

[el bandido]

T2MI plugins were added to the TNAP 4.0 image feeds a few minutes ago. They were missing for some reason... Run software update to see them.

The satellites and language issue will be fixed soon in TNAP 4.1.

[stephan94]

Hello el bandido
another problem, this time with the KA band.
I am using a modified LNB to be able to get the frequencies of the KA (A) band 18200-19200.
my LOF (20357) is higher than the search band (as in band C)
This possibility existed (huevos), we had discussed it a lot with you among other things in PM at the end of 2018
but it has disappeared so the value of the frequency found is bad.
Could there be a way to have that possibility again

Thanks in advance

Stephan

ps: I know this request is a bit larger than topic TNAP4.1

[el bandido]

The satellite display should be fixed. Flash New Image to test. Thanks.

17257


17259

[Megatron817]

With the latest 20210813 getting a crash doing a tuner configuration change. I can post the log if it is not happening on your box EB.

[el bandido]

Need to see the crash log. NimManager was updated/changed. Thanks.

[Megatron817]

Crash log

Also did a factory reset. Did not crash anymore but my favorites list did not get erased after the factory reset like they should have been.

[cyberham]

I downloaded from online and installed the August 13 TNAP 4.1 image. All images loaded prior to this did not solve my clock issue when I switched my Mio+ to standby. My Mio+ clock has always been accurate if I left the receiver powered. However, this latest release may be the magic bullet. So far, the clock is remaining correct even in standby. I will continue leaving the receiver in standby whenever I am not using it to test if it remains accurate.

Added: This morning I installed the new August 15 image. Continuing to monitor.

[stephan94]

Hello
I updated today to 4.1.
Unfortunately the problem of the satellite list which does not work in German language is still there

Have a good day

Stephan94

[el bandido]

There never was a time problem when the receiver was in standby --as long as the last channel had the correct time!
Enigma2 receivers and fta receivers in general are set to grab the time from the transponder. The reason for this is simple: Most other parts of the world besides North America send the correct time on all transponders that can be seen by a fta receiver. North America does not do that.

The SystemTime plugin worked well, but was misunderstood by some users. This led to other time problems.
TNAP is based on OpenPLi. OpenPLi made the SystemTime plugin obsolete months ago, but the SystemTime plugin was retained in TNAP. This caused other time issues because two partial sets of time keeping files ended up in TNAP 4.0. So it depends on how you were running your fta system as to whether you had a time problem or not.

There should be no more time issues in TNAP, providing you have set the receiver to a transponder with the correct time If using Transponder time, Or if you have a decent and correctly set Internet connection if using NTP time. If you need to sync the time for some unknown reason, then reboot the box. Otherwise, set the receiver up correctly for the time and forget about it...

[el bandido]

Hello
I updated today to 4.1.
Unfortunately the problem of the satellite list which does not work in German language is still there

Have a good day

Stephan94


In your About screencap, 2021-08-07 Is your enigma version. Online updates were not set correctly before, but are today. Either install the image (Flash image), or try another online update.

17264

17265

17266

KA Blindscan to be added!

[el bandido]

Crash log

Also did a factory reset. Did not crash anymore but my favorites list did not get erased after the factory reset like they should have been.

Try an online update. It should work now. If online update does not show 8-15 fro enigma2 in the About menu, then flash the 8-15 image.

720p 60 Hz boot should be fixed.
Factory reset needs work...
Thanks!

[Megatron817]

Try an online update. It should work now. If online update does not show 8-15 fro enigma2 in the About menu, then flash the 8-15 image.

720p 60 Hz boot should be fixed.
Factory reset needs work...
Thanks!

8-15 no issue here.
I see an option missing even on the earlier versions of 4.1
There is no option to remove satellite or Terrestrial services in the channel context menu.

[stephan94]

In your About screencap, 2021-08-07 Is your enigma version. Online updates were not set correctly before, but are today. Either install the image (Flash image),
KA Blindscan to be added!

Thanks it works well,
I have done the flashimage method successfully.:bigthumbup:

Ka blindscan, I can't find where it is?
I can't find the inversion when the LOF is above the search area.
KA-SAT search does not match KA LNBs

[el bandido]

KA Blindscan to be added later! . Not available or Not working today....

[el bandido]

8-15 no issue here.
I see an option missing even on the earlier versions of 4.1
There is no option to remove satellite or Terrestrial services in the channel context menu.

"Remove selected satellite" should be available after an online update.

[Megatron817]

"Remove selected satellite" should be available after an online update.

Yes, now available after online update. Thanks

[el bandido]

Factory reset should be fixed, but you need to Flash today's image online and not take the online updates. The reason for this is simple: There is a package named tnap-extras that has been updated. This package contains the Factory reset files we want to use. So if you take the online update, then these files will be installed which means you will lose both channels and settings.

Factory reset should now eliminate any stored Bouquets. Factory reset also restores the hidden radio channels on 103w ku.

17270

17271

[stephan94]

Hello ,
Living in europe, is it necessary to do this factory reset?

have a good day

[el bandido]

Hello ,
Living in europe, is it necessary to do this factory reset?

have a good day

No!
Have a Great Day!!!

[clucas]

So now I did it. I installed the enigma2-plugin-extra-tnap-4.1-flashimage_1.1 plugin and went to do a software update and my receiver just sits there with the word "boot" on the display. I've tried to reboot and kept hitting the menu button, nothing. I then renamed the noforce to force file and installed the TNAP-4.1-osmio4k_usb.zip in downloaded images folder but still no luck. My USB stick has a backup I made before I did any updates but I don't see any way to get there to restore it since the receiver is locked in the boot mode. Suggestions?

[Megatron817]

So now I did it. I installed the enigma2-plugin-extra-tnap-4.1-flashimage_1.1 plugin and went to do a software update and my receiver just sits there with the word "boot" on the display. I've tried to reboot and kept hitting the menu button, nothing. I then renamed the noforce to force file and installed the TNAP-4.1-osmio4k_usb.zip in downloaded images folder but still no luck. My USB stick has a backup I made before I did any updates but I don't see any way to get there to restore it since the receiver is locked in the boot mode. Suggestions?

When you power up the receiver as soon as you see the edision splash screen repeat pressing menu button on the remote should give the recovery boot screen. I did what you said you did and ran software update and no issue here I don't know what happened on your end. Where did you get TNAP-4.1-osmio4k_usb.zip? You don't put a TNAP usb.zip in downloaded_images folder. TNAP Usb.zip needs to be extracted to a usb drive no folder.

[el bandido]

So now I did it. I installed the enigma2-plugin-extra-tnap-4.1-flashimage_1.1 plugin and went to do a software update and my receiver just sits there with the word "boot" on the display. I've tried to reboot and kept hitting the menu button, nothing. I then renamed the noforce to force file and installed the TNAP-4.1-osmio4k_usb.zip in downloaded images folder but still no luck. My USB stick has a backup I made before I did any updates but I don't see any way to get there to restore it since the receiver is locked in the boot mode. Suggestions?

Performing a software update from most versions of TNAP 4 would result in failure because TNAP 4.1 is different. Everything should have been OK if you would have flashed the image instead of doing an online update. Maybe there will be a way to fix this from happening in the future, but software update and Flash image are two different things and cannot always be interchanged.

TNAP-4.1-osmio4k_usb.zip Does not exist as a download. This file was never posted online that I know about.
TNAP-4.1-osmio4k_20210818_usb.zip Does exist and is attached.
To recover:
(1) Download TNAP-4.1-osmio4k_20210818_usb.zip
(2) Use a Known-To-Be-Good usb drive and extract the TNAP-4.1-osmio4k_20210818_usb.zip file to the usb drive.
(3) Unzip TNAP-4.1-osmio4k_20210818_usb.zip. This will give you a folder named TNAP-4.1-osmio4k_20210818_usb on the usb drive.
(4) Power the receiver OFF by unplugging the power source. Insert prepared usb drive into the receiver. Remove all other usb devices from the receiver if any are attached.
(5) Power On the receiver and follow onscreen instructions.

If you cannot see the onscreen instructions, then you may power off then power on the receiver and rapidly press the ok button on the remote until you see the loading process start on the receiver's screen. Else, navigate to the noforce file on the prepared usb stick and rename it to force.

[clucas]

The file you posted got me in. Didn't boot by itself but did when I kept hitting "OK". Thanks, EB!

[k7ar]

EB I prepared a USB stick just as you described but when I rebooted the Mio+ it just normally rebooted, I didn't see any additional instructions. I tried pressing OK several times while restarting, and renamed noforce to force but as I said it rebooted the existing May 23rd image. Thanks for any suggestions.

Alan Rovner
Vancouver, Wash.

[clucas]

Alan,

Just remember I have the Mio4k not the "+". Maybe that's why the file worked for me.

[el bandido]

EB I prepared a USB stick just as you described but when I rebooted the Mio+ it just normally rebooted, I didn't see any additional instructions. I tried pressing OK several times while restarting, and renamed noforce to force but as I said it rebooted the existing May 23rd image. Thanks for any suggestions.

Alan Rovner
Vancouver, Wash.

Attached is the correct file for mio+

[cyberham]

I downloaded from online and installed the August 13 TNAP 4.1 image. All images loaded prior to this did not solve my clock issue when I switched my Mio+ to standby. My Mio+ clock has always been accurate if I left the receiver powered. However, this latest release may be the magic bullet. So far, the clock is remaining correct even in standby. I will continue leaving the receiver in standby whenever I am not using it to test if it remains accurate.

Added: This morning I installed the new August 15 image. Continuing to monitor.
Perhaps I have a unique hardware issue with my Mio+. But it is clear the clock issue continues after all. As I've been sitting here for the past 30 minutes, the clock has deviated dramatically 2 times. It is now 3 hours in the future and probably the date is in the last century (1969 or 1970). I would have to power it up to check that.

For the record:
1) I have carefully followed the updates for TNAP 4.1. The current time shows Friday, January 2, 1970 11:16 am. Time is approximately 3 hours in the future and the date is 51 years behind. My current software is TNAP 4.1 2021-08-15.

2) I have never used anything but the Internet time synchronization method. I have never used transponder time sync since owning this receiver. I learned years ago with previous receivers that transponder sync doesn't work in Canada. My Internet is stable and reliable.

3) When needed, lately if I reboot, I am using the deep standby selection. It seemed in past, this provided a better reboot since it powers down the receiver completely. When powering up, the receiver goes to clock mode. I then press POWER on my remote to switch on the receiver.

4) If I only do a restart, then the receiver restarts but the TV does not display anything. I must cycle the power on the receiver so the TV then syncs and displays a picture.

5) My workaround is OK for me. I simply never power down the receiver to standby. Doing this keeps the receiver totally accurate. Some don't like to leave the receiver on all the time. I don't mind.

6) It seemed when I first installed this software update that it had resolved the issue since I could leave the receiver in standby for long periods (even overnight) and the clock remained accurate. It almost seemed like the issue developed again over time. As I'm using the receiver, it has just corrected itself automatically. It will remain accurate now as long as I don't go to standby.

7) Months ago, we had a very bad lightning storm. One particular strike nearby caused a power hit. This seemed to have an impact on receiver operation. I changed HDMI cable, etc. This is why I'm wondering if I have a hardware issue.

[el bandido]

Post your settings file located in /etc/enigma2 of receiver files. It will be OK to do this as long as you have no logins to Facebook or any other website that requires a password.

[MikeB]

Perhaps I have a unique hardware issue with my Mio+. But it is clear the clock issue continues after all. As I've been sitting here for the past 30 minutes, the clock has deviated dramatically 2 times. It is now 3 hours in the future and probably the date is in the last century (1969 or 1970). I would have to power it up to check that.

For the record:
1) I have carefully followed the updates for TNAP 4.1. The current time shows Friday, January 2, 1970 11:16 am. Time is approximately 3 hours in the future and the date is 51 years behind. My current software is TNAP 4.1 2021-08-15.

2) I have never used anything but the Internet time synchronization method. I have never used transponder time sync since owning this receiver. I learned years ago with previous receivers that transponder sync doesn't work in Canada. My Internet is stable and reliable.

3) When needed, lately if I reboot, I am using the deep standby selection. It seemed in past, this provided a better reboot since it powers down the receiver completely. When powering up, the receiver goes to clock mode. I then press POWER on my remote to switch on the receiver.

4) If I only do a restart, then the receiver restarts but the TV does not display anything. I must cycle the power on the receiver so the TV then syncs and displays a picture.

5) My workaround is OK for me. I simply never power down the receiver to standby. Doing this keeps the receiver totally accurate. Some don't like to leave the receiver on all the time. I don't mind.

6) It seemed when I first installed this software update that it had resolved the issue since I could leave the receiver in standby for long periods (even overnight) and the clock remained accurate. It almost seemed like the issue developed again over time. As I'm using the receiver, it has just corrected itself automatically. It will remain accurate now as long as I don't go to standby.

7) Months ago, we had a very bad lightning storm. One particular strike nearby caused a power hit. This seemed to have an impact on receiver operation. I changed HDMI cable, etc. This is why I'm wondering if I have a hardware issue.

I will BET MONEY, that regardless of these receivers being set to grab time via NTP, they somehow ALSO randomly sync time to whatever transponder you are sitting on. IF that time is wrong (which we all know in the USA is most are wrong), then it goes to that time. At least until the next time sync interval.

WHY that happens, I don't know, but I'm pretty sure that's what's doing it.

[Megatron817]

I know I use a startup service with a good time accurate Transponder and clock stays accurate. The reason I do that is my internet is a hot spot and not always online. The ATSC channels using the Hauppauge tv tuner are good startup services and I think 103W ku has some transponders that have accurate time the one with DW English was the last I checked and I believe the transponder with NHK world is accurate but not 100% sure on that one. I use an ATSC channel.

[MikeB]

I know I use a startup service with a good time accurate Transponder and clock stays accurate. The reason I do that is my internet is a hot spot and not always online. The ATSC channels using the Hauppauge tv tuner are good startup services and I think 103W ku has some transponders that have accurate time the one with DW English was the last I checked and I believe the transponder with NHK world is accurate but not 100% sure on that one. I use an ATSC channel.

On 99W, scan in AFN 3900 V DVB-S2 8psk 27500 2/3. One of the channels is called: "Bars & Tone". Save that one to a Bouquet, and use it for the Startup Service, as it seems to keep perfect time.

[cyberham]

Lately, I have been using the Media Player more than previously since it offers access to a lot of channels I can't receive via Ku. I notice today that the receiver time went back to January 1970 while I was using the receiver and I wasn't in standby. I noticed this when I started using the Media Player. I wonder if using the player may trigger the receiver to lose its clock accuracy? When the date goes wrong, then the Media Player no longer will stream channels. Lack of ability to stream was one reason why I noticed the time had gone wrong earlier today. So I left the Media Player and went back to normal satellite use. And waited. There is no way now to force an immediate time update without restarting the receiver. The time was eventually updated.

My Settings file is attached.

[el bandido]

This setting makes your receiver turn Off when you turn it On...

config.usage.startup_to_standby=yes

There are a few other changes that can be made. So we will see if we can find something that works.

[cyberham]

The reason I set the receiver to turn off when it deep restarts is because then when I power it on I can see a picture on my TV. If I just allow a restart without that, the receiver ends up being on but there is no picture on the TV. So I have to manually turn off the receiver and then turn it on to sync with the TV and show a picture.

[el bandido]

What is the correct setting for your tv? Is it 1080i or 720p?

[el bandido]

Check your messages and you will find an image link. Your settings file has been modified a bit and is installed in that image. Save your lamedb and lamedb5 files that are in /etc/enigma2. Then install the image. Do Not allow an auto restore to take place, and really that option should not be present because your settings file is in it. Once the image is installed, stop enigma2 using the init 4 command in telnet, then transfer the lamedb and lamedb5 files that you saved back into /etc/enigma2 folder of the receiver. Restart enigma2 using the init 3 command, and the receiver should be setup with your channels and settings.

[cyberham]

It supports 1080i, 1080p and lower.

[cyberham]

I read your instructions here after I installed the image you sent. It didn't do an auto restore. So all I had to do was reset the GUI (I like PLi-FullNightHD), restore my channels and bouquets via Dreamset, and deep restarted the receiver. It is running now normally on TNAP 4.1 2021-08-20. I have reinstalled my m3u8 playlists so I can use the Media Player. I will continue to monitor the receiver.

[el bandido]

When you restore via Dreamset, you put the crap right back in that I took out.

[Megatron817]

If you put those m3u8 files into a bouquet they will play as a channel then you don't have use media player.
I'll share my list here as an example and using notepad++ you can edit the file and add your channels to it.
The file goes in etc/enigma2
When you extract the zip it may be in a folder but you want just the bouquets IPTV file not folder in etc/enigma2.
To add to this some characters when editing your URLS will need to be changed. I Know a : after [Only registered and activated users can see links] will need to be [Only registered and activated users can see links] in the URL.And after the .com,.org. get another % instead of:. I guess that is the way e2 handles it.

[MikeB]

If you put those m3u8 files into a bouquet they will play as a channel then you don't have use media player.
I'll share my list here as an example and using notepad++ you can edit the file and add your channels to it.
The file goes in etc/enigma2
When you extract the zip it may be in a folder but you want just the bouquets IPTV file not folder in etc/enigma2.
To add to this some characters when editing your URLS will need to be changed. I Know a : after [Only registered and activated users can see links] will need to be [Only registered and activated users can see links] in the URL.And after the .com,.org. get another % instead of:. I guess that is the way e2 handles it.

I second this. I found this out last year, and that's how I do them also. Works perfectly. Only issue I see, is that IF you are recording any of them, (yes, you can set timer recordings for IP channels) AND they have a break or hesitation in the streaming, the recording will quit immediately.

[cyberham]

Crap? Dreamset causes problems? I haven't experienced any that I know of. I only use it to copy my info as a backup to my PC. Or to write it back. I don't actually use Dreamset to edit anything.

I can re-install the new image if necessary.

[cyberham]

If you put those m3u8 files into a bouquet they will play as a channel then you don't have use media player....
I guess my question is why do all those maneuvers? I have hundreds of channels categorized in playlists according to US, Japan, Canada, English, etc. I never want to record these, just roam and watch. Unless there is an issue with the Media Player, it works fine for me. And when it's time to update them, then I source them again and just update the playlists.

[el bandido]

Crap? Dreamset causes problems? I haven't experienced any that I know of. I only use it to copy my info as a backup to my PC. Or to write it back. I don't actually use Dreamset to edit anything.

I can re-install the new image if necessary.

Your settings file had some crap in it that may/may not have caused problems. When you restored using Dreamset, then you most likely restored the settings file which put the same lines back in that I deleted....
No worries. Just see if the time works better.

[Megatron817]

I guess it would take a long to do hundreds. I only have about dozen. lol I stream mostly youtube but I am watching Super Channel IPTV right now it has some good American movies but it got some greek words on the screen.

[cyberham]

Check your messages and you will find an image link. Your settings file has been modified a bit and is installed in that image. Save your lamedb and lamedb5 files that are in /etc/enigma2. Then install the image. Do Not allow an auto restore to take place, and really that option should not be present because your settings file is in it. Once the image is installed, stop enigma2 using the init 4 command in telnet, then transfer the lamedb and lamedb5 files that you saved back into /etc/enigma2 folder of the receiver. Restart enigma2 using the init 3 command, and the receiver should be setup with your channels and settings.
I re-installed the new image. All went well except I ended up with no bouquets. The channels and settings are there. So I repeated the whole process. Same result.

Once I used init 4 via telnet to stop enigma2, I used Filezilla to copy lamedb and lamedb5 overwriting the existing lamedb and lamedb5 in the receiver. I exited Filezilla and went back to telnet to use init 3.

[cyberham]

I don't see that Dreamset copies the settings file.

[el bandido]

The question is: Does the tv work correctly now without using any extra restarts to get a picture? If it does not help, then you may restore again from Dreamset to get everything you want back.

Thanks for checking!!!

[cyberham]

I guess it would take a long to do hundreds. I only have about dozen. lol I stream mostly youtube but I am watching Super Channel IPTV right now it has some good American movies but it got some greek words on the screen.
I don't see Super Channel in my list. I'll check your list. I do watch youtube frequently. Lots to learn from that source. If I want to fix my lawn mower, for example, I turn to youtube.

[clucas]

I downloaded from online and installed the August 13 TNAP 4.1 image. All images loaded prior to this did not solve my clock issue when I switched my Mio+ to standby. My Mio+ clock has always been accurate if I left the receiver powered. However, this latest release may be the magic bullet. So far, the clock is remaining correct even in standby. I will continue leaving the receiver in standby whenever I am not using it to test if it remains accurate.

Cyberham, My time seems to hold with the latest TNAP 4.1 as I have recordings done overnight with no issues. In the "Customize" menu the last two lines deal with the time. Mine is set to "Internet (ntp)" and the last line is using pool.ntp.org. Have you tried this setting?

[cyberham]

The question is: Does the tv work correctly now without using any extra restarts to get a picture? If it does not help, then you may restore again from Dreamset to get everything you want back.

Thanks for checking!!!

No, the receiver restarts but there is no picture on the TV. I must power cycle on the remote to get the TV to sync to the receiver. In past, I've tried different combinations of 720p, 1080p, 1080i and 60 Hz / auto / multi. Nothing resolves that issue. I think this started with the lightning storm. So I like using the Startup in Standby switch so once the clock appears, I know I can power on the receiver.

[MikeB]

No, the receiver restarts but there is no picture on the TV. I must power cycle on the remote to get the TV to sync to the receiver. In past, I've tried different combinations of 720p, 1080p, 1080i and 60 Hz / auto / multi. Nothing resolves that issue. I think this started with the lightning storm. So I like using the Startup in Standby switch so once the clock appears, I know I can power on the receiver.

Have you tried a different HDMI port on your tv set, and maybe even with a new HDMI cable?

[cyberham]

I've done this swapping before. But just now I tried swapping to another TV port and switching to a different HDMI cable. All I found is that my newest cable from ebay doesn't work at all with the Edision yet it works with my older sat receiver and new laptop PC. That's strange. There are a lot of parameters on A/V settings menu. Who knows if the default settings are correct. For example, switching off pre-emphasis terminates the picture. I switched that back on fast. Maybe one of the other switches on that menu is wrong. I'd normally check the instruction manual.

Added: what do you know! I enabled the HDMI-CEC menu on the receiver. Now when I restart the receiver, the TV picture comes on.

[stephan94]

this concerns the two versions of TNAP 4.0 and 4.1
if you are with the T2MI plugin
it works perfectly with 32APSK (these are the first programs I see in 32APSK)

[cyberham]

Cyberham, My time seems to hold with the latest TNAP 4.1 as I have recordings done overnight with no issues. In the "Customize" menu the last two lines deal with the time. Mine is set to "Internet (ntp)" and the last line is using pool.ntp.org. Have you tried this setting?

I have these settings also. I have always used the Internet as my reference. Since my receiver sits facing me I can always see the clock. This morning I witnessed it go from accurate to wildly inaccurate while in Standby. So I powered it up and the date was 1970. Mike knows what I am talking about since he seems to have the same issue. I am retiring from attempting to troubleshoot this. Most of the time it is accurate. When inaccurate, it fairly quickly corrects so I don't think it will affect recordings very often.

[el bandido]

I am retiring from attempting to troubleshoot this.

The final image is only as good as the efforts that are put into it!

[el bandido]

Hello el bandido
another problem, this time with the KA band.
I am using a modified LNB to be able to get the frequencies of the KA (A) band 18200-19200.
my LOF (20357) is higher than the search band (as in band C)
This possibility existed (huevos), we had discussed it a lot with you among other things in PM at the end of 2018
but it has disappeared so the value of the frequency found is bad.
Could there be a way to have that possibility again

Thanks in advance

Stephan

ps: I know this request is a bit larger than topic TNAP4.1

We can try to put this in the image now. What is the correct LOF? 20357 for the LOF does not seem correct.
20357MHz−950MHz = 19407MHz
20357MHz-2150MHz = 18207MHz

What is the make/model of the lnb?

Where can this lnb be purchased?
Thanks.

[Megatron817]

The final image is only as good as the efforts that are put into it!

Comparing TNAP 4.1 to OpenPli 8.1 I left my internet on all night and I checked OPenPli 8.1 First.With the time setting set to internet ntp the only way it worked correct was to set a startup service channel with the right time transponder. I used DW english 103ku band. after the Mio rebooted time was good. I then changed the channel to Cozi 103KU band and put the Mio in standby and went to bed woke up over five hours later the clock on the front of the mio showed 4:42 looked at my phone it showed 4:42 so all was good with OpenPLi 8.1. I then turned on the Mio and Booted TNAP 4.1 and using the same settings in the menu as OpenPli 8.1 did the same process and put the Mio in standby went back to bed woke back up afew hours later the clock was way off and date was 1970. So some reason Tnap 4.1 is not grabbing the NTP time in standby and the startup service time is not keeping. Use a startup service and transponder time works perfect.

[el bandido]

Try Flashing the image online to 8-22-2021. Then retest.
17278


The 8-22 image changes UPDATE_HWCLOCK="no" to UPDATE_HWCLOCK="yes"
17279

Make sure the time synchronization is set to internet(ntp) after the 8-22 image is installed.
17280

A bit of additional information:
Making changes inside a file like the one shown above may not be seen in online software updates - even if the changed file is updated on the feed server. The reason for this is simple: While the information inside the package may have changed, the package version did not. So when the receiver is looking for online updates while running Software update, it will not "see" the new ntp package because the package version is identical to the old package in the receiver. This is why sometimes you need to Flash the image instead of trying to run Software update and thinking all is well... It all depends on which packages are being updated and how the package version information is set.

[Megatron817]

8-22-21 is working correctly without a startup service and internet ntp set.
Will go to standby and test it out.

[Megatron817]

Clock jumped ahead and date 1969 around an hour in so didn't fix it.

[MikeB]

Clock jumped ahead and date 1969 around an hour in so didn't fix it.

That sucks.

Observations: What I find especially interesting about this, even IF you have it set to only use NTP time, and set it to sync even in Standby, is IF you also have the Mio parked on a transponder with the proper time set, the time stays perfect.

Conversely, IF the same settings above, BUT, you have it parked on a transponder with IM-properly set time, it will NOT keep time, and jumps at random, until the next NTP sync interval anyway, which can be set by the user on TNAP 4.0 and below.

In other words, it seems TNAP is partial to wanting to use Transponder time, no matter what changes we make so far...

[el bandido]

That sucks.

Observations: What I find especially interesting about this, even IF you have it set to only use NTP time, and set it to sync even in Standby, is IF you also have the Mio parked on a transponder with the proper time set, the time stays perfect.

Conversely, IF the same settings above, BUT, you have it parked on a transponder with IM-properly set time, it will NOT keep time, and jumps at random, until the next NTP sync interval anyway, which can be set by the user on TNAP 4.0 and below.

In other words, it seems TNAP is partial to wanting to use Transponder time, no matter what changes we make so far...

It is important to remember that these are Test Images.
Right now, It is better to have patience than to speculate.
Point in case: I have been running the MIO+ receiver in Standby since 11:48 AM this morning. The receiver is set to a channel on a dead transponder at 81w c band. The MIO+ was rebooted at 11;46 AM, and the correct time on the box was noted. Then the receiver was put into standby at 11:48 AM, and the Internet connection was removed from the wireless wifi the MIO+ is connected to. Current time on the MIo+ display is 14:14, which is the same time as my computer displays. This means my Mio+ is keeping correct time without a valid transponder and without an Internet connection. So we need to look carefully and see why other receivers are not doing the same when using the 8-22 image.

[el bandido]

Clock jumped ahead and date 1969 around an hour in so didn't fix it.
Time syncs happen at 30 minute intervals. Check the About page of the receiver, and verify 8-22 date for the image install. Check your settings and settings file. We are getting different results using the same image and need to find out why.

Thanks.

[Megatron817]

I got 8-22 I will do another flash without backup and set everthing up from scratch. I did auto restore last time but i'm sure the setting file was ok.

[Megatron817]

I'm not sure about how long the jump earlier was I had been outside when I came in the time had jumped. I'm all set back up now with 8-22 date image parked on cozi now in standby.

[Megatron817]

Time held for an hour then I turned it on and was messing and around. I had turned off the internet with the network adapters went from wireless to wired while watching Cozi the clock did change to transponder time and Cozi is some hours ahead but the date was right. Turned the adapter off and on again the internet time was set right. That would be how to sync the time it seems. Turn the adater off and on. Might have to do it a few times to get it to stick.

[Megatron817]

Sync trick with adapter on and off doesn't work at all with OpenPli 8.1 Keeps going back transponder time.So what ever changes you made to TNAP 4.1 EB, 4.1 is better.

[cyberham]

Saturday night I flashed TNAP 4.1 into a vacant slot. I did a complete installation without restoring anything from backup files. I scanned one satellite then left the receiver in Standby overnight. Sunday morning the clock seemed stable. So I online updated the Mio+ with all updates there. I spent Sunday morning scanning all satellites in the arc that I can see. I then configured my system back to normal including all channels, bouquets and even the Media Player with all playlists.

So far...since Saturday night, the Mio+ clock is boringly accurate whether the receiver is on, or in Standby, or after restarts. Not sure if it's the new software or perhaps the action of doing a completely clean install where all switches, etc. are reset to default that is responsible. No conclusions yet. But the champagne is being chilled as I type. And the receiver is in Standby.

[el bandido]

TNAP Is not built on the OpenPli 8.1 branch. So it is hard to compare the two images in some ways, but in other ways, they would be equal.

Shown below is the About page for the best time build for me so far.
Build date = 2021-08-22
Last update = 2021-08-22
Enigma version = 2021-08-21

17281

[cyberham]

...Added: what do you know! I enabled the HDMI-CEC menu on the receiver. Now when I restart the receiver, the TV picture comes on.
After doing the clean installation, I noticed HDMI pre-emphasis and HDMI-CEC menu access were OFF by default. My restart issue of the receiver not syncing to my TV after a restart returned. I changed HDMI pre-emphasis and HDMi-CEC menu access to ON. This resolved my restart issue and the TV display now always appears after any receiver restart.

My clock is still showing accurate date/time.

[el bandido]

Thanks it works well,
I have done the flashimage method successfully.:bigthumbup:

Ka blindscan, I can't find where it is?
I can't find the inversion when the LOF is above the search area.
KA-SAT search does not match KA LNBs


What is the make/model of your ka lnb?

Where can your ka lnb be purchased?

[stephan94]

Hello el bandido.
one LNB KA( D) is from Inverto, it is a KA / KU band LNB.
Unfortunately, this LNB is no longer available
[Only registered and activated users can see links]
The other is also a KA-SAT LNB from Inverto intended for programs with another frequency band.
which has been modified to receive KA (A)
[Only registered and activated users can see links]
it is for this modified LNB (Qarz is replaced by 27 MHz) that the inversion (as in C band) is important because the LOF is above the search zone
for my example LOF 20357 for zone 18200/19200

otherwise there are others (but much more expensive) from norsat
here for example
[Only registered and activated users can see links]
who additionally need a feedhorn which is not free.
[Only registered and activated users can see links]

[el bandido]

I will try to add this:
ka lnb 20357 l.o.
20357-950 = 19407
20357-2150 = 18207

[stephan94]

it would be great:yes1:

[cyberham]

Since I think I now have a clean install, I want to ask how I can do some PID edits on a tp. Today I learned that the DC Channel on 87W Ku no longer scans in. I'm told there is no longer a PAT table for this transponder.

The tp info is:
11760H
S/R 3.9787mb
D/R 5.5mb
VPID 1500
APID 1501
PMT ID 8191
PCR 1500
Service ID 5

[el bandido]

Let me know if there are any more problems with the time. This includes today, tomorrow or even next week. Thanks.

Dreamboxedit should allow the entry of pids. PIDS can also be manually entered but it can be time consuming. Try Dreamboxedit and see if it works.

[cyberham]

Let me know if there are any more problems with the time. This includes today, tomorrow or even next week....
I've had two instances of the date going to 1969 today. But this is different. The first case was when I was streaming via a link in my IPTV bouquet. The second just occurred now while I was watching a recorded show. It seems when not using the satellite function, the receiver gets pulled off its correct date/time for some reason. Otherwise, time has been accurate whether the receiver was on or in standby.

[el bandido]

Can you post a screenshot or clear picture of the About page? (Menu--->Information--->About)

Also, what is in /etc/default/ntpdate? You may use the Dream-Explorer plugin to see this file as shown. This file should be set to "yes"

17282

[cyberham]

See attached. It's set to "no". Should I change it?

[el bandido]

I think the hardware clock not being updated has caused most of the time issues in TNAP 4.1. You could change that to "yes", but it would be better to update correctly, else there may be problems or issues. The changes are in the feeds, but they cannot be "seen" by the receiver because the package versions are equal. So a flash is needed.

The latest image to Flash is 8-24-2021. Really all you need to do is put a fresh, known-to-be-good usb drive into the receiver, then select Flash image in receiver menus. Select a slot that has with backup and start the flash process. Do absolutely nothing else, and the image should flash, then restore your receiver. Usually this Flash & Restore takes 5-10 minutes, depending on what was installed in the receiver.
After the 8-24 image is installed, check and see if the rest of the time issues disappear. Verify the image is dated 8-24 in the About page of the receiver.

[el bandido]

it would be great:yes1:

Your KA lnb has been added to the image. Check and see that it works correctly.
We will try to add the KA lnb to blindscan if it works correctly in the image. Thanks.

17285<--------->17286


Flash the 8-24 image. Then test the new lnb setting for KA....

[stephan94]

Hello.
I see on your screenshot that it is for the MIO4KPlus
my Edision is a MIO4K
it also works?

[stephan94]

It works perfectly.
the frequencies are now correct.:yes1:
currently, as you said the blindscan is not working.

I also noticed that for this test the MIO4K
does not take into account what has been modified by the
TS Satellite editor plugin modified in KA band
The modifications are well stored in etc / enigma2 / satelittes.xml
but the receiver does not take into account this xml.
in KU no problem

[cyberham]

The latest image to Flash is 8-24-2021....
Monitoring.

[el bandido]

I also noticed that for this test the MIO4K
does not take into account what has been modified by the
TS Satellite editor plugin modified in KA band
The modifications are well stored in etc / enigma2 / satelittes.xml
but the receiver does not take into account this xml.
in KU no problem

Try to make the modifications again using TS satellite editor with the new lnb setting.
Blindscan will be next.

[stephan94]

Try to make the modifications again using TS satellite editor with the new lnb setting.
Blindscan will be next.
This is what I did .
I wanted to add the new frequencies after doing the tests
positive.
It was then that I realized that the changes
were not taken into account.

or do I have to redo a new flash?

[el bandido]

That sucks.

Observations: What I find especially interesting about this, even IF you have it set to only use NTP time, and set it to sync even in Standby, is IF you also have the Mio parked on a transponder with the proper time set, the time stays perfect.

Conversely, IF the same settings above, BUT, you have it parked on a transponder with IM-properly set time, it will NOT keep time, and jumps at random, until the next NTP sync interval anyway, which can be set by the user on TNAP 4.0 and below.

In other words, it seems TNAP is partial to wanting to use Transponder time, no matter what changes we make so far...

Most likely, Transponder time has nothing to do with the reported time issue because there is supposed to be some logic built into Transponder time which would keep the time from being reset or "Jumping". The receiver has an internal clock that is sometimes called a Real Time Clock (RTC) or Hardware Clock. If the internal clock is not set or updated, then it will give whatever time value is stored in it when called upon to give the time.

Setting the internal clock to update most likely fixed the remaining time issues. This is based on the observations of two people who took the time to provide some information about the problem, and test the changes. So I guess the time issue only effected two people or maybe they were the only ones interested in really fixing it???

Beginning with TNAP 4.1 and most likely any future versions TNAP, the time will be mostly automatic. Currently, Internet time will sync every 30 minutes, which is probably too much. My system runs fine with a time sync from the Internet every 24 hours or longer, providing the internal clock is updated. A restart or reboot of the receiver will also cause the time to sync with the Internet. Any additional time sync problems need to be reported, else the time sync is fixed and working.

Some changes need to be made in Blindscan and Positioner setup. Nothing else has been suggested to add or change. The Test Images will be removed once changes are made to Blindscan and Positioner setup.

[cyberham]

Do you stream video from m3u8 files or watch recorded video files via your Edision? If yes, do those actions still allow the Edision to always keep good time?

My Mio+ again started having erratic time. So Tuesday night I flashed the latest image and did not do an auto restore again. Back to scratch. I scanned in the satellites and channels. Nothing else was restored. My plan this time is to do nothing but watch satellite channels. I won't use any external editors, or stream video, or even record or watch videos. I want to keep a controlled environment. So far, clock seems fine though I don't watch it all the time. I will leave it like this for a week and work at a different hobby.

[MikeB]

Do you stream video from m3u8 files or watch recorded video files via your Edision? If yes, do those actions still allow the Edision to always keep good time?



Yes, and no, time can still can go random even with streaming, at least with TNAP 4.0.

I'm still running TNAP 4.0 though, and as long as it's set to use NTP time sync, it goes random whenever it likes. That's with hardwired internet, and nothing else in my house using NTP time goes random like this receiver does.

I simply can't figure out why it does this. I don't remember it ever happening with the original version of TNAP except when you had recording timers set, and changed to a different slot with a different image. (when you switched back to the image you set the timers in, they were all changed to like the year 2075. IIRC, it's posted here in the forum when it happened). BUT, this clock time drifting did start happening even before I loaded TNAP 4.0.

[el bandido]

Stream videos or do what else you normally would do with the receiver. Let's see if the time is fixed during streaming. Thanks.

[clucas]

Well, I hate to add my name to the time list but here's what happened to my MIO 4k today. I happened to walk by the receiver at about 4:40 AM and noticed it said :13. Then at about 12:50 the panel read something like 8:20. Both times about 4 1/2 hours off. I then changed to the transponder I wanted to record (with know correct transponder time) and the clock did not change so I turned if off and watched it. I have a daily timer set to start at 13:00 and about a minute before that the time corrected to 12:59 and it started to record at 13:00. Maybe the front display has nothing to do with clock used for recording? I'm just guessing.

[el bandido]

Well, I hate to add my name to the time list but here's what happened to my MIO 4k today. I happened to walk by the receiver at about 4:40 AM and noticed it said :13. Then at about 12:50 the panel read something like 8:20. Both times about 4 1/2 hours off. I then changed to the transponder I wanted to record (with know correct transponder time) and the clock did not change so I turned if off and watched it. I have a daily timer set to start at 13:00 and about a minute before that the time corrected to 12:59 and it started to record at 13:00. Maybe the front display has nothing to do with clock used for recording? I'm just guessing.

Post a screenshot, clear picture, or the contents of the About page in the receiver (Menu--->Information--->About). Thanks.

[clucas]

About an hour after it stopped recording I happened to look at the display and it was off about 4 1/2 hours again. It's not a problem since the timer worked perfectly.
17292

[el bandido]

Your image is too old and does not have all of the updates. Your image is dated 8-18, but needs to be 8-23 or higher.
Please Flash to 8-24 image and retest. Time problems should no longer exist in the 8-24 image if the receiver is set correctly. But if they do, we need to know about them and see if they can be fixed! Thanks.

17293

Check the About page after Flashing and verify it says 8-24 or 8-25 for a build date.

[clucas]

I appreciate you sending me the 8/18/21 TNAP 4.1 when I couldn't get my receiver to boot. I'll gladly update to a newer image but have some questions.

I looked all over the site but can't find a place where I can download the latest 8/24 version. Could you direct me to the area where the downloads are available? I'm guessing I have to use a USB stick with the file loaded or is there another way to do update it correctly?

A new image will overwrite all my LNB settings and scanned channels, won't it? Is there a way to download these and later restore them once the image is updated? The reason I ask is that I just read the DC feed at 11760 on 87W was able to be scanned so I did a blind transponder scan then scanned the transponder and moved it to my bouquet but it "greyed out" my LPB feed I had saved. It said the tuner was not configured. I did another blind transponder scan and this time 11760 did not show up but it corrected my LPB and now both are there. I feel I'm spending more time with updates and configurations rather than watching TV!

Oh, I saw you asking about a Ka LNB. I was doing a little research and posted a link on SatelliteGuys for Swedish Microwave ([Only registered and activated users can see links]) you may want to look at. You have to submit information for a quote so I'm sure it's not going to be cheap.

Carl

[el bandido]

Lots of times, testing images will be nothing more than one update after another. The words Test Image are put on the boot screen for a reason.

The image you want to flash is online and can be done automatically with settings, satellites, channels etc. restored automatically.

Here is a thread for online flashing: [Only registered and activated users can see links]

You may ask any questions about online flashing in that thread.

[cyberham]

...Tuesday night I flashed the latest image and did not do an auto restore again. Back to scratch. I scanned in the satellites and channels. Nothing else was restored. My plan this time is to do nothing but watch satellite channels. I won't use any external editors, or stream video, or even record or watch videos. I want to keep a controlled environment. So far, clock seems fine though I don't watch it all the time. I will leave it like this for a week...
I have watched satellite channels, played videos, done some recording and done a little streaming using Media Player. No clock jumps or inaccurate times have been seen. This light testing is not proof the issue is fixed, but it adds weight in support of this. I am going to avoid using external editors in future which, I think, can/may corrupt the Edision database files. I'm ready to receive the official release so I can finalize my installation and add bouquets. I look forward to any improvements in Positioner Setup which I use extensively with my USALS dish and Blind Scan.

[el bandido]

Setting the hardware clock to update probably fixed the remaining time issues. We will see...

The problem with editors is they may carry some problems forward. A lot of users do not realize or understand this. There is nothing wrong with editors, but when you have problems or issues, sometimes it is best to start clean. Loading a new image, then reinstalling the saved settings from any editor may carry forward problems or issues.

Now is the time to reload the original Dreamset files into the receiver. It will not hurt anything. Backup the whole image before you do this, or copy the entire enigma2 folder (located in /etc/enigma2) to your computer so it can be used as a restore point. Check for proper operation after reloading the Dreamset files.

More work needs to be done to make ka blindscan work. Positioner Setup needs a message added. There is not much left to do that is known about.

[el bandido]

There are over 10,000 .ipk packages in TNAP feeds as shown below. usually all of these packages are deleted from the server, then the new .ipk packages are uploaded when the feeds change. It doesn't always have to be done this way, but it usually is with TNAP images. In other words, updating the feeds takes a little bit of effort. More supported receivers = More feeds.

When you change or modify a file in the image, either the feeds need to be updated to reflect the changes, or a new image has to be uploaded. For some changes, a new image is uploaded and the 10,000+ .ipk feeds are deleted from the server and new ones uploaded. So making a change to one file is not the easiest thing to do, considering what all needs to be done in order to make the change usable for everyone that uses the image.

There is nothing more frustrating or aggravating than for someone to have a problem, then not follow through with testing the file changes to see that they work. Most things can be fixed if the problem is worked at long enough, but it is aggravating as hell to hunt for files that may have problems or make changes to files, then go through all of the steps needed to make the changes usable and have no one to test the changes or get no feedback on the changed files.

I realize that most fta users are limited in computer skills, but fta in North America is a "Do it Yourself" type hobby. And it is likely to get worse. Take a good look at some of the junk type appliance fta receivers that are being offered for sale in North America. Receives that have features or recovery procedures from 2005 are being offered. Parts of Enigma2 are open source, so we can change some of it. Appliance type receivers are closed source, Take a pick as to which one you want, but enigma2 receivers will perform no better in North America than the work or effort that is put into them.

17297

[clucas]

It's been almost two days and I check it randomly and my time seems to be accurate and holding after the 8/24/21 update of TNAP 4.1. I did the download and it flashed and updated the settings, which takes a while. I don't use any editors so don't have that issue to worry about.

Thanks, El Bandido for all the time and work you put into this and the individual help along the way.

[cyberham]

Just now, I was watching the clock, it jumped before my eyes. I changed from Standby to On and sure enough the date is 1969. Otherwise, it worked perfectly for 4 1/2 days.

Is it a coincidence that only today for the first time since flashing this image:
- I used Dreamset to read the database to my PC. Only read it. Didn't write to the Mio+. I can't see how this could hurt anything.
- I ftped using Filezilla an IPTV bouquet with some m3u8 links to etc/enigma2 folder on the Mio+. I probably shouldn't have done this.

Added: I compared the IPTV bouquet with a bouquet created by the Mio+. They are similar but the IPTV bouquet has a web URL. Perhaps this difference confused the Mio+. I have deleted the IPTV bouquet and will continue to monitor.

[el bandido]

Just now, I was watching the clock, it jumped before my eyes. I changed from Standby to On and sure enough the date is 1969. Otherwise, it worked perfectly for 4 1/2 days.

Is it a coincidence that only today for the first time since flashing this image:
- I used Dreamset to read the database to my PC. Only read it. Didn't write to the Mio+. I can't see how this could hurt anything.
- I ftped using Filezilla an IPTV bouquet with some m3u8 links to etc/enigma2 folder on the Mio+. I probably shouldn't have done this.

Added: I compared the IPTV bouquet with a bouquet created by the Mio+. They are similar but the IPTV bouquet has a web URL. Perhaps this difference confused the Mio+. I have deleted the IPTV bouquet and will continue to monitor.

I want you to be able to use this box any way you want without the time getting corrupted. Nothing you have done here should corrupt the time.
Let's fix it.
Open a telnet session and enter the following:
opkg update
opkg install util-linux
[Only registered and activated users can see links]
Reboot the box and continue operating the box the way you want to.

If you want to see the problem first:
Most likely you will have 67 or some other very low number stored in the hardware clock. This number Is Not Changing!
A hardware clock number of 67 = Thu Jan 01 1970 00:01:07 GMT+0000 Or for my timezone, it is: Wed Dec 31 1969 19:01:07 GMT-0500 (Eastern Standard Time). This was 52 years ago.
To see your hardware clock number, look in the file where it is stored. The file is called rtc. It is located in the fp folder at: /proc/stb/fp.
The rtc file should display the current time in unix. My rtc file currently has 1630292771 for the time. Reloading the rtc file will show an updated time...

Anyway, install the util-linux package, REBOOT and retest. Time problems will continue until the hardware clock is running. Installing the util-linux package will get your hardware clock running the way we have it set.. Be sure to reboot after installing this package. You may check your rtc file before and after installation to see the results...

[cyberham]

I followed this procedure. I didn't see the low number in rtc before or after because I had already rebooted previously and restored normal operation. My rtc is now 1630320545. I'll keep this in mind if the date/time go wrong.

[el bandido]

We were missing one package named util-linux-hwclock - 2.34-r0


You may check that this package is installed in any image by using the telnet command opkg list-installed.

[MikeB]

I want you to be able to use this box any way you want without the time getting corrupted. Nothing you have done here should corrupt the time.
Let's fix it.
Open a telnet session and enter the following:
opkg update
opkg install util-linux
[Only registered and activated users can see links]
Reboot the box and continue operating the box the way you want to.

If you want to see the problem first:
Most likely you will have 67 or some other very low number stored in the hardware clock. This number Is Not Changing!
A hardware clock number of 67 = Thu Jan 01 1970 00:01:07 GMT+0000 Or for my timezone, it is: Wed Dec 31 1969 19:01:07 GMT-0500 (Eastern Standard Time). This was 52 years ago.
To see your hardware clock number, look in the file where it is stored. The file is called rtc. It is located in the fp folder at: /proc/stb/fp.
The rtc file should display the current time in unix. My rtc file currently has 1630292771 for the time. Reloading the rtc file will show an updated time...

Anyway, install the util-linux package, REBOOT and retest. Time problems will continue until the hardware clock is running. Installing the util-linux package will get your hardware clock running the way we have it set.. Be sure to reboot after installing this package. You may check your rtc file before and after installation to see the results...


We were missing one package named util-linux-hwclock - 2.34-r0


You may check that this package is installed in any image by using the telnet command opkg list-installed.

My Mio also has this NTP time wandering issue, so I had changed to transponder time sync, which stays perfect. I'm also still running a slightly older version of TNAP 4.0 on my regular Mio. I checked, and didn't have the util-linux-hwclock file installed. So, I followed your instructions above, and just installed and rebooted. I changed my time settings back to grab time from NTP, and synced it, and saved the settings. My RTC clock now has this: 1630327898

I'll let you know how it goes.

[cyberham]

We were missing one package named util-linux-hwclock - 2.34-r0


You may check that this package is installed in any image by using the telnet command opkg list-installed.

This is good news. I do have that package.

[MikeB]

This is good news. I do have that package.

BUT, you didn't have it BEFORE installing the full Linux pack per EB's post, correct? I didn't have it before, and as you know, I also had the NTP time/date wandering issue.

Hope I don't jinx it, but so far since just before 9am this morning when I did this "fix", my NTP time and date has remained perfect, even with using SUSPEND mode, and not being on a transponder with perfect time. That looks good, because it likely would have gone wonky at least 3-4 times in that time period before this fix.

[cyberham]

BUT, you didn't have it BEFORE installing the full Linux pack per EB's post, correct?...
I don't know since I didn't know to check for the missing pack before installing the Linux pack. I did have a high rtc number (not 67) before installing. I'm going to re-install my IPTV bouquet now which I removed thinking it was a factor in my unstable clock. I feel confident the clock issue is resolved.

[el bandido]

It would most likely depend on when you last rebooted or re-started the receiver as to what number would have been stored in the hardware clock. The hardware clock was resetting to 0 on reboots...

We will see if the clock is fixed. Run or restore anything you want.

[Megatron817]

My test with util-linux-hwclock - 2.34-r0 installed looks good, Even had my hotspot turned off over night and the clock didn't jump. No startup service was used and time was set to internet (npt) and left on standby on a transponder with wrong time. I am now testing util-linux-hwclock package on OpenPli 8.1 and the internet time is now functioning correctly after syncing time by deactivating the network adapter then activating the network adapter. A reboot on Openpli 8.1 does not sync the time but with TNAP 4.1 the time will sync with a reboot or deactivating and activating the network adapter.

[el bandido]

This is the way it should run:

My test with util-linux-hwclock - 2.34-r0 installed looks good, Even had my hotspot turned off over night and the clock didn't jump. No startup service was used and time was set to internet (npt) and left on standby on a transponder with wrong time. I am now testing util-linux-hwclock package on OpenPli 8.1 and the internet time is now functioning correctly after syncing time by deactivating the network adapter then activating the network adapter. A reboot on Openpli 8.1 does not sync the time but with TNAP 4.1 the time will sync with a reboot or deactivating and activating the network adapter.

There are checks built-in the image to keep transponder time from varying by a large amount. it seems every location in the world has issues with transponders that do not give the precise time.

NTP time is supposed to have checks built in. If the ntp time cannot update, then nothing is supposed to happen.

The way it is set now, the hardware clock should update when ntp is successfully updated. This means we should have a good time value now in the hardware clock when the receiver needs to fall back on it.

NTP is set to sync every 30 minutes, and this value is not adjustable by the user in the receiver menus.

[el bandido]

A lot of Linux utilities were added. This makes the image a bit bigger.
There were only 2 linux utilities installed in TNAP 4.0
util-linux-mount cortexa15hf-neon-vfpv4 2.34-r0
util-linux-sulogin cortexa15hf-neon-vfpv4 2.34-r0

Here are the utilities we have now:
Some of these, or even most of these utilities could be deleted. Some sort of a decision need to be made about these. We really need to only add the hwclock utility shown in red, but some of these extra utilities could be useful.
util-linux armv7vehf-neon-vfpv4 2.34-r0
util-linux-addpart armv7vehf-neon-vfpv4 2.34-r0
util-linux-agetty armv7vehf-neon-vfpv4 2.34-r0
util-linux-blkdiscard armv7vehf-neon-vfpv4 2.34-r0
util-linux-blkid armv7vehf-neon-vfpv4 2.34-r0
util-linux-blkzone armv7vehf-neon-vfpv4 2.34-r0
util-linux-blockdev armv7vehf-neon-vfpv4 2.34-r0
util-linux-cal armv7vehf-neon-vfpv4 2.34-r0
util-linux-cfdisk armv7vehf-neon-vfpv4 2.34-r0
util-linux-chcpu armv7vehf-neon-vfpv4 2.34-r0
util-linux-chmem armv7vehf-neon-vfpv4 2.34-r0
util-linux-choom armv7vehf-neon-vfpv4 2.34-r0
util-linux-chrt armv7vehf-neon-vfpv4 2.34-r0
util-linux-col armv7vehf-neon-vfpv4 2.34-r0
util-linux-colcrt armv7vehf-neon-vfpv4 2.34-r0
util-linux-colrm armv7vehf-neon-vfpv4 2.34-r0
util-linux-column armv7vehf-neon-vfpv4 2.34-r0
util-linux-ctrlaltdel armv7vehf-neon-vfpv4 2.34-r0
util-linux-delpart armv7vehf-neon-vfpv4 2.34-r0
util-linux-dmesg armv7vehf-neon-vfpv4 2.34-r0
util-linux-eject armv7vehf-neon-vfpv4 2.34-r0
util-linux-fallocate armv7vehf-neon-vfpv4 2.34-r0
util-linux-fdformat armv7vehf-neon-vfpv4 2.34-r0
util-linux-fdisk armv7vehf-neon-vfpv4 2.34-r0
util-linux-fincore armv7vehf-neon-vfpv4 2.34-r0
util-linux-findfs armv7vehf-neon-vfpv4 2.34-r0
util-linux-findmnt armv7vehf-neon-vfpv4 2.34-r0
util-linux-flock armv7vehf-neon-vfpv4 2.34-r0
util-linux-fsck armv7vehf-neon-vfpv4 2.34-r0
util-linux-fsck.cramfs armv7vehf-neon-vfpv4 2.34-r0
util-linux-fsfreeze armv7vehf-neon-vfpv4 2.34-r0
util-linux-fstrim armv7vehf-neon-vfpv4 2.34-r0
util-linux-getopt armv7vehf-neon-vfpv4 2.34-r0
util-linux-hardlink armv7vehf-neon-vfpv4 2.34-r0
util-linux-hexdump armv7vehf-neon-vfpv4 2.34-r0
util-linux-hwclock armv7vehf-neon-vfpv4 2.34-r0
util-linux-ionice armv7vehf-neon-vfpv4 2.34-r0
util-linux-ipcmk armv7vehf-neon-vfpv4 2.34-r0
util-linux-ipcrm armv7vehf-neon-vfpv4 2.34-r0
util-linux-ipcs armv7vehf-neon-vfpv4 2.34-r0
util-linux-isosize armv7vehf-neon-vfpv4 2.34-r0
util-linux-kill armv7vehf-neon-vfpv4 2.34-r0
util-linux-last armv7vehf-neon-vfpv4 2.34-r0
util-linux-ldattach armv7vehf-neon-vfpv4 2.34-r0
util-linux-logger armv7vehf-neon-vfpv4 2.34-r0
util-linux-look armv7vehf-neon-vfpv4 2.34-r0
util-linux-losetup armv7vehf-neon-vfpv4 2.34-r0
util-linux-lsblk armv7vehf-neon-vfpv4 2.34-r0
util-linux-lscpu armv7vehf-neon-vfpv4 2.34-r0
util-linux-lsipc armv7vehf-neon-vfpv4 2.34-r0
util-linux-lslocks armv7vehf-neon-vfpv4 2.34-r0
util-linux-lslogins armv7vehf-neon-vfpv4 2.34-r0
util-linux-lsmem armv7vehf-neon-vfpv4 2.34-r0
util-linux-lsns armv7vehf-neon-vfpv4 2.34-r0
util-linux-mcookie armv7vehf-neon-vfpv4 2.34-r0
util-linux-mesg armv7vehf-neon-vfpv4 2.34-r0
util-linux-mkfs armv7vehf-neon-vfpv4 2.34-r0
util-linux-mkfs.cramfs armv7vehf-neon-vfpv4 2.34-r0
util-linux-mkswap armv7vehf-neon-vfpv4 2.34-r0
util-linux-more armv7vehf-neon-vfpv4 2.34-r0
util-linux-mount armv7vehf-neon-vfpv4 2.34-r0
util-linux-mountpoint armv7vehf-neon-vfpv4 2.34-r0
util-linux-namei armv7vehf-neon-vfpv4 2.34-r0
util-linux-nologin armv7vehf-neon-vfpv4 2.34-r0
util-linux-nsenter armv7vehf-neon-vfpv4 2.34-r0
util-linux-partx armv7vehf-neon-vfpv4 2.34-r0
util-linux-pivot-root armv7vehf-neon-vfpv4 2.34-r0
util-linux-prlimit armv7vehf-neon-vfpv4 2.34-r0
util-linux-raw armv7vehf-neon-vfpv4 2.34-r0
util-linux-readprofile armv7vehf-neon-vfpv4 2.34-r0
util-linux-rename armv7vehf-neon-vfpv4 2.34-r0
util-linux-renice armv7vehf-neon-vfpv4 2.34-r0
util-linux-resizepart armv7vehf-neon-vfpv4 2.34-r0
util-linux-rev armv7vehf-neon-vfpv4 2.34-r0
util-linux-rfkill armv7vehf-neon-vfpv4 2.34-r0
util-linux-rtcwake armv7vehf-neon-vfpv4 2.34-r0
util-linux-runuser armv7vehf-neon-vfpv4 2.34-r0
util-linux-script armv7vehf-neon-vfpv4 2.34-r0
util-linux-scriptreplay armv7vehf-neon-vfpv4 2.34-r0
util-linux-setarch armv7vehf-neon-vfpv4 2.34-r0
util-linux-setpriv armv7vehf-neon-vfpv4 2.34-r0
util-linux-setsid armv7vehf-neon-vfpv4 2.34-r0
util-linux-setterm armv7vehf-neon-vfpv4 2.34-r0
util-linux-sfdisk armv7vehf-neon-vfpv4 2.34-r0
util-linux-su armv7vehf-neon-vfpv4 2.34-r0
util-linux-sulogin armv7vehf-neon-vfpv4 2.34-r0
util-linux-swaplabel armv7vehf-neon-vfpv4 2.34-r0
util-linux-swapoff armv7vehf-neon-vfpv4 2.34-r0
util-linux-swapon armv7vehf-neon-vfpv4 2.34-r0
util-linux-switch-root armv7vehf-neon-vfpv4 2.34-r0
util-linux-taskset armv7vehf-neon-vfpv4 2.34-r0
util-linux-ul armv7vehf-neon-vfpv4 2.34-r0
util-linux-umount armv7vehf-neon-vfpv4 2.34-r0
util-linux-unshare armv7vehf-neon-vfpv4 2.34-r0
util-linux-utmpdump armv7vehf-neon-vfpv4 2.34-r0
util-linux-uuidd armv7vehf-neon-vfpv4 2.34-r0
util-linux-uuidgen armv7vehf-neon-vfpv4 2.34-r0
util-linux-uuidparse armv7vehf-neon-vfpv4 2.34-r0
util-linux-wall armv7vehf-neon-vfpv4 2.34-r0
util-linux-wdctl armv7vehf-neon-vfpv4 2.34-r0
util-linux-whereis armv7vehf-neon-vfpv4 2.34-r0
util-linux-wipefs armv7vehf-neon-vfpv4 2.34-r0
util-linux-write armv7vehf-neon-vfpv4 2.34-r0
util-linux-zramctl armv7vehf-neon-vfpv4 2.34-r0

[MikeB]

BUT, you didn't have it BEFORE installing the full Linux pack per EB's post, correct? I didn't have it before, and as you know, I also had the NTP time/date wandering issue.

Hope I don't jinx it, but so far since just before 9am this morning when I did this "fix", my NTP time and date has remained perfect, even with using SUSPEND mode, and not being on a transponder with perfect time. That looks good, because it likely would have gone wonky at least 3-4 times in that time period before this fix.

Well, mine held out pretty good, BUT, I just caught it jumping time again. I'm still running TNAP 4.0, and I have NTP time set to sync at 5 minute intervals, and it did that. Real time was 18:54, and when I looked up, the clock was suddenly at 20:00. It must have been that way for over 4 minutes, because I didn't have enough time to turn it on out of Suspend mode, to check what actual date that was with.

Also, my RTC seems to be updating by itself, (as seen in the root / proc / stb / fb folder file called RTC) BUT, it no longer has the full Unix countdown time & date from 1970 as it did right after I did the full linux file update. Right now at 19:01, it has: 90487 as the time stamp?

Hopefully it'll stay well after I upgrade to TNAP 4.1, which will be after it's a release candidate.

17298

[el bandido]

Your hardware clock is not being updated.

Here is the epoch time converter: [Only registered and activated users can see links]

Here is time 90487:
GMT: Friday, January 2, 1970 1:08:07 AM
Your time zone: Thursday, January 1, 1970 8:08:07 PM GMT-05:00
Relative: 52 years ago

Here is time 0
GMT: Thursday, January 1, 1970 12:00:00 AM
Your time zone: Wednesday, December 31, 1969 7:00:00 PM GMT-05:00
Relative: 52 years ago

Most likely, you rebooted the box about one day ago, and something just happened to make the receiver fall back on the hardware clock. Most likely, your hardware clock is not being set or synced with ntp.

Trying to fix the 4.0 version for everyone using the image is not a good idea because something else may get broken in the process. Either upgrade to the test image or wait a few more days until testing is completed.

If you want to continue working with the 4.0 image, enter this telnet command hwclock --systohc || :, then see what the hardware clock reports.
[Only registered and activated users can see links]
[Only registered and activated users can see links]

[MikeB]

Your hardware clock is not being updated.

Here is the epoch time converter: [Only registered and activated users can see links]

Here is time 90487:
GMT: Friday, January 2, 1970 1:08:07 AM
Your time zone: Thursday, January 1, 1970 8:08:07 PM GMT-05:00
Relative: 52 years ago

Here is time 0
GMT: Thursday, January 1, 1970 12:00:00 AM
Your time zone: Wednesday, December 31, 1969 7:00:00 PM GMT-05:00
Relative: 52 years ago

Most likely, you rebooted the box about one day ago, and something just happened to make the receiver fall back on the hardware clock. Most likely, your hardware clock is not being set or synced with ntp.

Trying to fix the 4.0 version for everyone using the image is not a good idea because something else may get broken in the process. Either upgrade to the test image or wait a few more days until testing is completed.

If you want to continue working with the 4.0 image, enter this telnet command hwclock --systohc || :, then see what the hardware clock reports.
[Only registered and activated users can see links]
[Only registered and activated users can see links]



I don't have any problem waiting for the full release of 4.1. I've waited this long after all.

What key symbols are those 'bar' type characters after --systohc in that command? Are those Forward Slashes, or (lowercase) L's

[el bandido]

Just copy and paste it....:th_thumbs20up:

[MikeB]

Just copy and paste it....:th_thumbs20up:

DUH, me, lol. Ok, here's what rtc file is showing now: 1630440318

Local time right now is: 8:05pm

Checked again, and the full unix time seems to be holding. 8:10pm it says = 1630440600

Ok, I just realized that it was running the wrong local time offset (4 hours), so I ran the command: hwclock -w -u and it's now showing the proper offset from UTC time.

Right now it's: 1630455913 which translates to: Tue Aug 31 2021 20:25:13 GMT-0400 (Eastern Daylight Time)

SUCCESS! It seems to be holding. Thanks again EB, I'll continue to monitor and let you know.

[el bandido]

The feeds will no longer work unless the image is Flashed to 8-31-2021. The reason for this is a kernel update to 5.14.
The feeds will work once the 08-31 is flashed in the receiver. Flashing online is easy and automatic. Instructions on how to do this were posted earlier in this thread.

We want to get all of this juggling or changing of the feeds done. A lot of the updates have been efforts to fix the time. But all of these updates to the feeds will wreck a receiver for the inexperienced user as we have already seen.

The amount of image packages that can be downloaded in a single update have been set to 80. Anything over 80 packages in a receiver update should require the user to Flash a new image in order to update. This was also done to help inexperienced users or users that are not paying attention from getting stuck in a bootloop.

17299

17300<------------->17301

These online images have been tested to load and boot....

[stephan94]

Hello el bandido

Do we know what kernel 5.14 brings or improves?


have a good day

[MikeB]

DUH, me, lol. Ok, here's what rtc file is showing now: 1630440318

Local time right now is: 8:05pm

Checked again, and the full unix time seems to be holding. 8:10pm it says = 1630440600

Ok, I just realized that it was running the wrong local time offset (4 hours), so I ran the command: hwclock -w -u and it's now showing the proper offset from UTC time.

Right now it's: 1630455913 which translates to: Tue Aug 31 2021 20:25:13 GMT-0400 (Eastern Daylight Time)

SUCCESS! It seems to be holding. Thanks again EB, I'll continue to monitor and let you know.

Ok, NTP time is holding rock-steady now. The RTC is holding solid with the full Unix time code, and hasn't missed a beat since I ran the above codes. Even while in Standby mode.

Right now it's: 1630549772 which translates as: Wed Sep 01 2021 22:29:32 GMT-0400 (Eastern Daylight Time)

[MikeB]

Ok, NTP time is holding rock-steady now. The RTC is holding solid with the full Unix time code, and hasn't missed a beat since I ran the above codes. Even while in Standby mode.

Right now it's: 1630549772 which translates as: Wed Sep 01 2021 22:29:32 GMT-0400 (Eastern Daylight Time)

Well, it held out well in Suspend mode, it kept the FULL unix time, and updated as it needed in the hardware clock like it should. Then I turned the receiver on, and tried to use it, but it acted like it couldn't connect to the lnbf/receive any signal. So I then did a full reboot... It went back to just having 4 character time codes in there for some reason.

I re-ran the hwclock commands I ran earlier, and it reloaded FULL time again.

I'm going to LEAVE the receiver ON full now, and see what happens from there. Likely I'll be loading TNAP 4.1 sooner than later, once the release candidate comes out. Maybe even doing a full scratch setup with that, so no "ghosts" in setup files can cause issues.

[Megatron817]

Well, it held out well in Suspend mode, it kept the FULL unix time, and updated as it needed in the hardware clock like it should. Then I turned the receiver on, and tried to use it, but it acted like it couldn't connect to the lnbf/receive any signal. So I then did a full reboot... It went back to just having 4 character time codes in there for some reason.

I re-ran the hwclock commands I ran earlier, and it reloaded FULL time again.

I'm going to LEAVE the receiver ON full now, and see what happens from there. Likely I'll be loading TNAP 4.1 sooner than later, once the release candidate comes out. Maybe even doing a full scratch setup with that, so no "ghosts" in setup files can cause issues.

Once 4.1 official is out go ahead and auto restore then go in and save your settings file from etc/enigma2 and delete those lines EB listed early on in this thread and reload the settings file.Remember to telnet init 4 send the setting file to etc/ enigma2 and then telnet init 3.
I don't think you will have any issues plus it will be alot faster than a full setup from scatch.

[el bandido]

Well, it held out well in Suspend mode, it kept the FULL unix time, and updated as it needed in the hardware clock like it should. Then I turned the receiver on, and tried to use it, but it acted like it couldn't connect to the lnbf/receive any signal. So I then did a full reboot... It went back to just having 4 character time codes in there for some reason.

I re-ran the hwclock commands I ran earlier, and it reloaded FULL time again.

I'm going to LEAVE the receiver ON full now, and see what happens from there. Likely I'll be loading TNAP 4.1 sooner than later, once the release candidate comes out. Maybe even doing a full scratch setup with that, so no "ghosts" in setup files can cause issues.

Maybe the time problem is seen clearly now? TNAP 4.1 runs the hwclock commands automatically, so that along with some other changes should fix the time. No dramatic steps for any user besides sticking a good usb stick in the receiver and updating the receiver to TNAP 4.1 should be needed.

It is a good idea to do a fresh install in enigma2 receivers anytime you have a problem that cannot be seen. Lots of things can end up in a settings file over a period of time. Bouquets and channel files usually do not give any problems when used for long periods of time, but the settings file can cause issues if wrong or bad entries are in it. It is rare that anything in a settings file from DreamBoxEdit, Dreamset...etc causes an issue, but it does happen. So removing those files first when there is a problem and performing a clean install is a good idea. These files can always be installed or restored once it is proven the problem or issue is not in them.

I would say that we can consider the time issue solved for now in current versions of TNAP 4.1. We can start looking at other things such as the missing start-up files and move the image out of testing soon.

[clucas]

Once 4.1 official is out go ahead and auto restore then go in and save your settings file from etc/enigma2 and delete those lines EB listed early on in this thread and reload the settings file.Remember to telnet init 4 send the setting file to etc/ enigma2 and then telnet init 3.
I don't think you will have any issues plus it will be alot faster than a full setup from scratch.

Just reporting that my time has been fine with the 8/24 update on my MIO 4k.

This telnet thing, I recently saved my etc/enigma2 folder to my iMac just by looking at the drives that are on my network (the MIO shows up just like any other computer hard drive) and doing a copy from the MIO and pasted it to my computer. I trust it will work the other way if I have to restore the files. Are PC's able to do this too? It saves starting another program and putting in all those commands.

[el bandido]

Information on the time is appreciated!

Both Linux and Windows PC's can do the same thing.To restore the files from the saved enigma2 folder, you need telnet and enter init 4 to stop enigma2, then transfer the files. Use init 3 in telnet to wake the receiver up after re-installing the files.

[MikeB]

Just reporting that my time has been fine with the 8/24 update on my MIO 4k.

This telnet thing, I recently saved my etc/enigma2 folder to my iMac just by looking at the drives that are on my network (the MIO shows up just like any other computer hard drive) and doing a copy from the MIO and pasted it to my computer. I trust it will work the other way if I have to restore the files. Are PC's able to do this too? It saves starting another program and putting in all those commands.

YES, copying back and forth also works fine with a regular pc. through File Manager However, three caveats (NOTE: make a backup before messing with files!):

1: Make SURE you don't accidentally drag a folder or file away from where it belongs, and into another folder. I had that happen on my old laptop, (with the init.d folder) that had a touchy trackpad. It bricked my receiver temporarily, and I had to restore it.

2: IF you copy/edit (with Notepad++ software)/copy back any files, you MUST restart the receiver for it to re-read the changes from the file. Sometimes just restarting Enigma is good enough, but not always.

3: Don't live-edit files while they are still on the receiver, it may go South on you. Make a copy of the file on your computer, and edit THAT. If you suddenly have something go wrong while editing, you didn't ruin the original file live on the Mio at that point.

[el bandido]

Test images have been removed from feeds and Flash image.
17306

NOW is a good time to destroy all Test images for TNAP 4.1 as they are no longer needed.

[Megatron817]

Looks nice. The about page still shows Test image. I installed no T2mi driver, now shows based on OpenPli.

[stephan94]

:yes1:

[el bandido]

Work will continue on adding the Ka lnb to blindscan.

Enigma2 images are only as good as the efforts that are put into them!

Thanks to all that participated in the discussions and efforts to make fta a tad bit better in North America.

Tnap 4.1 disucussions will be >>HERE<<.