I have noticed that I didn’t push the OC fixes for the N2 yesterday so they are not in the current nightly. Just FYI @Sholander and anyone else using OC.
Next one tomorrow will have it.
I knew that you’d forget, so did not download today’s nightly 
There is no 4.x kernel version for the C2, the problem with your dvb adapter is probably down to the crazycat drivers, if you had reported when it was working then we could have corrected it when it stopped working but as neither you nor us know due to the fact nobody said anything then we can’t help with this issue.
Nightly version was created so users could help us with testing our latest changes and was not created for users to find a version that they are comfortable with and then stick with it.
I’m sorry if you nor anyone else is unhappy with it but if you have a problem then I suggest you install one of our stable releases as these do not have forced updates and you are free to use whatever version you want.
I agree with @TheCoolest.
What would be draconian is if we enforced this on Stable builds which we do not, so please do not spread such fud.
If you install our nightly image then you are 100% correct here, this is explained on our download page and you accept this when you install CE nightlies.
Not true, we encourage users who disagree with our decisions to let us know as long as it is done constructively, we do listen to feedback.
99% of users are okay with forced updates on nightly and respect our decision on this and understand our reasoning behind it.
You are free to compile CoreELEC yourself if you don’t want your device to update, we would of even helped you to do this or you could have just waited for a stable release.
At the end of the day you don’t have to use our builds, there is other options available if you don’t like how we operate, sorry to see you go 
.
2 Likes
We are considering some slight changes to the update policy for nightlies.
If an update is available then the user will be prompted every 6 hours if they would like to download it.
This would give users an element of control over the nightlies, we recognise it may be appropriate to delay updating ie to test an older nightly or prevent updating to a bad update.
We are also looking at adding a prompt to reboot when updates are downloaded if users want it to make life just that little easier 
7 Likes
I have noticed that detection of SAT > IP sources in Tvheadend has become very erratic recently. After an update it takes at least two reboots to get TVheadend to detect my SAT > IP box, and the latest nightly took about 10 reboots before it found it. This maybe a problem localized to the TVheadend addon rather than Coreelec itself.
Its an issue because other users than myself simply report things not working if things crash or need a reboot.
What do I need to supply to get to the bottom of this ?
Shoog
I never had problems detecting my tuner SAT>IP Telestar Digibit R1. Tested with CoreELEC + Mecool KIII Pro and AlexELEC + H96 Pro+. I do not like nightly versions, I always use stable versions.
These are my settings in the ‘SAT> IP’ tuner:
- miniDLNA server: disabled
- SAMBA server: disabled
- RTSP multicast: disabled
Configuration of tvheadend server:
Tuners
- Initial scan = off
- Idle scan = off
Networks
- Network discovery = off
- Skip startup scan = on
- Idle scan muxes = off
It seems that this is a known issue with TVH, what seems to be happening is that at boot the TVH server looks for the SAT > IP and if for some reason it fails to find it, it waits a full hour before looking again. There might be fixes (such as delaying the start of TVH).
I just wonder why in the last nightly the issue seems to have gotten a lot worse. The only thing I can observe is that TVH is very slow to start up and maybe seems to be getting slower.
Shoog
Why are all my posts deleted? Including my opinion on forces update. They weren’t off topic. Why weren’t they at least moved?
Version 20190605/20190606 again works “fine”. Only TVheadend often reports various discontinuity, invalid checksum, Continuity counter error and Transport error
This commit work maybe only for DVB-T, but no for DVB-T2
If you can’t me here, just write
@Temsor, thread was cleaned for off-topic messages(So nothing personal if your messages were cleaned too)
If you have an issue than please don’t forget to collect and attach logs, as I see you ignored this request previous time.
Without logs nobody knows about what happening on your system
https://discourse.coreelec.org/t/how-to-report-an-issue-youre-having-with-coreelec/3022/4
If it seems good, the time can be left in 2 or 3 minutes, which is the time it takes for my tvheadend server to recognize my SAT> IP tuner when the tuner is initially turned off. Check the configuration of your tvheadend server and do not overload it with tasks if you only have one or two tuners.
This indicates lost of packets transfered from USB stick. Most likely your box is heavy loaded with other tasks. Internal tuner have HW support for data transfer offloading CPU. For USB tuners all have to be done by SW.
I will investigate.
However in my digging I found various references to TVH using UPnP to initialize its connection to the SAT>IP and this is incompatible with fixed IP addresses on the SAT>IP. I have my SAT>IP using a fixed IP so this will be the next thing I try removing it from the fixed IP.
Shoog
Do not investigate much, the best configuration of a server in a private network is assigning a fixed IP address from the router’s DHCP server.
Ok, seems that a static IP address was the problem. Since taking it off it has found the SAT>IP after an upgrade and another reboot subsequently.
Shoog
Its bug on TVH side then? I guess you would saw, if there would be new need to fill static IP @TVH interface… TVH authors usually responds very well.
Its not a bug as such, its a feature of how it finds SAT > IP tuners using UPnP and setting a fixed IP upsets that discovery method. Its not documented over there but it is mentioned in a few of the bug reports that it has generated for users.
Shoog
Latest nightly has broken SAT>IP again. Going to have to revert.
Shoog
Nothing changed that could cause this. We are at stabilization phase.