Jump to content

Recommended Posts

cyrenbyren
Posted (edited)

I've not noticed this -

 

I remember you saying you use zfs, right? Have you tried storing the xattrs in the disk inodes as oppose to the default xml that zfs creates? You can do so by setting xattr=sa on the pool.

 

interesting. i'll attempt this as well. i am using zfs at the bottom layer as well.

 

EDIT: no difference. at least not any difference i care to wait for. changing owners on the file system directly takes less than 2 seconds on the underlying folder, while on the nfs share it takes.. well, more time. it took 30 minutes previously, and i've waited for a minute now. i am not patient enough to wait it out :D

Edited by cyrenbyren
mastrmind11
Posted

I've not noticed this -

 

I remember you saying you use zfs, right? Have you tried storing the xattrs in the disk inodes as oppose to the default xml that zfs creates? You can do so by setting xattr=sa on the pool.

I have not tried this but is interesting.  Not really a big deal since I only had to do it when I changed all my media from me to emby.  Thanks for the info though.

Posted (edited)

interesting. i'll attempt this as well. i am using zfs at the bottom layer as well.

 

EDIT: no difference. at least not any difference i care to wait for. changing owners on the file system directly takes less than 2 seconds on the underlying folder, while on the nfs share it takes.. well, more time. it took 30 minutes previously, and i've waited for a minute now. i am not patient enough to wait it out :D

 

I have not tried this but is interesting.  Not really a big deal since I only had to do it when I changed all my media from me to emby.  Thanks for the info though.

 

Yes it makes a big big performance improvement - but sorry should have mentioned that it only applies to new data. So you wont notice a performance gain immediately.

 

Also... 30mins wtf?

Edited by dcrdev
cyrenbyren
Posted

Yes it makes a big big performance improvement - but sorry should have mentioned that it only applies to new data. So you wont notice a performance gain immediately.

 

Also... 30mins wtf?

 

is there a way to force it to write everything down?

 

and yes, wtf is right. :D

Posted

is there a way to force it to write everything down?

 

and yes, wtf is right. :D

 

Only way I know of is zfs send | zfs receive to the same pool

cyrenbyren
Posted (edited)

Only way I know of is zfs send | zfs receive to the same pool

 

just tried this on a fresh folder with a bunch of stuff copied in. doesn't seem to make any difference over nfs. unless the copy operation keeps the old meta somehow? if so, my test was meaningless.

 

EDIT: that is, i did not use zfs send/receive.

Edited by cyrenbyren
mastrmind11
Posted

30 mins seems excessive.  How deep is the recurse?  Does dmesg show any nfs or zfs errors?

cyrenbyren
Posted

30 mins seems excessive.  How deep is the recurse?  Does dmesg show any nfs or zfs errors?

 

no errors from either zfs or nfs.

 

the total amount of items that needs chowning is 120k and change, i think at most five levels deep?

Posted

What are your nfs export parameters?

 

Also hmm I think copy should have been sufficient - in that case I think you must have something else going on.

mastrmind11
Posted (edited)

What are your nfs export parameters?

 

Was just going to ask this too.  @@cyrenbyren have you enabled async in your export params?  It's off by default as of a few releases ago.

Edited by mastrmind11
cyrenbyren
Posted (edited)

What are your nfs export parameters?

 

Also hmm I think copy should have been sufficient - in that case I think you must have something else going on.

 

Flags: rw,relatime,vers=4.0,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,port=0,timeo=600,retrans=2,sec=sys,clientaddr=192.168.1.105,local_lock=none,addr=192.168.1.20

 

EDIT: @@mastrmind11 so no, async is not enabled, unless it is by default.

Edited by cyrenbyren
mastrmind11
Posted

Flags: rw,relatime,vers=4.0,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,port=0,timeo=600,retrans=2,sec=sys,clientaddr=192.168.1.105,local_lock=none,addr=192.168.1.20

 

EDIT: @@mastrmind11 so no, async is not enabled, unless it is by default.

not sure of your linux version/specs so not sure whether it's on by default... used to be a few years ago, the switched it to sync since then.  Try adding the param and see if it makes a difference.

