binhex

[Support] binhex - Emby

Recommended Posts

Posted (edited)

OK, so I've run into one minor issue... My cache disk is filling up quite rapidly.

 

I have /config mapped to /mnt/cache/appdata/binhex-emby, which is the default and is as all my other containers are mapped.

 

Within Emby, I do not have a custom cache path set up, which is what I believe I should do. However... I SSH into my unRAID box and I'm seeing .../appdata/binhex-emby/cache in both /mnt/cache and /mnt/user. My appdata share is set to "Use cache disk = prefer", so it can overflow onto the array if necessary.

 

So I think what I need to do is add a mapping to the docker config something like: /cache -> /mnt/user/embycache, then tell emby to use /cache as its cache path. Does that make sense?

 

Also, the big issue with the cache dir is this:

image.png.09ad27b21b5ea41b08556ee6c7d63e17.png

 

5009 itty bitty cache files only account for 52 MB of data, but because of sector sizes they're taking up 4.9GB of actual disk space!

 

Long story short... does the additional host path in the container pointing to somewhere specifically on the array and not on the cache disk sound like the right way to fix this?

 

Am I the only one running into this issue? Granted my cache disk is only 240GB, but none of my shares are set to use it (other than appdata) - it's really only hosting my docker.img and docker config files at this point.

 

 

Update: on the other hand, I just discovered a big pile of movies that the filebot docker had tucked away that I didn't know existed... :/  That didn't help cache disk utilization. I'll keep an eye on it, but I think that I should be OK for now... I guess I just have to stop NZBGet any time I fire up the fileget docker to ensure it's not stealing away freshly downloaded items.

 

Edited by FreeMan

Share this post


Link to post
Share on other sites
3 hours ago, FreeMan said:

However... I SSH into my unRAID box and I'm seeing .../appdata/binhex-emby/cache in both /mnt/cache and /mnt/user.

Those are the same path, just two different ways of getting there. /mnt/user contains everything on /mnt/cache and /mnt/diskX, that's how user shares work.

 

3 hours ago, FreeMan said:

5009 itty bitty cache files only account for 52 MB of data, but because of sector sizes they're taking up 4.9GB of actual disk space!

Windows THINKS they are taking up that much space, but I seriously doubt they are. If you are curious, you need to figure out the commands to show used space at the actual console.

Hint... du and df. Windows only knows what SMB tells it, which has very little bearing on reality.

Share this post


Link to post
Share on other sites

Yeah, I think the real issue was all those files that filebot had spirited away in the background... My cache drive went from > 70% used to about 35% where it's sitting now. I don't think it was all in those files, but there were quite a few gig chewed up there.

 

off to google du & df - thanks for the tip!

Share this post


Link to post
Share on other sites

Next step - does anyone know how to get the various Emby apps (Android, XBOX, TV) working through a reverse proxy? (he asks hopefully...)

Share this post


Link to post
Share on other sites
3 hours ago, FreeMan said:

It works fine as long as you don't enable nginx authentication on that specific site. I have my emby reverse proxied and it works just fine to android phone apps, don't know about any other apps. The downside is you are relying totally on emby to keep itself secure from hacks, but given how high profile the software is, I figure if it were exploited, it would be newsworthy in the geek community and fixed quickly.

Share this post


Link to post
Share on other sites
10 hours ago, jonathanm said:

It works fine as long as you don't enable nginx authentication on that specific site. I have my emby reverse proxied and it works just fine to android phone apps, don't know about any other apps. The downside is you are relying totally on emby to keep itself secure from hacks, but given how high profile the software is, I figure if it were exploited, it would be newsworthy in the geek community and fixed quickly.

I guess I haven't been clear enough - I've been doing that a lot lately...

 

I want to use nginx as the reverse proxy, LE for security and an emby app and that seems to be a combination that doesn't work.

 

I guess your points about emby's built in security are valid - the drawback is that I have to create a good, strong password for my users (since none of them are at my house to enter their own password), or have them pick one and send it to me. With LE, I had them pick their own passwords and encrypt them, then send me the encrypted results which I put in .htaccess.

 

I guess this isn't a major crisis, that's how I'd been running services for them before emby came along (well, before I switched to emby...), I was just hoping that le/nginx would be a one-stop, single password front door behind which everything else could run password free.

Share this post


Link to post
Share on other sites

