Jump to content

Version 3.2.40.0 is now available for download

nurgle

By nurgle
in Linux

 Share

Recommended Posts

nurgle

nurgle   3

Posted
Posted

Hi,

 

I am running Emby on Ubuntu 16.04, version Version 3.2.36.0 and it tells me there is a new version available 3.2.40.0. I've always kept my server up to date using apt-get upgrade through the opensuse repo (http://download.opensuse.org/repositories/home:/emby/xUbuntu_16.04/)  and never had a problem. This time round i'm not sure if I should upgrade or not due to the change from mono to .Net. My question is, the version that's available in the repo is this a mono or .Net build? Is there a way I can check before I run an apt-get upgrade?

 

I would like to move from mono to .Net but how seamless is the upgrade? I've seen a few issues on the forum so I'm not sure if its safe to do or not.

 

Many thanks,

 

David

Link to comment
Share on other sites
dcrdev

dcrdev   251

Posted
Posted (edited)

That is the mono version - unfortunately the .net core version isn't available via a repository, as inconvenient as that is.

 

In regards to making the switch, it's relatively seamless but not quite.

 

1. $ systemctl stop emby-server

2. $ apt-get remove emby-server

3. Edit /etc/emby-server.conf

    -- Change the line beginning EMBY_PROGRAMDATA= to EMBY_PROGRAMDATA=/var/lib/emby-server

4. $ chown -R emby:emby /var/lib/emby-server

5. Download emby and run $ dpkg -i emby-server-deb_3.2.40.0_amd64.deb

6. $ systemctl daemon-reload && systemctl start emby-server

7. That's it - you may need to reinstall some plugins, so that they target .net core.

 

I would probably recommend making a backup of your data directory first though.

$ mkdir /temp/emby.backup && rsync -avPX /var/lib/emby-server/. /temp/emby.backup/.
Edited by dcrdev
Link to comment
Share on other sites
tdiguy

tdiguy   96

Posted
Posted

Switching from mono to .net is worth doing. But it likely will not be very smooth. Plan an outage window with your family :)

If your on emby premier it might be worth looking into the help for migrating emby using the emby backup plugin or following the instructions from 

dcrdev

 

The .net emby is far more responsive than mono and scanning libraries takes significantly less time.

Link to comment
Share on other sites
nurgle

nurgle   3

Posted
  • Author
Posted

Thanks for the response. For now I've just updated the mono version using the repo. I'll have a go at updating to .net at the weekend.

 

One thing I have noticed in my /etc/emby-server.conf there isn't a EMBY_PROGRAMDATA= variable, only the following:

 

## To change the defaults add any of the following settings below the comments

##
## EMBY_USER=       #$EMBY_USER, username to run Emby under, the default is emby
## EMBY_GROUP=      #$EMBY_GROUP, Emby server group where Emby user belongs
## EMBY_DIR=        #$EMBY_DIR, the location of Emby program files the default is /usr/lib/emby-server
## EMBY_BIN=        #$EMBY_BIN, full path of MediaBrowser.Server.Mono.exe the default is /usr/lib/emby-server/bin/MediaBrowser.Server.Mono.exe
## EMBY_DATA=       #$EMBY_DATA, the location of Emby data, cache, logs, the default is /var/lib/emby-server
## EMBY_PIDFILE=    #$EMBY_PIDFILE, the location of emby.pid, the default is /var/run/emby/emby-server.pid
## EMBY_ADD_OPTS=   #$EMBY_ADD_OPTS, additional options to pass to the Emby server executable, beyond ffmpeg, ffprobe and restart
## MONO_BIN=        #$MONO_BIN, full path of mono binary, the default is /usr/bin/mono-sgen
## MONO_OPTS=       #$MONO_OPTS, list of additional options to pass to mono binary
## MONO_ENV=        #$MONO_ENV, list of environment variables for running mono binary
 
Should I just add the EMBY_PROGRAMDATA= or should I be using EMBY_DATA= entry?
 
Thanks again.
Link to comment
Share on other sites
dcrdev

dcrdev   251

Posted
Posted

It's a different startup script / configuration file for .net core.

 

You should update that file after you have updated the package.

Link to comment
Share on other sites
SkyBehind

SkyBehind   23

Posted
Posted (edited)

It seems VAAPI hasn't been able to initialize since I updated.  Log attached.   Any thoughts?

 

notes:

 

1.  Emby is part of the video group

2.  There is no longer an option in Emby to select ffmpeg (this disappeared when I updated to .Net version previously, but it was working with the static version that comes packaged).  Regardless, ffmpeg is owned by the group of which Emby is a part of.

emby log 22nov2017.txt

Edited by SkyBehind
Link to comment
Share on other sites
dcrdev

dcrdev   251

Posted
Posted (edited)

I believe the .net core version packages libva and drivers only for drm.

 