cyrenbyren
Posted (edited)

not sure of your linux version/specs so not sure whether it's on by default... used to be a few years ago, the switched it to sync since then.  Try adding the param and see if it makes a difference.

 

i will have a try, but that will have to be for later unfortunately. thank you for your help today though! and @@dcrdev as well!

Edited by cyrenbyren
Posted (edited)

after updating to the latest stable docker today i have 3 problems... 

 

emby sets no resume point where i can start after stopping....

 

the pushover plugin doesn´t send a message when i watch something

 

nothing is scrobbled to trakt.tv

 

also in the emby backend there isn´t shown who is watching or what....

 

https://pastebin.com/EssiAnjm

 

here is another log - playing from firetv doesn´t even start

 

https://pastebin.com/zrheNVxK

 

edit

 

VAAPI Transcoding also doesn´t work anymore....

 

is their a way to revert back to the last version?

 

the history looks different than in the past....

Edited by b0mb
Posted

after updating to the latest stable docker today i have 3 problems... 

 

emby sets no resume point where i can start after stopping....

 

the pushover plugin doesn´t send a message when i watch something

 

nothing is scrobbled to trakt.tv

 

also in the emby backend there isn´t shown who is watching or what....

 

https://pastebin.com/EssiAnjm

 

here is another log - playing from firetv doesn´t even start

 

https://pastebin.com/zrheNVxK

 

edit

 

VAAPI Transcoding also doesn´t work anymore....

 

is their a way to revert back to the last version?

 

the history looks different than in the past....

 

The logs look perfectly fine. There are no progress reports coming in from any apps. I would suggest reporting that in the section of the community for whichever app you're using. Thanks.

Posted (edited)

i´ve tried playing back via kodi which works but not with resume point, pushover or trakt plugins configured in the emby backend...

 

 

i´ve tried playing back via chrome - doesn´t work

 

also firetv doesn´t work

 

problems appeared after updating to the latest docker that has been released yesterday 

 

edit:

 

nevermind - restarted the container and everything seems to work again ;)

Edited by b0mb
Posted

@@b0mb, please next time follow the guidelines in how to report a problem

 

The purpose of this topic is primarily for Emby Docker announcements. Thanks !

Posted

@@cyrenbyren Didn't think a simple chown could be that taxing. What I can do is only chown when the permissions on the /config top directory don't match, that way it's still guaranteed to work even if permissions are wrong while solving your issue.

cyrenbyren
Posted

@@cyrenbyren Didn't think a simple chown could be that taxing. What I can do is only chown when the permissions on the /config top directory don't match, that way it's still guaranteed to work even if permissions are wrong while solving your issue.

 

that would work perfectly fine for me!

mastrmind11
Posted

Getting ready to try this container in the next few minutes, 1 question:  Is the --volume path supposed to point to the root of the share?  ie, I have my nas shared via NFS using /path/to/mount1/movies, /path/to/mount1/tv, etc.  If I point to /path/to/mount1 will I have access to subfolders?  If not, how does adding new shares as libraries work w/o having to instantiate a new container w/ new --volume args?  I ask because several other containers I use expect an explicit list of volumes (I assume mainly because there will never be a reason to grow the list... sonarr, radarr, etc).  Waiting on this answer before I wind up a real instance.  THanks

Posted

The --volume does indeed point to the root, everything inside will be recursively exposed in the container.

  • Like 1
mastrmind11
Posted

The --volume does indeed point to the root, everything inside will be recursively exposed in the container.

well done.  thanks

Posted

@@cyrenbyren Could you give the beta tag a try? It should start fine now.

mastrmind11
Posted

why is the container named "focused_fermat"?  Please update your install instructions to include "--name emby-server" in the command.... it's a pain in the ass  to have to list containers and copy/paste container id when working with them.  

mastrmind11
Posted

The --volume does indeed point to the root, everything inside will be recursively exposed in the container.

This doesn't appear to be the case.  I can obviously see the root, but nothing under it.  emby is part of the r/w group but not the owner.

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