New FreeNAS Package for testing

[Luke 42077]

Where did you submit a pull request to?

 

Also for the ffmpeg error make sure your environment is set to pull quarterly stable packages. If you have it set to latest that's not supported and ffmpeg will fail.

[makarai 109]

Hmm, did you upgrade your existing jail or installed freshly?

 

Because that error sounds strangely Familiar to being on the latest pkgs train and not the quarterly.

[makarai 109]

Where did you submit a pull request to?

 

Also for the ffmpeg error make sure your environment is set to pull quarterly stable packages. If you have it set to latest that's not supported and ffmpeg will fail.

He put out a pull request to my repository. It's not updated to 54 yet.

[tprelog 0]

Clean install. I just confirmed the emby-server-beta.json is using the quarterly packages. I only changed the emby-download-link as seen in the pull request

 

Did you see my edit? I realize this only seems to be effecting me in google-chrome

[makarai 109]

I'll check tomorrow and report back. Cheers.

[tprelog 0]

Thanks Cheers

[MRobi 161]

 but otherwise the installation and database upgrade went off with out a hitch.

 

Curious on this. Did you simply mount your dataset to /var/db/emby-server or were there extra steps you took here? I ask as I follow the same practice of keeping all settings on a separate dataset, and the second I mounted my configs, emby-server would no longer boot.

[tprelog 0]

Curious on this. Did you simply mount your dataset to /var/db/emby-server or were there extra steps you took here? I ask as I follow the same practice of keeping all settings on a separate dataset, and the second I mounted my configs, emby-server would no longer boot.

 

I made a snapshot first (just in case) but otherwise I just stopped emby -- remounted my datasets -- then restarted emby

[cherup 3]

Have the official build installed, but get an error on h264 codec:

 

 

>Shared object "libx264.so.152" not found, required by "libavcodec.so.58"

 

Any ideas how to solve ?

[Luke 42077]

Make sure your freenas system is configured for stable packages and not latest.

[cherup 3]

Make sure your freenas system is configured for stable packages and not latest.

hmmm haven't done anything special but upgrading freebsd. so normal 11.2 is installed, but system looks like

 

 

-rw-r--r--   1 root  wheel  2838854 Sep 13 03:29 libx264.a

lrwxr-xr-x   1 root  wheel       14 Sep 13 03:29 libx264.so -> libx264.so.155

-rwxr-xr-x   1 root  wheel  1988496 Sep 13 03:29 libx264.so.155

Edited October 11, 2018 by cherup

[sluggo45 47]

Read back the last several pages of this thread. This problem has come up several times, and solved.

[Barlog9511 17]

Yea sorry, like i said the previous beta was missing the fanart and moviedb features.

 

I try to install the latest beta v 3.6.0.54 and problem with background images is still here ...

[cherup 3]

Ok, have fixed my problem with "Shared object "libx264.so.152" not found, required by "libavcodec.so.58""

 

had to remove the latest libx264 package and installed the version

 

/var/cache/pkg/libx264-0.152.2854.txt

 

After that I reinstalled the emby-server.

 

Two remaining questions:

 

- when will emby be updated to libx264.so.155 that I can run a pkg update ?

- how can I configure existing installation using only quartely updates ?

[makarai 109]

Make sure your freenas system is configured for stable packages and not latest.

 

@@Luke, i just reinstalled emby-server and indeed the quarterly packages have been updated to libx264 155, and hence the current installation method for new systems will not work. So an update within emby needs to happen in order to support the version 155

 

Cheers 

[Luke 42077]

What a pain in the neck. That essentially forces the developer to release an update following a quarterly packages release.

[makarai 109]

What a pain in the neck. That essentially forces the developer to release an update following a quarterly packages release.

Luckily it's only once a quarter

On a serious note, Tha last update that was serious was Dec 2017, so almost a year ago.

[constrict 9]

For those looking for a quick temp fix.

 

I guarantee no safety from using this but the internet always finds a way to have a backup. Can use this if you don't have a backup of the pkg.

fetch https://mirrors.xtom.com/freebsd-pkg/FreeBSD%3A11%3Aamd64/quarterly/All/libx264-0.152.2854.txz
pkg add libx264-0.152.2854.txz

Edited October 13, 2018 by constrict

[makarai 109]

This will work, if some people have issues with an error message such as libx264 is already installed do it in the following order

 

from within the emby-server-beta jail you get there via

iocage console emby-server-beta

type

pkg remove libx264
fetch https://mirrors.xtom.com/freebsd-pkg/FreeBSD%3A11%3Aamd64/quarterly/All/libx264-0.152.2854.txz
pkg add libx264-0.152.2854.txz

and while you are add it update to the newest beta it works flawelessly

service emby-server stop
pkg add -f https://github.com/MediaBrowser/Emby.Releases/releases/download/3.6.0.55/emby-server-freebsd_3.6.0.55_amd64.txz
service emby-server start

Thanks constrict

 

 

For those looking for a quick temp fix.

 

I guarantee no safety from using this but the internet always finds a way to have a backup. Can use this if you don't have a backup of the pkg.

fetch https://mirrors.xtom.com/freebsd-pkg/FreeBSD%3A11%3Aamd64/quarterly/All/libx264-0.152.2854.txz
pkg add libx264-0.152.2854.txz

Edited October 13, 2018 by makarai

[tprelog 0]

@@constrict and @@makarai

 

Thanks guys. Just wanted to confirm everything seems to be working with Emby Version 3.6.0.55 and the temporary download fix for libx264

[Luke 42077]

Thanks guys. We will update the package as soon as we can.

[embytal 3]

What a pain in the neck. That essentially forces the developer to release an update following a quarterly packages release.

 

Only if the packages you depend upon are updated.

Don't you want to leverage the optimization of some of the libraries that your project leverages?

 

Without quarterly, I can tell you the number of threads you have (currently two) on broken dependencies would be a lot higher.

Edited October 13, 2018 by embytal

[Luke 42077]

I'd rather just bundle everything in the future and not have to deal with this. This essentially just blindesides us into releasing a new update when we weren't really planning on it. And it's just going to keep happening if we don't find a more permanent solution.

[makarai 109]

I'd rather just bundle everything in the future and not have to deal with this. This essentially just blindesides us into releasing a new update when we weren't really planning on it. And it's just going to keep happening if we don't find a more permanent solution.

 

how do other development project deal with this?

I am a physicist, so i dont have any expertise, but is there no way to  just check for if libx264 is installed instead of checking if libx264.long_unknow_version_number is installed. (was the change so big from 152 -> 155?)

[embytal 3]

how do other development project deal with this?

I am a physicist, so i dont have any expertise, but is there no way to  just check for if libx264 is installed instead of checking if libx264.long_unknow_version_number is installed. (was the change so big from 152 -> 155?)

 

It is related to the way some libraries are linked.