Yes, as time moves on, support for older operating systems are dropped. Certainly for operating systems that are no longer supported by their vendors.
Does this mean they will immediately stop working? No, we don’t do anything to prevent them from working. But we don’t do anything to keep them working.
Your suggestion is good and it’s exactly what we plan on doing in the future.
You can always see what our supported versions are on our website.
Linux provides a different set of hassles. To expect somone that can't deal with the upgrade from Windows 7 to Windows 10 to be able to move to Linux is totally unrealistic.
As a developer you should be well aware of the complexities of regression testing. It is quite reasonable to stop supporting and testing on obsolete systems. Furthermore, the security risks of running these old systems should not be encouraged and continuing to support encourages this unsafe behaviour.
Furthermore, it dose not make business sense to invest in supporting those that fail to meet minimum requirements.
We are a team of three that manage two entirely separate app codebases that are distributed through three different app stores, each with two different presentations between TV and hand-held, with many different size classes for all of them across multiple OS versions and minor updates for tens or hundreds of different devices with their own quirks.
On top of that, we have a DVR codebase that runs across six different hardware architectures for five different Operating Systems and eight different NAS platforms. Those Operating Systems all have many versions that the DVR can run under, many of which have their own quirks.
The situation that we're running into today is the fallout of fixing a performance issue in our Tailscale integration on Windows. We worked with the Tailscale team to identify the issue and they were able to mitigate it, which required that we updated to a new version of their library. They made the decision to target Go 1.21 in the latest version, which required us to do the same. The Go team had decided to end support for Windows 7 in Go 1.21 due to Microsoft, Chrome, etc. no longer supporting this generation of Operating System. At the time of us making this change a few weeks ago, we were not aware of this change and the implications it would or wouldn't have.
Generally when we have changes like this in a pre-release for a few weeks, it is long enough to surface any issues across our customer base that would prevent us from shipping this more widely. It's clear that in this case, none of our customers running Windows 7 were active on this site or downloading pre-releases, so no one was aware of this issue.
We're continuing to work to figure out a solution to this immediate issue within the bounds of the options and tools we have available to us.
And, just to repeat this again. This happened on operating systems that we don’t support and never gave guarantees for Channels DVR Server working on.
We believe we have a workaround to get people on Windows 7 back up-and-running. We have built a new build of the build from November that has a recent build number which will prevent it from trying to update to the Stable release that recently came out.
To use it:
C:\ProgramData\ChannelsDVR\latest\channels-dvr.exe to C:\ProgramData\ChannelsDVR\latest\channels-dvr-prev.exe
channels-dvr.exe-windows-x86_64 to C:\ProgramData\ChannelsDVR\latest\channels-dvr.exe
This should have the DVR running reporting version 2023.12.30.2006.
Once that is done, please go to Settings -> Status -> Update Pre-Release and you should be running the latest build again.
As we evaluated this situation, we identified additional safety checks we could implement during upgrade to ensure the new version can successfully run before completing the upgrade. We hope this will prevent future issues of these sorts of upgrades causing DVRs to stop functioning.
As @maddox has said before, over the long term, it is important for the DVR and Client software to regularly update. If we are unable to find ways for newer releases to run on older Operating Systems, running old DVR versions will likely eventually cause issues that we are unable to address.
Thank you Eric!
Nice work and thanks! I'll be upgrading machine to Win10 this week, but this fix gets me some time to make it happen.
Heartfelt thanks to you three for continuing to do amazing work and being incredibly approachable and supportive.
Thank you for working on a solution and for the explanation on what happened. Just to clarify, this is a temporary solution and we should assume to continue to get future updates that we are still required to upgrade our older OS?
I would like to suggest that as part of your licensing check call, you send the OS information so that you can be aware of what users are running out there.
I will start working on my server upgrade. Its a multi-day project that I have not been looking forward to. For my purposes, my "antique" server was still perfectly adequate. In my case, being on WHS, MS did not give a good upgrade path for the product.
From the DVR server product page (from where you download the installer):
Channels DVR Server is officially supported on Windows 10 and up.
For those of you running into the Windows 7/Home Server 2011 issue, please try to update to the latest pre-release. We've been able to get a new build that works on Windows 7.
Thank you folks. I noticed the OS check was implemented and tested this morning. I noticed a discrepancy and noted it here:
Thank you as usual for outstanding support.
As everyone here knows, this Dev team is outstanding!!
Thanks
Steam seems to have come to the same conclusion.
Steam Support :: Windows 7 and Windows 8 Support (steampowered.com)
In regards to Home Server 2011, I did a check for pre-release and it successfully moved me to 2024.01.04.1920. Thank you.
For me, this is now a test server as I completed the week long migration to a completely new Windows 11 PC. The channels migration itself was relatively painless (Thank you!). My week long effort was mostly about the my storage array (fully backing up, reorganizing, preparation), but also included building the new PC, installing OS and apps, etc. I have been completed many successful server migrations at work. Its just a lot of hours to make sure everything gets there and works. Its amazing how many places data gets stashed in the windows systems.
There seems to be a industry wide movement recently to deliberately cutoff the old OS versions. I think its sad when an application "could" still work on those platforms. Think of the environmental waste this constant churn is creating.
I'm sure someone will pipe up and comment about how much time can be saved by eliminating testing these old versions. But lets be realistic, is every version of windows 10 tested? I tried to find an actual count, the list I found was ridiculously long.
Anyhow, thanks again for the improved update process. Many of us have spouses that are very unhappy when their dvr disappears.
I'll pipe up, but not about time saved from testing software on EOLed OSes. The reason that new and updated software is not tested on old unsupported operating systems is because they are old and unsupported. They are security hazards, no longer updated, and cannot reliably support running new software.
If you wish to continue to run older and unsupported software, you are more than welcome to do so. In fact, I do run old versions of software that are no longer supported, and do so on OSes that are old and no longer supported. But I don't expect current software to run on those systems, and I don't expect the old software to implement new features.
(You don't complain to the automakers that you can't play your 8 tracks in that new Audi you've been eying, do you? You don't expect your 64-1/2 Mustang to work with your satellite radio subscription without doing some upgrades, right?)
I think there are a few things that have been happening:
The one that I think sucks the most is that #2 item. It really is the thing that is contributing to e-waste, etc.
But the other ones? In cases where the hardware is able to run the newer Operating Systems, why should the whole industry be burning lots of resources for fixing and supporting old systems that potentially are exposing everyone to security risks when there are alternatives?
The thing that is a bummer about all of this, is that the things that we have had to do to support old versions of macOS and Windows that are EOL'd by Go have ended up being very small numbers of lines of changes. But, there have been some recent changes, for instance, that made Go on Windows have 1 more bit of randomness in the newer API than the older one (which is a big deal in randomness).
This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.