and now, on to the next issue... :(

 

Yesterday at 17:50 local time, the docker shut down and now I can't get it to restart. This is the last bit of the log file:

Quote

2018-01-12 10:25:37,184 DEBG 'emby' stderr output:
ffprobe version 3.4 Copyright (c) 2007-2017 the FFmpeg developers
built with gcc 7.2.0 (GCC)
configuration: --prefix=/usr --disable-debug --disable-static --disable-stripping --enable-avisynth --enable-avresample --enable-fontconfig --enable-gmp --enable-gnutls --enable-gpl --enable-ladspa --enable-libass --enable-libbluray --enable-libfreetype --enable-libfribidi --enable-libgsm --enable-libiec61883 --enable-libmodplug --enable-libmp3lame --enable-libopencore_amrnb --enable-libopencore_amrwb --enable-libopenjpeg --enable-libopus --enable-libpulse --enable-libsoxr --enable-libspeex --enable-libssh --enable-libtheora --enable-libv4l2 --enable-libvidstab --enable-libvorbis --enable-libvpx --enable-libwebp --enable-libx264 --enable-libx265 --enable-libxcb --enable-libxvid --enable-shared --enable-version3

2018-01-12 10:25:37,184 DEBG 'emby' stderr output:
libavutil 55. 78.100 / 55. 78.100
libavcodec 57.107.100 / 57.107.100
libavformat 57. 83.100 / 57. 83.100
libavdevice 57. 10.100 / 57. 10.100
libavfilter 6.107.100 / 6.107.100
libavresample 3. 7. 0 / 3. 7. 0
libswscale 4. 8.100 / 4. 8.100
libswresample 2. 9.100 / 2. 9.100
libpostproc 54. 7.100 / 54. 7.100

2018-01-12 10:25:37,434 DEBG 'emby' stderr output:
file:/media/Sport/V8 Supercars/V8 2010/40 - Round 12, Falken Tasmania Challenge, Symmons Plains - Qal, Races 1-2 (12.11.2010 - 14.11.2010)/Symmons.Plains.Sunday.Race.2.7z.001: Invalid data found when processing input

2018-01-12 17:50:21,972 WARN received SIGTERM indicating exit request
2018-01-12 17:50:21,987 DEBG killing emby (pid 40) with signal SIGTERM
2018-01-12 17:50:21,987 INFO waiting for emby to die
2018-01-12 17:50:22,274 DEBG fd 8 closed, stopped monitoring <POutputDispatcher at 47620398561688 for <Subprocess at 47620398559744 with name emby in state STOPPING> (stdout)>
2018-01-12 17:50:22,275 DEBG fd 10 closed, stopped monitoring <POutputDispatcher at 47620389178400 for <Subprocess at 47620398559744 with name emby in state STOPPING> (stderr)>
2018-01-12 17:50:22,277 INFO stopped: emby (exit status 0)
2018-01-12 17:50:22,277 DEBG received SIGCLD indicating a child quit

I can provide more if needed.

 

To be fair, there's no need for the .7z file to be there (and I'm going to remove it to see what happens), but this file was at /Sport/V8 Supercars/2010/... and emby processed it just fine. Because of the way it lists directories, I moved it to /Sport/V8 Supercars/V8 2010/... and now it seems to be throwing this error. The 7z archive is fine - I just extracted it to a test directory without error. I don't, however, feel that this is the issue causing the docker to not start...

 

Any suggestions?

 

TL;DR:

And... problem solved before posting - I'll put this up in case anyone else runs into a similar issue:

 

In my attempts to get emby to work behind the secured nginx reverse-proxy, I'd added an extra container variable to the emby config: /certs -> .../appdata/letsencrypt/keys/<somewhere>  That <somewhere> doesn't exist now after the most recent le update and key file rebuild.

 

Final Resolution:

There was a bug discovered in one of the authentication routines used by LetsEncrypt, so their devs shut off that method and released an update. The LSIO devs grabbed the latest version & released a docker update. That update required some minor configuration changes to make things work again. There are about 5-6 pages of discussion on the lsio-le/nginx support thread in these boards covering it. Since LE wasn't working right, the path pointed to above didn't exist.

Edited by FreeMan
Added the final resolution

Share this post


Link to post
Share on other sites

I've run into a problem similar to @Frostyfruit mentioned here.

 

It seems that I can get .mp4 video files recorded on my cell phone to play, but AVIs, MKVs & MP4s from ripped DVDs or TV captures won't play. I get the " No compatible streams are currently available. Please try again later or contact your system administrator for details." error message.

 

I get loads of ffmpeg-transcode-* log files in //nas/cache/appdata/binhex-emby/logs, so it doesn't seem to be a permissions issue on ffmpeg. I'm attaching a transcode log for an MP4 and an MKV file - I don't see any obvious errors, but I'm not an expert. Both of the files that produced these logs play just fine in VLC on my Win10 box or on my Kodi box, just not in Emby.

 

I'm sure there's something that I've configured wrong in the Emby setup, but I haven't a clue as to what it might be. You've seen evidence of my entire experience with Emby in the posts in this thread - I'm no expert!

 

I'm not sure what config or log info might be helpful, but I'm happy to respond to prompting!

ffmpeg-transcode-MP4.txt

ffmpeg-transcode-MKV.txt

 

Update: I'm getting the failure to play on Win7 with Chrome and Win10 with Firefox. However, it plays just fine on my phone via the Emby app. This works, except that the kids are not going to be connecting via an app due to the inability to work through a password-protected reverse-proxy on the apps...

 

Further Update: If I connect to Emby locally in my browser, I can play movies just fine. If I try to connect via my external domain name, it doesn't work. This probably explains why the Emby app would play - it's connected via internal IP address

Edited by FreeMan

Share this post


Link to post
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


Copyright © 2005-2017 Lime Technology, Inc. unRAID® is a registered trademark of Lime Technology, Inc.