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

[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.

 

[el bandido]

Your hardware clock is not being updated.

Here is the epoch time converter: https://www.epochconverter.com/

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.
root@osmio4kplus:~# hwclock --systohc || :
root@osmio4kplus:~#

 

[MikeB]

Your hardware clock is not being updated.

Here is the epoch time converter: https://www.epochconverter.com/

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.
root@osmio4kplus:~# hwclock --systohc || :
root@osmio4kplus:~#

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.



<------------->

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.