FreeNAS plugin

[albrown 0]

Yes if you shutdown the jail the alias IP isn't created. I'm specifically talking about having the jail (regardless of the plugin status).

 

Since the ping works I would check 'sockstat' to make sure emby is actually listening on the port you expect it to.

 

root@emby_1:/ # sockstat

USER COMMAND PID FD PROTO LOCAL ADDRESS FOREIGN ADDRESS

emby mono-sgen 12192 39 tcp4 *:8096 *:*

emby mono-sgen 12192 40 tcp4 *:8920 *:*

emby mono-sgen 12192 41 udp4 *:1900 *:*

emby mono-sgen 12192 42 udp4 *:7359 *:*

emby mono-sgen 12192 43 udp4 127.0.0.1:52985 *:*

emby mono-sgen 12192 44 udp4 192.168.23.190:11596 *:*

emby mono-sgen 12192 45 udp4 127.0.0.1:64467 *:*

emby mono-sgen 12192 46 udp4 192.168.23.190:22509 *:*

emby mono-sgen 12192 52 tcp4 192.168.23.190:42007 192.168.23.175:1584

root python2.7 8262 3 tcp4 192.168.23.190:12346 *:*

root cron 7958 4 dgram -> /var/run/logpriv

root syslogd 7904 4 dgram /var/run/log

root syslogd 7904 5 dgram /var/run/logpriv

root syslogd 7904 6 udp6 *:514 *:*

root syslogd 7904 7 udp4 *:514 *:*

 

I think it is 8096 right?

[josh4trunks 70]

 

root@emby_1:/ # sockstat

USER COMMAND PID FD PROTO LOCAL ADDRESS FOREIGN ADDRESS

emby mono-sgen 12192 39 tcp4 *:8096 *:*

emby mono-sgen 12192 40 tcp4 *:8920 *:*

emby mono-sgen 12192 41 udp4 *:1900 *:*

emby mono-sgen 12192 42 udp4 *:7359 *:*

emby mono-sgen 12192 43 udp4 127.0.0.1:52985 *:*

emby mono-sgen 12192 44 udp4 192.168.23.190:11596 *:*

emby mono-sgen 12192 45 udp4 127.0.0.1:64467 *:*

emby mono-sgen 12192 46 udp4 192.168.23.190:22509 *:*

emby mono-sgen 12192 52 tcp4 192.168.23.190:42007 192.168.23.175:1584

root python2.7 8262 3 tcp4 192.168.23.190:12346 *:*

root cron 7958 4 dgram -> /var/run/logpriv

root syslogd 7904 4 dgram /var/run/log

root syslogd 7904 5 dgram /var/run/logpriv

root syslogd 7904 6 udp6 *:514 *:*

root syslogd 7904 7 udp4 *:514 *:*

 

I think it is 8096 right?

 

yeah 8096 which is the default. The link should work, not sure why it isn't working for you.

[albrown 0]

yeah 8096 which is the default. The link should work, not sure why it isn't working for you.

 

Me too, thanks you for suggesting something I wouldn't have known to check (or how to). 

[kjp4756 41]

Just so you know the patches razzfazz posted earlier don't appear to work with mono 4.2.2.10.

 

The patches appear to apply successfully, however the library monitor crashes in emby with an error along the lines of "unkown filename".  It was the same error that I got before the patches.

[razzfazz 11]

Just so you know the patches razzfazz posted earlier don't appear to work with mono 4.2.2.10.

 

The patches appear to apply successfully, however the library monitor crashes in emby with an error along the lines of "unkown filename".  It was the same error that I got before the patches.

 

 

Odd, they seem to work just fine here on plain FreeBSD with the new port version.

 

Can you post the full error message?

Edited January 24, 2016 by razzfazz

[razzfazz 11]

Also, for what it's worth, KeventWatcher.cs didn't actually change at all between 4.2.1.124 and 4.2.2.10: both are at commit 9820f6e14857088898ca319d40bceb2770f3d16a.

Edited January 24, 2016 by razzfazz

[albrown 0]

Me too, thanks you for suggesting something I wouldn't have known to check (or how to). 

 

Created a normal jail and manually installed emby-server to it did a bit of configuration and opened the url came straight up.  Added storage to the jail and created a library and it stared scanning the TV shows straight in.

 

I'm not sure what's up with the Plugin but this path worked and that one didn't. 

 

Thanks for the help for those that had suggestions.  I appreciate it.

 

Al

[josh4trunks 70]

Created a normal jail and manually installed emby-server to it did a bit of configuration and opened the url came straight up. Added storage to the jail and created a library and it stared scanning the TV shows straight in.

 

I'm not sure what's up with the Plugin but this path worked and that one didn't.

 

Thanks for the help for those that had suggestions. I appreciate it.

 

