Jump to content

FreeBSD Package


Luke

Recommended Posts

crunchyemby

@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 by crunchyemby
  • Like 1
Link to comment
Share on other sites

crunchyemby

@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.
 

  • Like 1
Link to comment
Share on other sites

crunchyemby

@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"}
...

  • Like 1
Link to comment
Share on other sites

crunchyemby

@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:

  1. stop Emby ("service emby-server stop")
  2. downgrade to mono ... as of March 2021, "latest" is tied to mono 5.10.1.57_3 ("pkg install mono")
  3. 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")
  4. **CRITICAL** lock the Emby package ("pkg lock emby-server")
  5. upgrade mono 5.20.xxxxxxx ("pkg install mono5.20-5.20.1.34")
  6. **OPTIONAL** unlock the Emby package ("pkg unlock emby-server")
  7. restart Emby ("service emby-server start")
  8. 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 by crunchyemby
  • Like 1
Link to comment
Share on other sites

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:

  1. stop Emby ("service emby-server stop")
  2. **CRITICAL** lock the Emby package ("pkg lock emby-server")
  3. downgrade to mono ... as of March 2021, "latest" is tied to mono 5.10.1.57_3 ("pkg install mono")
  4. 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")
  5. upgrade mono 5.20.xxxxxxx ("pkg install mono5.20-5.20.1.34")
  6. restart Emby ("service emby-server start")
  7. cross fingers

Thanks, that's helpful info.

Link to comment
Share on other sites

Baenwort
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:

  1. stop Emby ("service emby-server stop")
  2. downgrade to mono ... as of March 2021, "latest" is tied to mono 5.10.1.57_3 ("pkg install mono")
  3. 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")
  4. **CRITICAL** lock the Emby package ("pkg lock emby-server")
  5. upgrade mono 5.20.xxxxxxx ("pkg install mono5.20-5.20.1.34")
  6. **OPTIONAL** unlock the Emby package ("pkg unlock emby-server")
  7. restart Emby ("service emby-server start")
  8. 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.

  • Thanks 1
Link to comment
Share on other sites

  • 2 weeks later...
Baenwort
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.

  • Thanks 1
Link to comment
Share on other sites

  • 2 months later...
raidflex
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

Duffyx

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 by Duffyx
  • Like 1
Link to comment
Share on other sites

specsnow

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. 

  • Like 1
Link to comment
Share on other sites

specsnow

Looks like 4.6.2.0 is now available for FreeBSD 11. Hopefully FreeBSD 12 will get it soon! :)

  • Like 1
  • Thanks 1
Link to comment
Share on other sites

MRobi
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

Duffyx
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 by Duffyx
Link to comment
Share on other sites

MRobi
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 :)

  • Like 1
Link to comment
Share on other sites

Baenwort
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

  • Like 1
Link to comment
Share on other sites

Duffyx
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 by Duffyx
  • Like 1
Link to comment
Share on other sites

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

MRobi
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

Baenwort
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

MRobi
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

Baenwort
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

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

  • 1 month later...

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 account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...