Latest development version

My development version is
2.0.0.3463 - Sep 3 2015 that’s 15 days ago. Is this still the latest version? Could that my update on debian is broken,
but the apt.sonarr.tv tells also that 3 sep is latest one …

The latest version for the branch Sonarr is set to is on System: Updates

That should be the latest version though, there are a fee changes that will be in the next successful build, but those were done a fee days ago.

check! thanks. My system is fine than ;-0)

Ooh, a followup to this then, & this may be the wrong place/person to be asking, but once installed via a QNAP build qpkg, do the updates work automatically (through GIT), or will it require an updated qpkg.

The System :: Updates for me is showing 2.0.0.3357, presumably the non Development stable release, but unsure where I can check it is in fact the ‘latest’.

Where did you get your Mono? Is it the QMono package maintained by QNAP_Stephane? Does your updates work? The app works okay, it is the updating that does not work.

Thats’s the one, yea’, found it here:

I’m not sure if updates work, which is why I’m inquiring what the latest non-Dev build version is… if it’s 2.0.0.3419 then yes, or there has been no updates since I installed it around 10 days ago…

Latest stable is 2.0.0.3357

There are newer development builds, but I believe there was a change on the develop branch to get most people back on stable instead of develop. I can’t find the commit, so I might be wrong.

Your Settings > General should say Updates branch is master

1 Like

Aaaha! Think you’ve hit the nail on it, the updates tab is showing the latest stable 3357, however since I already have 3419, it won’t downgrade itself, guess we’ll see when a new stable eleases if auto-update works or not.

I checked the branch is indeed Master, as you suggested.

It depends on which Mono you downloaded, there are three links there, one for 3.10, one for 3.12, another for 4.x, if you are using the first link, 3.10 it will update, otherwise it will not update. There is a problem with Sonarr when you use Mono 4.x and the developers will not fix it, I reported this issue months ago and they simply ignored it. You can see if there is any updates on the Updates tab of the Settings, the top most version is always the latest and if there is a tag after it saying INSTALLED it means you’re using the latest version. If you always want the latest you need to change your branch to “develop” instead of “master”.

Just to clarify develop isn’t considered stable. Has new interested features and stuff. I wouldn’t use it for everyday usage

Not seeing anything either, I’m on a Linux server and I recall the builds were stuck about a month ago. Not been that many changes, figured someone would say something eventually.

But my develop build is at 2.0.0.3463

Its considered less stable, but its still stable. We have over 3000 users using it daily, including all the devs. It definitely isn’t for everyone and there is there is a chance issues arise due to it being the first place new features are heavily used.

I see what you mean now. I changed to the develop branch. I see the 3463 update available, however despite logs appearing like a successful update, upon restart it;s back to 3419, maybe it reads from the qpkg over all else… I’ll go see if our qpkg master Stephane has anything to add, though I imagine he gets pestered plenty for updates qpkg updates.

See? I told you… It’s not that. It’s the app that does not work properly with Mono 4.x. If you install Mono 3.10 (and don’t care about its security vulnerabilities) the app will update just fine. Sonarr developers need to fix it to work properly with Mono 4.x but they do not care. They don’t care if you are running a software with security issues. They probably think that everyone just runs the app on a raspberry pi.

Yes it is stable. I’ve always used develop and have no problems whatsoever. Can safely use every day. What is the reason why you’re saying that? Give an example of what made you think this way. I always used develop and have none issues. The only issue I have with Sonarr is that it will not update when it’s running on top of Mono 4.x, this is Sonarr problem, and it happens in any branch, not only develop branch.

I wasn’t saying it’d break, just not as stable as stable (and I’m not sure how much I even believe that). Using new beta features are great, everyone needs feedback and stuff, but its not without risks.
As @markus101 it should absolutely be safe to use.

Something in mono changed (for the bad) and broke the ability for us to get information on another process, the fact that it worked in 3.10 and broke in 4.0 means something in mono changed, not something we broke. The solution is a lot more complicated than “fixing it”, hence the reason why it wasn’t fixed.

I would love to see this list of security issues.

Yes, thats the only viable platform, never mind the thousands of people on Windows.

@d2877834rt5 I’m getting seriously annoyed with your disposition. Your accusations are based on assumptions and misunderstanding how we use mono.

The problem is with mono, period.

We call the Process.GetProcesses API. It’s a single api call to get all Processes accessible to the user. If on 3.x it worked for qnap and now on 4.x it doesn’t, how can you possibly argue that we’re to blame and somehow have to fix it?
Btw, the mono team doesn’t officially support integration and packaging for qnap either, you’re just lucky that some third-party developer somewhere spends time on making it work.

Also check this possible cause and this possible solution and hope that’s the reason. The above commits explain the behavior IF qnap doesn’t support KERN_PROC2, coz the KERN_PROC fallback code was broken in that first commit.
Can we now please stop bashing at the Sonarr dev team… thank you.

If you really want to get your hands dirty, figure out how they build mono for qnap, get that version, and build it, then test it.

I am arguing that you need to fix it because Mono changed and your app did not. It’s like you made an app to run on Windows 95, then Microsoft release Windows 98 and it still worked, but then they released Windows 2000 and XP and your app only worked somewhat, and you forgot to update or fix the issue to work with the newest version of Windows. That is why it is your app and not Mono. It is silly to say that the problem is Mono, it is not. Mono is working just fine, other .net apps are running fine on my server, only your app is doing this update problem and that is because you guys are not fixing it. I love your app very much, but that does not mean that I will pretend it is perfect or blindly defend it when it is not getting fixed. I want the app to be automatically updated and I do not want to use an older version of a software to use your app. Markus was saying that he would love to see a list of security issues. Wow. That came from a developer. Why do people update apps? It’s because of bugs, and bugs often mean vulnerabilities, I never though that I would have to explain this to a developer. I don’t want to downgrade Mono. I just want Sonarr to automatically update with the latest version of Mono. I am not a developer. If you want me to stop “bashing”, which I am not, I am just stating the truth because you guys aren’t explaining why, then please explain in simple terms why you cannot make your app work with Mono 4.x. I mean no disrespect but I hate being kept in the dark. Thanks.

TLDR You’re wrong, its a mono bug.

I didn’t ask you to explain anything I asked where this magical vulnerability list is, since you’re so adamant is the reason 4.0 was released, which clearly doesn’t exist and you’re blowing smoke.

You’re making an assumption here that bugs mean vulnerabilities, when that isn’t 1 to 1. Take this current mono bug for example, its a bug, a regression even, things used to work a particular way and when mono 4.0 was released it didn’t work the same way, thats a bug. The framework didn’t change and we suddenly need to support something different, this code works fine in .net (Windows), fine in mono 3.10 and should again work fine in mono 4.2 when the bug is fixed, there isn’t anything we can do here, we ask for the list of processes and the system gives us zero back.

I find that hard to believe when you’re being so condescending, even if you are wrong.