Al

sounds good, just realize if you install emby from pkg you'll want to compile ffmpeg from ports and enable the options mentioned in embys port (ASS,LAME,OPUS,X265)

[kjp4756 41]

Odd, they seem to work just fine here on plain FreeBSD with the new port version.

 

Can you post the full error message?

I'm not sure what is going on now.  The patch fails.  I've even deleted the whole mono subdirectory and recreated everything.

root@emby:/usr/ports/lang/mono # make
===>   mono-4.2.2.10 depends on file: /usr/local/sbin/pkg - found
===> Fetching all distfiles required by mono-4.2.2.10 for building
===>  Extracting for mono-4.2.2.10
=> SHA256 Checksum OK for mono-4.2.2.10.tar.bz2.
=> SHA256 Checksum OK for 932359f3d627da13408350b1172ceb63c30f6327.diff.
=> SHA256 Checksum OK for 2af882232ce4961fdbe1ba0ae36246456bb1fbfb.diff.
===>  Patching for mono-4.2.2.10
===>  Applying distribution patches for mono-4.2.2.10
===>  Applying FreeBSD patches for mono-4.2.2.10
3 out of 10 hunks failed--saving rejects to mcs/class/System/System.IO/KeventWatcher.cs.rej
=> Patch patch-KeventWatcher.c failed to apply cleanly.
*** [do-patch] Error code 1
 
Stop in /usr/ports/lang/mono.

I've attached the reject file and the patch I'm using in the files directory.

 

 

EDIT: I think I see what's going on now.  The updated freebsd port has some of the fixes in your one commit that I'm using for the patch.

 

 

Update to 4.2.2.10 [1]

While here, add patch to increase FD limit for kqueue-based FileSystemWatcher
[2].

PR:        205902 [1], 205919 [2]
Submitted by:    feld [1], razzfazz@[member="gmail"].com [2]

patch-KeventWatcher.c .txt

KeventWatcher.cs.rej.txt

Edited January 24, 2016 by kjp4756

[albrown 0]

sounds good, just realize if you install emby from pkg you'll want to compile ffmpeg from ports and enable the options mentioned in embys port (ASS,LAME,OPUS,X265)

 

Thanks, I will do that.  So far sorting out a couple minor things with permissions to the library files.  Seems somehow when I copied the files from the source to the NAS that some of the directories didn't get (or keep) the correct permissions.

 

At this point I'm mounting the library as read-only to emby while I test and try to build some trust in the software.  

 

Thanks again for the reminder I'll put it near the top of my testing list.

[razzfazz 11]

 

I'm not sure what is going on now.  The patch fails.  I've even deleted the whole mono subdirectory and recreated everything.

root@emby:/usr/ports/lang/mono # make
===>   mono-4.2.2.10 depends on file: /usr/local/sbin/pkg - found
===> Fetching all distfiles required by mono-4.2.2.10 for building
===>  Extracting for mono-4.2.2.10
=> SHA256 Checksum OK for mono-4.2.2.10.tar.bz2.
=> SHA256 Checksum OK for 932359f3d627da13408350b1172ceb63c30f6327.diff.
=> SHA256 Checksum OK for 2af882232ce4961fdbe1ba0ae36246456bb1fbfb.diff.
===>  Patching for mono-4.2.2.10
===>  Applying distribution patches for mono-4.2.2.10
===>  Applying FreeBSD patches for mono-4.2.2.10
3 out of 10 hunks failed--saving rejects to mcs/class/System/System.IO/KeventWatcher.cs.rej
=> Patch patch-KeventWatcher.c failed to apply cleanly.
*** [do-patch] Error code 1
 
Stop in /usr/ports/lang/mono.

I've attached the reject file and the patch I'm using in the files directory.

 

 

EDIT: I think I see what's going on now.  The updated freebsd port has some of the fixes in your one commit that I'm using for the patch.

Update to 4.2.2.10 [1]

While here, add patch to increase FD limit for kqueue-based FileSystemWatcher
[2].

PR:        205902 [1], 205919 [2]
Submitted by:    feld [1], razzfazz@[member="gmail"].com [2]

 

 

Yeah, that one patch was incorporated into the port.

Edited January 24, 2016 by razzfazz

[kjp4756 41]

Ok got it working.  I just removed their patch from the Makefile and distinfo and used your commit.  Seems to work now.

[razzfazz 11]

This version should apply cleanly on top of everything else in the FreeBSD port.

[razzfazz 11]

@@razzfazz

Do you mind creating another freebsd bug report to add your entire patch to freebsd's ports tree?

If this gets accepted, then we can be sure all FreeBSD users can enable realtime monitoring without experiencing crashes.

 

Filed as PR 206593.