When using direct render manager, you can't use an active device. Do you have any render nodes listed under /dev/dri? If so try changing the "VA API Device:" option in Emby to point to that, for example "/dev/dri/renderD128".

 

Also when you say it was working with the static version that was packaged with the mono build, that was never built with vaapi support so I don't see how; it would have just ignored the vaapi directive in the command line. Those builds came from here https://johnvansickle.com/ffmpeg/ and as you can see no vaapi support: 

                 gcc: 6.4.0
                 yasm: 1.3.0.28.g51af
                 nasm: 2.14rc0

               libass: 0.14.0
               libvpx: 1.6.1-1402-g9639641cd
              libvmaf: 0.6.1
              libx264: 0.152.19 ba24899
              libx265: 2.5+66-dae558b40d99
              libxvid: 1.3.4-1+b2
              libwebp: 0.6.0 
              libzimg: 2.6.1
              librtmp: 2.4
            libgnutls: 3.5.16
            libtheora: 1.2.0alpha1+git
            libfrei0r: 1.6.1-1+b1
           libvidstab: 1.10
          libfreetype: 2.8.1-0.1
          libopenjpeg: 2.3.0 

              libalsa: 1.1.4.1
              libsoxr: 0.1.3b1
              libopus: 1.2.1
             libspeex: 1.2
            libvorbis: 1.3.5
           libmp3lame: 3.100-2
        librubberband: 1.8.1 
       libvo-amrwbenc: 0.1.3-1+b1
    libopencore-amrnb: 0.1.3-2.1+b2
    libopencore-amrwb: 0.1.3-2.1+b2
Edited by dcrdev
Link to comment
Share on other sites
SkyBehind

SkyBehind   23

Posted
Posted (edited)

 

I believe the .net core version packages libva and drivers only for drm.

 

When using direct render manager, you can't use an active device. Do you have any render nodes listed under /dev/dri? If so try changing the "VA API Device:" option in Emby to point to that, for example "/dev/dri/renderD128".

 

Also when you say it was working with the static version that was packaged with the mono build, that was never built with vaapi support so I don't see how; it would have just ignored the vaapi directive in the command line. Those builds came from here https://johnvansickle.com/ffmpeg/ and as you can see no vaapi support:

                 gcc: 6.4.0
                 yasm: 1.3.0.28.g51af
                 nasm: 2.14rc0

               libass: 0.14.0
               libvpx: 1.6.1-1402-g9639641cd
              libvmaf: 0.6.1
              libx264: 0.152.19 ba24899
              libx265: 2.5+66-dae558b40d99
              libxvid: 1.3.4-1+b2
              libwebp: 0.6.0 
              libzimg: 2.6.1
              librtmp: 2.4
            libgnutls: 3.5.16
            libtheora: 1.2.0alpha1+git
            libfrei0r: 1.6.1-1+b1
           libvidstab: 1.10
          libfreetype: 2.8.1-0.1
          libopenjpeg: 2.3.0 

              libalsa: 1.1.4.1
              libsoxr: 0.1.3b1
              libopus: 1.2.1
             libspeex: 1.2
            libvorbis: 1.3.5
           libmp3lame: 3.100-2
        librubberband: 1.8.1 
       libvo-amrwbenc: 0.1.3-1+b1
    libopencore-amrnb: 0.1.3-2.1+b2
    libopencore-amrwb: 0.1.3-2.1+b2

No, I meant 3.2.36.0, or whatever the last stable .Net core was, that's the build I was referring to with the prepackaged ffmpeg.  I was using card0 before, but have also tried renderD128 with the same results.

 

I also have the johnvansickle ffmpeg installed, but can tell from htop that it's using the one included with Emby.

Edited by SkyBehind
Link to comment
Share on other sites
SkyBehind

SkyBehind   23

Posted
Posted

Downgraded to 3.2.36.0 (from 3.2.40.0) and all works again.  This is with both card0 and renderD128, using the ffmpeg and ffprobe that's packaged with Emby.

Link to comment
Share on other sites
pgalbavy

pgalbavy   6

Posted
Posted

I installed from the .deb package yesterday over, I think, .33 and it wiped my settings and everything. I had to re-config from scratch. Not sure what I missed, but all I did was "dpkg -i" over the old version.

Link to comment
Share on other sites
pgalbavy

pgalbavy   6

Posted
Posted

Also, just been looking and there are a lot of unreaped zombie ffmpeg processes (there is a library scan going on though):

 

