Jump to content

Docker


Luke

Recommended Posts

cyrenbyren

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

mastrmind11

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.

Link to comment
Share on other sites

dcrdev

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

cyrenbyren

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

Link to comment
Share on other sites

dcrdev

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

Link to comment
Share on other sites

cyrenbyren

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

mastrmind11

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

Link to comment
Share on other sites

cyrenbyren

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?

Link to comment
Share on other sites

dcrdev

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.

Link to comment
Share on other sites

mastrmind11

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

cyrenbyren

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

mastrmind11

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.

Link to comment
Share on other sites

cyrenbyren

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

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

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.

Link to comment
Share on other sites

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

alucryd

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

Link to comment
Share on other sites

cyrenbyren

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

Link to comment
Share on other sites

mastrmind11

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

Link to comment
Share on other sites

alucryd

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

  • Like 1
Link to comment
Share on other sites

mastrmind11

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

well done.  thanks

Link to comment
Share on other sites

mastrmind11

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.  

Link to comment
Share on other sites

mastrmind11

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.

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
×
×
  • Create New...