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.
Apologies for breaking into the discussion, but it seems to fit here: From what I’m seeing, the two fixes for Process.GetProcesses () are already included in Mono’s current stable (4.0.4.1).
At the very least, I don’t seem to have an issue with updating Sonarr (from latest master to latest develop, that is).
Is there something in particular I can test or look for? Reason is I’d like to update the Synology Mono package at some point (as a beta release first so we can get some feedback), but I don’t necessarily want to break people’s setup 
How can I be condescending markus? I asked you a long time ago why it does not work and until now you did not explain, so I am being reasonable to assume that you don’t care if you don’t care to explain. How is that being condescending? Go on my posts list and see me praising the app several times and thanking the developers. Now just because I am making one very valid complaint I am being condescending or is it you that do not know how to take criticism? By the way, I was not blowing any smoke. It is perfectly fine to assume that bugs can mean vulnerabilities, I am not saying that all bugs lead to vulnerabilities but many vulnerabilities stem from bugs/bad programming and you can say that I am wrong but it will not change that fact. I just want my app to be updated! I am frustrated every time I look at Sonarr’s update list and see fixes that I cannot get because it is not updating. Why can’t you guys please liaise with the package maintainer on QNAP to get this issue sorted? I am not the only one having this problem and you would know how to explain much better than I do since you are a developer. You could accomplish much more spending 5 minutes to write a concise message than I would accomplish by sending a long-winded message full of unsure information. Thanks for your effort but please put yourself in our shoes, you can get analytics I am sure, so you know how many people on QNAP are using your app, we’re all disappointed, please help.
Hey, Dr_Bean.
Interestingly, it looks like the second commit was also applied in earlier mono versions, as early as 4.0.1. The particular bug that I described earlier should only affect specific OSes, since it depends on what kind of syscalls the OS supports (from what I can see the KERN_PROC syscall is BSD specific). That might explain why you’re not seeing it on syno.
My concern is that mono changed code in the api between mono and the OS with respect to processes, without diving into it in detail I can’t ascertain exactly what changed. But i’ll venture a guess.
The code that invokes the KERN_PROC syscall was changed from a fixed max of 400 processes to a dynamic allocated one.
The syscall is first invoked without an actual buffer, and expects the syscall to return the buffer size required.
Subsequently the buffer gets allocated and the syscall invoked with the buffer, so the kernel can populate the buffer with process details.
The first commit implements this behavior, but had a bug… it doesn’t actually pass the buffer to the kernel in the second syscall. (in other words, it was never tested).
The second commit fixes that problem by passing the buffer along as intended.
If both commits are currently in the mono version available for qnap, then it could be that either mono’s assumptions about the syscall behavior is wrong, or the implementation on the OS side. Someone would have to look and compare FreeBSD and QNAP kernel source code to figure that out. Or someone could revert those two commits, see if it goes back to normal.
As for 4.x on syno, wouldn’t it be an idea to compile 4.0.4 as beta package and get a couple of regulars to test it for a month (or two)? Our experience is that any mono release is subject to regressions that only show themselves on specific usage patterns, so some duration testing is advised.
This is pretty condescending:
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.
Its a mono bug. Stephane (sp?) is aware that mono 4.0 doesn’t work for Sonarr’s updater, which is why 3.10 is recommended.
dont use Qmono 4.01, use only Qmono 3.10, Qmono 4.10 avoid the update running fine, it doesnt not finding the process to kill
(http://forum.qnap.com/viewtopic.php?f=320&t=109449&start=60#p486978)
and on our forums:
An update script instead of using Sonarr’s updater might work (its been a part of Sonarr for some time, but I’m not sure how many people use it) maybe @qoolbox can help with creating it specifically for QNAP:
The script takes in the following args:
ProcessID
Update folder (where the new files are)
Executing Application (full path to NzbDrone.exe - quoted if it contains spaces)
Arguments from when Sonarr was launched
The script will need to stop Sonarr, copy the files from the update folder to the proper folder, then start Sonarr again.
You’re right, those fixes were already present in Mono 4.0.1.0. Seeing as I don’t use QNAP, I can’t do much about that package, but reverting the code might be an easy way to verify the issue.
I was already planning on publishing the Syno package on the beta channel, and we’ll keep it there for a while. Just wanted to make sure there’s not a generic issue with Mono 4.x. I’ll pass on the feedback we get.
Thanks for the info 
I did not mean to be condescending at all, so apologies if you felt that way but it was not my intention.
Yes he is aware, but if you knew that the newest version had fixed it, why not tell him? I already did though, let’s see if he will update the package. I was only able to do it after I found out yesterday when reading the other guy’s message.
I noticed a script option. I just have no idea how to do it. Just wish that somebody with experience would do that. I help people, just not when I don’t know how. If I knew, I would be involved in fixing it.
Thanks.
That is not correct imo.
The Mono version that Stephane has packaged (4.0.1.0 from what I can tell, correct me if I’m wrong) already had that fix. Still, people run into issues with it.
That part of the Mono code hasn’t been touched since from what I can see, so it seems unlikely that packaging the latest stable will make a difference.
But let’s say you do, and the issue persists. I’d suggest to verify those code changes are indeed causing the problem, and if so, open a bug on Mono’s bugtracker. Imo, that’s where that part of the discussion belongs.
Thanks. I don’t know how to do that or what to explain, because I am not a developer, I have no experience with scripting/programming. I am just a user. I can understand some technical stuff but not programming level or how to analyse scripts. If I knew how to do it, I would be immediately going there and do it myself, trust me on this. I hate to be here humiliating myself asking for help but I have no other option =/ If you know how to do it, would you please kindly do it? It would help all QNAP users, not only myself. Thanks very much.
Fwiw, you seem to be approaching this like you urgently need to upgrade to 4.x. Unless you’re a .net/mono developer or maybe a poweruser and need 4.x for a specific reason, that’s not true. Just stick with 3.x for Sonarr. It works perfectly fine with that version, and that won’t change very soon.
If you’re asking me to make an effort to fix the Mono package for Qnap, sorry, but no. For one, I don’t own a QNAP, and secondly, I’m spending my spare time on Synology packages
Stephane uploaded the newest version of Mono and it seems to have fixed the issue, now Sonarr is updating. About installing an older version, no way… I just don’t run old software unless it’s not being maintained anymore. Fair enough if you don’t want to do it, it’s your time. Thanks.
This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.