crunchyemby 9 Posted March 24, 2021 Share Posted March 24, 2021 (edited) @Luke bsd_emby_n:/ # mono -V Mono JIT compiler version 5.20.1.34 (5.20.1.34 Sat Mar 20 09:10:34 UTC 2021) bsd_emby_n:/ # mono -V Mono JIT compiler version 6.8.0.123 (tarball Sat Mar 20 23:17:34 UTC 2021) bsd_emby_n:/ # pkg add -f https://github.com/MediaBrowser/Emby.Releases/releases/download/4.6.0.34/emby-server-freebsd11_4.6.0.34_amd64.txz [bsd_emby_n] Fetching emby-server-freebsd11_4.6.0.34_amd64.txz: 100% 44 MiB 11.4MB/s 00:04 [bsd_emby_n] Installing emby-server-4.6.0.34_1... Newer FreeBSD version for package emby-server: To ignore this error set IGNORE_OSVERSION=yes - package: 1104001 - running kernel: 1103000 Ignore the mismatch and continue? [y/N]: y pkg: Missing dependency 'mono' Failed to install the following 1 package(s): https://github.com/MediaBrowser/Emby.Releases/releases/download/4.6.0.34/emby-server-freebsd11_4.6.0.34_amd64.txz Edited March 24, 2021 by crunchyemby 1 Link to comment Share on other sites More sharing options...
crunchyemby 9 Posted March 24, 2021 Share Posted March 24, 2021 @Luke - Emby installs and starts fine with 5.10 ... bsd_emby_n:/ # mono -V Mono JIT compiler version 5.10.1.57 (5.10.1.57 Sat Mar 20 02:10:45 UTC 2021) bsd_emby_n:/ # !1003 pkg add -f https://github.com/MediaBrowser/Emby.Releases/releases/download/4.6.0.34/emby-server-freebsd11_4.6.0.34_amd64.txz [bsd_emby_n] Fetching emby-server-freebsd11_4.6.0.34_amd64.txz: 100% 44 MiB 11.4MB/s 00:04 [bsd_emby_n] Installing emby-server-4.6.0.34_1... Newer FreeBSD version for package emby-server: To ignore this error set IGNORE_OSVERSION=yes - package: 1104001 - running kernel: 1103000 Ignore the mismatch and continue? [y/N]: y ===> Creating groups. Using existing group 'emby'. ===> Creating users Using existing user 'emby'. [bsd_emby_n] Extracting emby-server-4.6.0.34_1: 100% bsd_emby_n:/ # service emby-server start Starting emby_server. 1 Link to comment Share on other sites More sharing options...
crunchyemby 9 Posted March 24, 2021 Share Posted March 24, 2021 I assume I'm missing something obvious, like a change in the system path... Just not seeing it. Link to comment Share on other sites More sharing options...
crunchyemby 9 Posted March 24, 2021 Share Posted March 24, 2021 @Luke - Further inspection of the Emby manifest... it looks like mono is tied to "5.10.1.57_3". ...emby-server-freebsd11_4.6.0.34_amd64.tar/+MANIFEST: ... "mono":{"origin":"lang/mono","version":"5.10.1.57_3"} ... 1 Link to comment Share on other sites More sharing options...
crunchyemby 9 Posted March 24, 2021 Share Posted March 24, 2021 (edited) @Luke Okay... for future reader clarity, once successfully installed Emby DOES find and use mono 5.20.... It's the dependency issue, of installing/upgrading Emby, that causes issues... Installing mono 5.20 removes Emby (to be fair it warns you first). If you use "pkg lock emby-server" you're able to upgrade mono, while keeping the currently installed version of Emby. As of Emby 4.6.0.34, mono 5.10.1.57_3 is an installation pre-requisite (specified in the Emby manifest, presumably derived from .../${ABI}/latest). So I assume, now that I have Emby running on 5.20, to get future Emby upgrades, we're going to need to perform the following steps: stop Emby ("service emby-server stop") downgrade to mono ... as of March 2021, "latest" is tied to mono 5.10.1.57_3 ("pkg install mono") upgrade Emby ("pkg add -f https://github.com/MediaBrowser/Emby.Releases/releases/download/x.x.x.xx/emby-server-freebsdxx_x.x.x.xx_amd64.txz") "pkg lock emby-server") **CRITICAL** lock the Emby package ("pkg lock emby-server") upgrade mono 5.20.xxxxxxx ("pkg install mono5.20-5.20.1.34") **OPTIONAL** unlock the Emby package ("pkg unlock emby-server") restart Emby ("service emby-server start") cross fingers * edit 1: Changed step order: Moved "lock" to just before upgrading mono, to make it obvious that the Emby lock is related to upgrading to mono 5.20. * edit 2: I didn't bother to research or test ... but to upgrade Emby, it may be required to perform "pkg unlock emby-server", before upgrading Emby. Optionally, you could "unlock" the Emby package after upgrading mono. Edited March 24, 2021 by crunchyemby 1 Link to comment Share on other sites More sharing options...
Luke 37065 Posted March 24, 2021 Author Share Posted March 24, 2021 1 minute ago, crunchyemby said: @Luke Okay... for future reader clarity, once successfully installed Emby DOES find and use mono 5.20.... It's the dependency issue, of installing/upgrading Emby, that causes issues... Installing mono 5.20 removes Emby (to be fair it warns you first). If you use "pkg lock emby-server" you're able to upgrade mono, while keeping the currently installed version of Emby. As of Emby 4.6.0.34, mono 5.10.1.57_3 is an installation pre-requisite (specified in the Emby manifest, presumably derived from .../${ABI}/latest). So I assume, now that I have Emby running on 5.20, to get future Emby upgrades, we're going to need to perform the following steps: stop Emby ("service emby-server stop") **CRITICAL** lock the Emby package ("pkg lock emby-server") downgrade to mono ... as of March 2021, "latest" is tied to mono 5.10.1.57_3 ("pkg install mono") upgrade Emby ("pkg add -f https://github.com/MediaBrowser/Emby.Releases/releases/download/x.x.x.xx/emby-server-freebsdxx_x.x.x.xx_amd64.txz") "pkg lock emby-server") upgrade mono 5.20.xxxxxxx ("pkg install mono5.20-5.20.1.34") restart Emby ("service emby-server start") cross fingers Thanks, that's helpful info. Link to comment Share on other sites More sharing options...
Baenwort 97 Posted March 26, 2021 Share Posted March 26, 2021 On 3/24/2021 at 1:33 PM, crunchyemby said: @Luke Okay... for future reader clarity, once successfully installed Emby DOES find and use mono 5.20.... It's the dependency issue, of installing/upgrading Emby, that causes issues... Installing mono 5.20 removes Emby (to be fair it warns you first). If you use "pkg lock emby-server" you're able to upgrade mono, while keeping the currently installed version of Emby. As of Emby 4.6.0.34, mono 5.10.1.57_3 is an installation pre-requisite (specified in the Emby manifest, presumably derived from .../${ABI}/latest). So I assume, now that I have Emby running on 5.20, to get future Emby upgrades, we're going to need to perform the following steps: stop Emby ("service emby-server stop") downgrade to mono ... as of March 2021, "latest" is tied to mono 5.10.1.57_3 ("pkg install mono") upgrade Emby ("pkg add -f https://github.com/MediaBrowser/Emby.Releases/releases/download/x.x.x.xx/emby-server-freebsdxx_x.x.x.xx_amd64.txz") "pkg lock emby-server") **CRITICAL** lock the Emby package ("pkg lock emby-server") upgrade mono 5.20.xxxxxxx ("pkg install mono5.20-5.20.1.34") **OPTIONAL** unlock the Emby package ("pkg unlock emby-server") restart Emby ("service emby-server start") cross fingers * edit 1: Changed step order: Moved "lock" to just before upgrading mono, to make it obvious that the Emby lock is related to upgrading to mono 5.20. * edit 2: I didn't bother to research or test ... but to upgrade Emby, it may be required to perform "pkg unlock emby-server", before upgrading Emby. Optionally, you could "unlock" the Emby package after upgrading mono. Can confirm this works on TrueNAS 12.0-U2.1 and Emby sees and uses mono 5.20 when running 5.6 beta. No issues with changing mono detected so far. Still testing functions. 1 Link to comment Share on other sites More sharing options...
Baenwort 97 Posted April 3, 2021 Share Posted April 3, 2021 On 3/25/2021 at 10:42 PM, Baenwort said: Can confirm this works on TrueNAS 12.0-U2.1 and Emby sees and uses mono 5.20 when running 5.6 beta. No issues with changing mono detected so far. Still testing functions. Confirming that after a week of use and several beta server updates where I had to run through this after each upgrade that I have encountered no issues with any functionality from this change. 1 Link to comment Share on other sites More sharing options...
specsnow 3 Posted June 5, 2021 Share Posted June 5, 2021 Hi all. Any ETA on when the FreeBSD ports will be updated to 4.6.2.0? It looks like one of the maintainers has pushed 4.6.1.0 but only to FreeBSD 13 and FreeBSD 14. Many of us run FreeBSD 12 (or FreeBSD 11) and are still waiting. https://www.freshports.org/multimedia/emby-server/ Link to comment Share on other sites More sharing options...
raidflex 9 Posted June 7, 2021 Share Posted June 7, 2021 On 6/5/2021 at 5:27 PM, specsnow said: Hi all. Any ETA on when the FreeBSD ports will be updated to 4.6.2.0? It looks like one of the maintainers has pushed 4.6.1.0 but only to FreeBSD 13 and FreeBSD 14. Many of us run FreeBSD 12 (or FreeBSD 11) and are still waiting. https://www.freshports.org/multimedia/emby-server/ Curious on this as well. Not sure why ports for Freebsd 14 are updated first when this is alpha software. Seems like it would make more sense to support stable first.... Link to comment Share on other sites More sharing options...
Duffyx 25 Posted June 7, 2021 Share Posted June 7, 2021 (edited) Hi all! I am the maintainer of the emby-server package and as most of the FreeBSD folks we are all volunteers to the project. First of all, the update of 4.6.2.0 has been carried out on 2 june 2021 as can be seen in the commit history on the main/master branch of the ports tree. That was literally the same day or one day later after the release came out, I can't remember. But nevertheless, that's fast. Secondly, when it is available for your specific use case is hard to tell, depending on which ports branch you track and if you use packages or not to upgrade. If you track the main branch of the ports tree you will already have the newest version in the ports tree from the timestamp of the above commit. If you track quarterly it will mostly take maximum a full quarter of the year depending on when the quarterly branches branch from the main/master branch. If you update using packages you need to wait for the build clusters to catch up for that release version/branch combo. Freshports reports the timestamp of the latest rebuilt if you hover over the versions of the package for that specific FreeBSD version... You can always manually change the repo you are tracking (latest/quarterly); https://wiki.freebsd.org/Ports/QuarterlyBranch You can check which branch you are tracking of packages by using pkg -vv, and looking for the repository URL what it mentions. TLDR; be patient! The rest of the FreeBSD infrastructure is catching up or you are using the quarterly packages and/or are tracking the quarterly ports tree. Edited June 7, 2021 by Duffyx 1 Link to comment Share on other sites More sharing options...
specsnow 3 Posted June 7, 2021 Share Posted June 7, 2021 Thank you @Duffyx for all your hard work! I am using the latest repo: url : "pkg+http://pkg.FreeBSD.org/FreeBSD:12:amd64/latest" and 4.5.4.0_1 is still the latest version of Emby available. When you look at FreshPorts, FreeBSD 14 has Emby 4.6.2.0 available in the latest repo, and FreeBSD 13 has Emby 4.6.1.0 available in the latest repo. FreeBSD 12 and FreeBSD 11 still only have 4.5.4.0_1 in the latest repo. I definitely don't mind being patient. I just want to make sure the cogs are spinning and it will eventually show up. 1 Link to comment Share on other sites More sharing options...
specsnow 3 Posted June 8, 2021 Share Posted June 8, 2021 Looks like 4.6.2.0 is now available for FreeBSD 11. Hopefully FreeBSD 12 will get it soon! 1 1 Link to comment Share on other sites More sharing options...
MRobi 159 Posted June 8, 2021 Share Posted June 8, 2021 On 07/06/2021 at 11:41, Duffyx said: Hi all! I am the maintainer of the emby-server package and as most of the FreeBSD folks we are all volunteers to the project. Question for you as the maintainer of the package. Is there a reason that the package version of emby-server is not using the bundled ffmpeg setup and is instead pointed to the default location using a generic ffmpeg build? Is that something that can be adjusted in the package itself? Link to comment Share on other sites More sharing options...
Duffyx 25 Posted June 9, 2021 Share Posted June 9, 2021 (edited) 8 hours ago, MRobi said: Question for you as the maintainer of the package. Is there a reason that the package version of emby-server is not using the bundled ffmpeg setup and is instead pointed to the default location using a generic ffmpeg build? Is that something that can be adjusted in the package itself? Depends on what you are exactly trying to say. Currently the FreeBSD port uses the Emby provided ffmpeg source and we built it locally, we do not use the generic ffmpeg which is available in FreeBSD ports. Edited June 9, 2021 by Duffyx Link to comment Share on other sites More sharing options...
MRobi 159 Posted June 9, 2021 Share Posted June 9, 2021 14 hours ago, Duffyx said: Depends on what you are exactly trying to say. Currently the FreeBSD port uses the Emby provided ffmpeg source and we built it locally, we do not use the generic ffmpeg which is available in FreeBSD ports. In a nutshell.... the FreeNAS/TrueNAS community plugin originally installed the emby pkg and all the dependencies separate. Since the pkg itself should install the required dependencies, @Baenwortupdated it so it would install only the emby pkg. When he made that change, nobody could play files because of ffmpeg errors. Digging into it, he found it was because it was pointed to the generic ffmpeg location instead of the emby provided location and has been for 3 or 4 years now. To make it work, users had to also run pkg install ffmpeg. So now the TrueNAS plugin is setup to install both (https://github.com/ix-plugin-hub/iocage-plugin-index/blob/master/emby.json), but using the generic ffmpeg can lead to errors on certain files. I'm thinking maybe you 2 could chat and figure out exactly what's happening here and fix it for good 1 Link to comment Share on other sites More sharing options...
Baenwort 97 Posted June 13, 2021 Share Posted June 13, 2021 On 6/8/2021 at 6:03 PM, MRobi said: Question for you as the maintainer of the package. Is there a reason that the package version of emby-server is not using the bundled ffmpeg setup and is instead pointed to the default location using a generic ffmpeg build? Is that something that can be adjusted in the package itself? It is the FreeNAS/TrueNAS plugin that is using the generic Ffmpeg build. The issue is the git at: https://github.com/freenas/iocage-plugin-emby.git which I've put in a request to update to the ffmpeg build bundled with emby. I'm trying to get someone who can authorize the request to push the button to approve my change. I've got the plugin's updated to at least stop the error messages for everyone who updates using them but I haven't gotten a response yet from a maintainer of https://github.com/freenas/iocage-plugin-emby.git 1 Link to comment Share on other sites More sharing options...
Duffyx 25 Posted June 14, 2021 Share Posted June 14, 2021 (edited) 9 hours ago, Baenwort said: It is the FreeNAS/TrueNAS plugin that is using the generic Ffmpeg build. The issue is the git at: https://github.com/freenas/iocage-plugin-emby.git which I've put in a request to update to the ffmpeg build bundled with emby. I'm trying to get someone who can authorize the request to push the button to approve my change. I've got the plugin's updated to at least stop the error messages for everyone who updates using them but I haven't gotten a response yet from a maintainer of https://github.com/freenas/iocage-plugin-emby.git Indeed. It seems the plugin uses a different rc script (overwrites the correct one) than the one shipped in the FreeBSD pkg (which correctly uses the emby ffmpeg/ffprobe location). You can always override manually for the time being by setting this in rc.conf in the jail: emby_server_ffmpeg="/usr/local/lib/emby-server/bin/ffmpeg"' emby_server_ffprobe="/usr/local/lib/emby-server/bin/ffprobe" Even more so I see that in the rc script that is used to overwrite the shipped one, ffdetect is not mentioned. This is also needed in recent versions IIRC. I think the best would be to just delete that script from the plugin as it is installed through the emby-server package coming from the FreeBSD repo anyway... Although I don't know if that's allowed / possible as my experience with TrueNAS plugins is limited. Edited June 14, 2021 by Duffyx 1 Link to comment Share on other sites More sharing options...
Luke 37065 Posted June 14, 2021 Author Share Posted June 14, 2021 21 hours ago, Baenwort said: It is the FreeNAS/TrueNAS plugin that is using the generic Ffmpeg build. The issue is the git at: https://github.com/freenas/iocage-plugin-emby.git which I've put in a request to update to the ffmpeg build bundled with emby. I'm trying to get someone who can authorize the request to push the button to approve my change. I've got the plugin's updated to at least stop the error messages for everyone who updates using them but I haven't gotten a response yet from a maintainer of https://github.com/freenas/iocage-plugin-emby.git Yes it would be great if they'd merge that in. Link to comment Share on other sites More sharing options...
MRobi 159 Posted June 15, 2021 Share Posted June 15, 2021 On 13/06/2021 at 20:26, Baenwort said: It is the FreeNAS/TrueNAS plugin that is using the generic Ffmpeg build. The issue is the git at: https://github.com/freenas/iocage-plugin-emby.git which I've put in a request to update to the ffmpeg build bundled with emby. I'm trying to get someone who can authorize the request to push the button to approve my change. I've got the plugin's updated to at least stop the error messages for everyone who updates using them but I haven't gotten a response yet from a maintainer of https://github.com/freenas/iocage-plugin-emby.git Just thinking out loud here.... I notice a lot of the other json's have a git hosted on personal githubs. How about forking the git, make the required changes and then point the json to the new artifact location? Link to comment Share on other sites More sharing options...
Baenwort 97 Posted June 16, 2021 Share Posted June 16, 2021 6 hours ago, MRobi said: Just thinking out loud here.... I notice a lot of the other json's have a git hosted on personal githubs. How about forking the git, make the required changes and then point the json to the new artifact location? Do we have someone willing to take on that responsibility? I've been hesitant as since Emby went closed sourced I'm not dependable contributor. I still pitch in occasionally as I still use it but I'm not the advocate and passionate supporter I was before that change. Link to comment Share on other sites More sharing options...
MRobi 159 Posted June 16, 2021 Share Posted June 16, 2021 9 hours ago, Baenwort said: Do we have someone willing to take on that responsibility? I've been hesitant as since Emby went closed sourced I'm not dependable contributor. I still pitch in occasionally as I still use it but I'm not the advocate and passionate supporter I was before that change. I don't mind forking it and can host it on my personal github and you can make any PR's needed. https://github.com/MRobi1/iocage-plugin-emby I changed the path for ffmpeg and ffprobe in the rc.d I'm not able to test it though. I shutdown my FreeNAS box last year in favor of Proxmox and run emby in docker now. Link to comment Share on other sites More sharing options...
Baenwort 97 Posted June 17, 2021 Share Posted June 17, 2021 11 hours ago, MRobi said: I don't mind forking it and can host it on my personal github and you can make any PR's needed. https://github.com/MRobi1/iocage-plugin-emby I changed the path for ffmpeg and ffprobe in the rc.d I'm not able to test it though. I shutdown my FreeNAS box last year in favor of Proxmox and run emby in docker now. I can test it (and I also added the ffdetect in my repo) but I won't have time until the second week of July. (this week is fathers day and moving house, next week is family camp trip, weekend after that is fourth of July). When Emby was open source I would have ranked it high enough to stay up late or reschedule something but right now it gets time when I have on a weekend. Link to comment Share on other sites More sharing options...
Luke 37065 Posted June 21, 2021 Author Share Posted June 21, 2021 Some news, we have a FreeBSD 13 package being built now. We'll get it up on the website for download. Thanks everyone. Link to comment Share on other sites More sharing options...
Luke 37065 Posted August 19, 2021 Author Share Posted August 19, 2021 Here are some updates related to our FreeBSD packages: Thanks everyone. 1 Link to comment Share on other sites More sharing options...
Recommended Posts
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now