4   116 19475     1  20   0 8572432 3851900 -   SLsl ?         69:37 /opt/emby-server/system/EmbyServer -programdata
0   116 19511 19475  20   0      0     0 -      Z    ?          0:00 [ffmpeg] <defunct>
0   116 19515 19475  20   0      0     0 -      Z    ?          0:00 [ffmpeg] <defunct>
0   116 21062 19475  20   0      0     0 -      Z    ?          0:02 [ffmpeg] <defunct>
0   116 23557 19475  20   0      0     0 -      Z    ?          0:01 [ffmpeg] <defunct>
0   116 26210 19475  20   0      0     0 -      Z    ?          0:01 [ffmpeg] <defunct>
0   116 28502 19475  20   0      0     0 -      Z    ?          0:01 [ffmpeg] <defunct>
0   116 29266 19475  20   0      0     0 -      Z    ?          0:01 [ffmpeg] <defunct>
0   116 29300 19475  20   0      0     0 -      Z    ?          0:01 [ffmpeg] <defunct>
0   116 29329 19475  20   0      0     0 -      Z    ?          0:01 [ffmpeg] <defunct>
0   116 29361 19475  20   0      0     0 -      Z    ?          0:01 [ffmpeg] <defunct>
0   116 29386 19475  20   0      0     0 -      Z    ?          0:01 [ffmpeg] <defunct>
0   116 29417 19475  20   0      0     0 -      Z    ?          0:01 [ffmpeg] <defunct>
0   116 31664 19475  20   0      0     0 -      Z    ?          0:01 [ffmpeg] <defunct>
Link to comment
Share on other sites
truntemus

truntemus   1

Posted
Posted

Downgraded to 3.2.36.0 (from 3.2.40.0) and all works again.  This is with both card0 and renderD128, using the ffmpeg and ffprobe that's packaged with Emby.

 

Hi After I upgraded to 3.2.40.0  I'm having problems watching my transcoded LiveTV on computers and mobile, even on the same network or outside the network. but directly on the server I can watch it. Im using TVheadend installed on the same server. How can I downgrade to 3.2.36.0

Link to comment
Share on other sites
xavier

xavier   1

Posted
Posted

Downgraded to 3.2.36.0 (from 3.2.40.0) and all works again.  This is with both card0 and renderD128, using the ffmpeg and ffprobe that's packaged with Emby.

how do you downgrade on on ubuntu 16.04 linux server as never downgraded only updated but just getting to many issues with the new m3u section added now nobody can stream from tv guide and need to revert back thanks for your time

Link to comment
Share on other sites
SkyBehind

SkyBehind   23

Posted
Posted

how do you downgrade on on ubuntu 16.04 linux server as never downgraded only updated but just getting to many issues with the new m3u section added now nobody can stream from tv guide and need to revert back thanks for your time

I just installed the old .deb over the newer version. I had it saved but you can probably still pull the older version off GitHub

 

Sent from my Nexus 6 using Tapatalk

Link to comment
Share on other sites
xavier

xavier   1

Posted
Posted

THIS SOUNDS LIKE IT IS CAUSING THE ISSUE - QUOTE FROM ANOTHER POST"So I've spent time reading through everything on the forum about IPTV and M3U tuners.

Is there any reason why we can't treat each M3U tuner as only being able to tune 1 channel from the channel xml list or have that as a user defined setting?
From the reading it seems like the M3U tuner is considered to be "unlimited" streams by default. If limited to 1 stream you could create as many m3u tuners for a source as available connections.
Emby would also be able to mark them available or watching as they are used

Example screenshot of how my tuners would be created if this was the case:
two hdhomeruns - 4x tuners
6 m3u tuners for iptv provider 1 - provider allows 6 concurrent connections
2 m3u tuners for iptv provider 2 - provider also allows you to pay for 6, paying for 2

As they are used, they get set to watching. When all are used it acts just like hdhomeruns and errors out when that source is out of connections. I assumed this was how it would work by default based on how physical tuners worked.

Another option would be allowing us to specify how many connections per m3u source and building that number of virtual tuners for that source. Probably a cleaner way to do it."" 

 

THIS SOUNDS LIKE IT'S EFFECTING PEOPLE LIKE ME WITH A UNLIMITED PLAYLIST THE ISSUE'S? AM I RIGHT IN THINKING I WOULD NEED TO CREATE 300+M3U TUNERS TO ALLOW THAT MANY TO BE ABLE TO VIEW A DIFFERENT CHANNEL?? PLEASE CAN WE REVERT BACK AS I SO DONT SEE THE POINT IN THIS WHAT SO EVER OR PLEASE CAN SOME ONE EXPLAIN HOW TO ACTUALLY ROLL BACK TO BEFORE THE CHANGES PLEASE ON UBUNTU 16.04 LINUX, UNTIL A NEWER RELEASE COMES OUT WITH THE ABILITY TO CHOOSE WEATHER YOU WANT THAT OR NOT AS I DON'T AS IT ISNT HELPING ME OR THE PEOPLE TRYING TO STREAM FROM CHANNELS WITH MY PLAYLISTS.

Link to comment
Share on other sites

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
 Share
Go to topic listing
×
×
  • Create New...