Edited January 25, 2016 by razzfazz

[bmcclure937 3]

Thanks for the great work making this open media server available on FreeNAS! I am looking forward to installing the Emby plugin tonight and tinkering with it.

[kjp4756 41]

@@josh4trunks

 

Today I discovered a problem with the init script of the freebsd port of emby-server.  I see the same script is used in the freenas plugin @ /usr/pbi/etc/rc.d/emby-server

 

In the pre-start section of that script it is forcing the timezone to UTC.  For me this was causing the air dates of shows to be a day off.  You should probably think about removing the ":$(TZ=UTC)" and "export UTC" from the pre-start section of that script.  That will force emby to use the localtime of the jail.

[josh4trunks 70]

@@woodsb02 was there a reason this was added to the init? is it required that TZ be set?

 

the ":" in the front mean the script shouldn't overwrite TZ if it's already set but I'm not sure if the system can already have the proper time from other methods.

[kjp4756 41]

@@woodsb02 was there a reason this was added to the init? is it required that TZ be set?

 

the ":" in the front mean the script shouldn't overwrite TZ if it's already set but I'm not sure if the system can already have the proper time from other methods.

I believe the TZ variable is used to override what ever /etc/localtime is.  It's not set otherwise.  I think at one point thetvdb provided the tv air dates differently and setting TZ to UTC was a workaround for that.  

 

Hopefully we hear back from the port maintainer because that is the place it would need to be taken care of.

[leetxjd 2]

I believe the TZ variable is used to override what ever /etc/localtime is.  It's not set otherwise.  I think at one point thetvdb provided the tv air dates differently and setting TZ to UTC was a workaround for that.  

 

Hopefully we hear back from the port maintainer because that is the place it would need to be taken care of.

That would explain why my guide is off by 6 hours. I use schedules direct through MediaPortal for LiveTV.

 

I would really like this fixed.

[woodsb02 17]

@@woodsb02 was there a reason this was added to the init? is it required that TZ be set?

 

the ":" in the front mean the script shouldn't overwrite TZ if it's already set but I'm not sure if the system can already have the proper time from other methods.

Hi everyone,

I set TZ value to UTC because otherwise mono was throwing a number of System.TimeZoneNotFound exceptions if it was not set. Note that if the variable is already set it does not get overridden.

 

I understand that mono should have instead used /etc/localtime to determine the timezone, but it was not doing that at the time, and this helped avoid the error.

 

I have just done a quick search and came across this update to mono which may have fixed this behavior:

https://github.com/mono/mono/pull/1860

 

I will do some experimenting over the next couple of days and change the init script with the next release if it is no longer required.

 

Note: a quick work around in the mean time is to simply set the TZ variable for the mono user in the jail.

[spencerisadog 4]

@@josh4trunks

 

Today I discovered a problem with the init script of the freebsd port of emby-server.  I see the same script is used in the freenas plugin @ /usr/pbi/etc/rc.d/emby-server

 

In the pre-start section of that script it is forcing the timezone to UTC.  For me this was causing the air dates of shows to be a day off.  You should probably think about removing the ":$(TZ=UTC)" and "export UTC" from the pre-start section of that script.  That will force emby to use the localtime of the jail.

 

I also have this problem with the dates being a day off.  I just learned to deal with it, however, I will agree that it caused significant confusion at first.

[josh4trunks 70]

Hi everyone,

I set TZ value to UTC because otherwise mono was throwing a number of System.TimeZoneNotFound exceptions if it was not set. Note that if the variable is already set it does not get overridden.

 

I understand that mono should have instead used /etc/localtime to determine the timezone, but it was not doing that at the time, and this helped avoid the error.

 

I have just done a quick search and came across this update to mono which may have fixed this behavior:

https://github.com/mono/mono/pull/1860

 

I will do some experimenting over the next couple of days and change the init script with the next release if it is no longer required.

 

Note: a quick work around in the mean time is to simply set the TZ variable for the mono user in the jail.

where were you seeing the mono errors related to no timezone? in the emby log? my pbi builds always fail when compiling emby if I don't have TZ set.

[woodsb02 17]

where were you seeing the mono errors related to no timezone? in the emby log? my pbi builds always fail when compiling emby if I don't have TZ set.

To be honest I can't remember exactly where I was seeing them... But I remember this was causing me difficulties at one point and when I found I simply had to set TZ I made this easy fix. Will do some testing this weekend and get back to you.

[scharbag 15]

Just wondering if 3.0.5871 release for FreeNAS is going to be made available?  Also, if there is any testing or help i can give, let me know.

 

Cheers,

[josh4trunks 70]

I was waiting for a decision from @@woodsb02 on the timezone thing. wanted to get that resolved. I could just build a release with the changes, just don't want it brake things.