Open MichaIng opened 10 months ago
Looking forward it!
Off topic: Just wanted to thank you all for your dietpi work. Take your time and don’t stress.
Looking forward to this too!! Been running a second instance of V4 for testing and it's great!!
One day 🙏
One day 🙏
Just upgraded to dietpi 9.3. does this mean I can upgrade now easy to sonarr v4?
No
@MichaIng @Joulinar Would it make sense to get in contact with the people over at the sonarr GitHub? https://github.com/Sonarr/Sonarr/issues
Not needed. I actually know what to do, just need to find the time to actually test/verify and implement it.
Hello Michael. Is there any update on this? I'm run into some difficulties with v3, which apparently are dealt with in v4, so it would be very useful for me.
Thanks v much.
Hello Michael. Is there any update on this? I'm run into some difficulties with v3, which apparently are dealt with in v4, so it would be very useful for me.
Thanks v much.
Same for me, would also be interested.
@MichaIng Following the threads brought me here, is there anything any of us can do to help that is actually useful to you? if you had instructions you wanted some people to run through and test on various platforms or chipsets and upload logs? You are maintaining this for tons of people, we can chip in and help.
Yes, I’m also volunteering. This issue becomes now very urgent since sonarr v3 has been deprecated since November 2023 and doesn’t get any (security) fixes.
Also documentation for v3 has been taken offline.
Thank you for dietpi. Best piece of software 🔥
@MichaIng I'm guessing the goalpost keeps changing cause you're looking at a safe migration method from v3 to v4.. how about the option of having them side by side and independent of each other instead? this way new users can opt for the latest while those with a fully functional older sonarr can retain them without worry of migration issues?
I'd be happy with a workable instruction list we can then test out and post results to help people who are coming to this. It seems like there is clearly too much work for just a small group to maintain. For those of us who are not specifically network or programming guys on linux but know just enough to be helpful, and are willing with a spare pi, a good write up would go a long way. You should be letting the community help where possible even though we may not be able to just fork dietpi and make send back a working PR we could probably be more helpful than we are.
The migration should be easier than a parallel implantation. I was just to busy the last weeks to catch up.
Thank you @MichaIng we appreciate all the work you to develop DietPi!
First of all thanks @MichaIng for maintaining this software. You do it for free and we don’t really have anything to say or request.
With that being said it wanted to just share my thoughts: I think a big part of people setting up a SBC is for the purpose of a homeserver with the *arr stack.
I would assume sonarr/radarr etc is one of the most installed softwares on dietpi.
I see now on Reddit/discord/youtube people actively lobbying against dietpi because of the sonarr v3 issue. They recommend against dietpi because of that.
I think this issue should get a higher priority because of that reason.
Thanks again for maintaining dietpi.
well everybody is free to install Sonarr v4 on it's own. Same as you would do on every other SBC. Quite a strange argument just because our installer is not support v4 yet. How would people install it on other systems?
And just to get an idea on what people DietPi using for 😉 https://dietpi.com/survey/#software
well everybody is free to install Sonarr v4 on it's own. Same as you would do on every other SBC. Quite a strange argument just because our installer is not support v4 yet. How would people install it on other systems?
And just to get an idea on what people DietPi using for 😉 https://dietpi.com/survey/#software
I disagree with this argument. Why do you even then provide dietpi-Software with a GUI and one-click install?
majority of the users have no experience with Debian or the terminal. That’s why dietpi is so attractive. Have an automated service/software repo which can be installed just with clicks.
as I said. I have no right to request anything. Just mirroring feedback from homeserver community
well I was following this argument
I see now on Reddit/discord/youtube people actively lobbying against dietpi because of the sonarr v3 issue. They recommend against dietpi because of that.
Soo if people recommend against dietpi
, how would they install Sonarr on a different platform?
well I was following this argument
I see now on Reddit/discord/youtube people actively lobbying against dietpi because of the sonarr v3 issue. They recommend against dietpi because of that.
Soo if people
recommend against dietpi
, how would they install Sonarr on a different platform?
I see recommendations to use proxmox with tt helper scripts https://tteck.github.io/Proxmox/
Or using AppStore of casaOS (yes I know casaOS can run on dietpi, but it’s not mentioned)
Openmediavault
I just want to share my subjective observations. Still love dietpi but also want to keep my software secure and up to date
CasaOS is nothing else than a Docker frontend. You can get a Sonarr Docker container up on DietPi in 1 minute. Proxmox is quite on overkill for an SBC, same as OMV.
And if someone really like to switch and test, Sonarr offers a migration script that can be used with minor adjustments.
I did a very quite test and it seems to be working
root@DietPiRS6:~# systemctl status sonarr.service
● sonarr.service - Sonarr Daemon
Loaded: loaded (/etc/systemd/system/sonarr.service; enabled; preset: enabled)
Active: active (running) since Sat 2024-10-19 13:06:33 CEST; 51s ago
Main PID: 11021 (Sonarr)
Tasks: 23 (limit: 201)
Memory: 89.8M
CPU: 13.853s
CGroup: /system.slice/sonarr.service
└─11021 /opt/Sonarr/Sonarr -nobrowser -data=/mnt/dietpi_userdata/sonarr/
And if someone really like to switch and test, Sonarr offers a migration script that can be used with minor adjustments.
I did a very quite test and it seems to be working
root@DietPiRS6:~# systemctl status sonarr.service ● sonarr.service - Sonarr Daemon Loaded: loaded (/etc/systemd/system/sonarr.service; enabled; preset: enabled) Active: active (running) since Sat 2024-10-19 13:06:33 CEST; 51s ago Main PID: 11021 (Sonarr) Tasks: 23 (limit: 201) Memory: 89.8M CPU: 13.853s CGroup: /system.slice/sonarr.service └─11021 /opt/Sonarr/Sonarr -nobrowser -data=/mnt/dietpi_userdata/sonarr/
That's Awesome! Can you put down what the minor adjustments were? Even a gist of the updated script! I'm positive that would solve 100% of the concerns people have and then this becomes an very minor issue. Again, I'm only asking how we can help. Not just on here, but in general. If there was a list of things to try I'd be happy to participate in that too.
Without any guarantee https://dietpi.com/forum/t/sonarr-version-out-of-date/21729/12?u=joulinar
Perfection!!
on Pi4B version 9.8.0
Without any guarantee https://dietpi.com/forum/t/sonarr-version-out-of-date/21729/12?u=joulinar
Excellent step-by-step! The only thing for my setup is that I skipped the purging of the old sonarr (G_ADP sonarr
) and just ran apt remove sonarr
as this will leave current configs be.
Without any guarantee https://dietpi.com/forum/t/sonarr-version-out-of-date/21729/12?u=joulinar
Hey @Joulinar thank you for this. Does this mean we might see progress for sonarr v4 within the dietpi updater soon?
Good start in the day to you all
Without any guarantee https://dietpi.com/forum/t/sonarr-version-out-of-date/21729/12?u=joulinar
Thank you very much for your help!!
Installer: https://raw.githubusercontent.com/Sonarr/Sonarr/develop/distribution/debian/install.sh
While the download page states that the v3 package will be overwritten, the new installer actually does not install a (DEB) package but downloads and extracts an archive. The DEB package and APT repository would just remain. This is pretty unclean and I am hence not sure whether this is the intended way of migration.
We can purge the package and do the migration via
dietpi-update
, but we'd need to make sure no data/configs are lost, hence needs some testing.