I don't have KU at present, so I'm not sure which ones would or wouldn't have proper time reference, sorry. Though IF you are set to only sync to Transponder time, and are watching a channel live and time starts going wonky, that's a good indication.How do I know if a tp doesn't have proper time? I only have Ku.
Sent from my SM-G950W using Tapatalk
I recommend anybody having a clock issue with TNAP, to flash the latest available TNAP 4.1 in a vacant slot, and DON'T restore any old files. DON'T do auto restore. Scan all satellites and channels fresh. Create new bouquets. I did this and my clock appears stable whether the receiver is on or in Standby. It has been like this since Saturday night.So far, the clock seems stable. I'm proceeding to scan in fresh all satellites across the arc. I won't restore any old files (settings, channels, bouquets).
I might give this another stab but I don't intend to spend a lot of time trying to make it work.I recommend anybody having a clock issue with TNAP, to flash the latest available TNAP 4.1 in a vacant slot, and DON'T restore any old files. DON'T do auto restore. Scan all satellites and channels fresh. Create new bouquets. I did this and my clock appears stable whether the receiver is on or in Standby. It has been like this since Saturday night.
I'm not flashing any images that aren't release versions. I'm still on 4.0, and now using a hybrid of transponder time with Bars & Tone as a startup service/parking channel, and NTP time otherwise, and it works perfect for me.I might give this another stab but I don't intend to spend a lot of time trying to make it work.
I'm not 100% sure about that. The times I've actually seen mine go off, as opposed to finding it later, it's reset to January 1, 1970. That's T=0 for Unix systems. Maybe there are a lot of transponders broadcasting that, I have no idea. It's been years since I looked at the time broadcast on any satellites, but when I did, most of them seemed to just be their local time rather than UTC.The reason time goes wonky on some peoples TNAP when set to NTP time AND using standby mode, is because for some reason, TNAP WANTS to sync to transponder time over NTP time. So, when on a channel/transponder with the wrong time, it'll wander off all by itself at intervals.
That can happen if you lose signal. Was it a regular satellite channel, or an IP channel recording? I've had it happen on an IP channel also, when there was a stream glitch/hesitation. It won't restart actual recording after the glitch/hesitation, though it'll keep looking like it's still recording.Not only do I have clock issues but I have one receiver that makes unreliable recordings. I sat here and watched the record indicator continue for the entire length of the program but only 600 bytes was recorded. I can fix most problems by rebooting the receiver just prior to the beginning of the record time. The other receiver seems to record OK. I once thought the osmio was a nice receiver but I no longer feel that way.
Remember, keep at least ONE other working image in a different slot. Makes it easier to restore, IF something happens to your main image. Also, nothing says you can't put the same image in multiple slots... You could have 4 cloned slots for that matter.Then I will install and delete all former images of TNAP.
That's good to hear. Not looking forward to a complete new setup of everything from scratch, BUT, if it works, guess it'll have to be done.I tried my best but I couldn't "break" TNAP 4.1 2021-08-24 Test Image regarding the date/time issue.
Will put the same new image in a couple of other slots. A complete setup from scratch isn't so bad. It provides an opportunity to update each satellite and channel listing.Remember, keep at least ONE other working image in a different slot.
Good point, and it's not as if it'll be my first time, or learning the receiver for the first time. If the newest image is fairly bug-free, that makes it all the better.A complete setup from scratch isn't so bad. It provides an opportunity to update each satellite and channel listing.
Regular sat channel. H&I East AND ABC. I have a workaround in place by creating cron jobs that reboot the receiver 5 minutes prior to the recording which seems to have "fixed" the problem.That can happen if you lose signal. Was it a regular satellite channel, or an IP channel recording? I've had it happen on an IP channel also, when there was a stream glitch/hesitation. It won't restart actual recording after the glitch/hesitation, though it'll keep looking like it's still recording.
If it was a satellite channel, make sure that channel is 100% working live as you are watching it. Maybe there's something going on there with switches, etc.
E-Channelizer. Works perfect and has for me. DBE corrupted my lamedb. Jenseneverest over on linuxsat suggested E-Channelizer a couple of years ago. Using the free version and no hitches whatsoever.I tried my best but I couldn't "break" TNAP 4.1 2021-08-24 Test Image regarding the date/time issue. After I loaded this image from scratch without importing any old satellites, channels or bouquets, it has worked perfectly. My time has been perfect for 3 1/2 days which exceeds any previous version. The only thing I won't try anymore is using an external editor to modify the Edision channels database. I have no proof but I'm suspicious of both Dreamset and DreamBoxEdit. I find I don't really need them anyway. I'm waiting for the official migration of this Test Image to a release. Then I will install and delete all former images of TNAP.
NTP time hasn't worked perfect for many of us since mid-TNAP 3.x. El Bandido thinks he now may have it fixed in TNAP 4.1, but that isn't a full release candidate just yet.If NTP time works perfect why do people insist on using tp time?
Not ruffling feathers. El is a good dude. It just must be a tnap thing because openatv is and has been perfect here.NTP time hasn't worked perfect for many of us since mid-TNAP 3.x. El Bandido thinks he now may have it fixed in TNAP 4.1, but that isn't a full release candidate just yet.
el bandido;102311 said: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
The telnet screen should look similar to this: root@osmio4kplus:~# opkg install util-linux
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...
el bandido;102313 said: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;102314 said: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.
TNAP 4.0 osmio4k
osmio4k login: root
Last login: Mon Aug 30 15:57:09 EDT 2021 on pts/0
root@osmio4k:~#
We use cookies and similar technologies for the following purposes:
Do you accept cookies and these technologies?
We use cookies and similar technologies for the following purposes:
Do you accept cookies and these technologies?