Unraid Emby Docker Issue

[PaulE123 20]

Hi all, I've tried posting this in the Unraid forum's thread for this docker, but nothing back so far. I hope it's ok to try here?

I'm having a very intermittent problem with a "Docker Image Disk Utilization of 100%" error popping up for me. I'm on Unraid 6.11.1 (though this has happened to me on previous release versions too), and running the latest Emby as of writing (4.7.8.0, though again, previous releases threw this error up too.) Last night I got an alert about this error, and then ~5 mins later another alert to state the utilization had returned to normal levels, so I wasn't able to check anything really. I feel it's a transcoding issue, and something screwed up with my directory config perhaps? My cache pool is x2 1TB SSD's in a BTRFS pool. I do share parts of my Emby library with select family members, and looking at Emby when the error popped up last night, there was indeed a family member logged in a consuming media. 

My setup is as follows:

Folder on cache pool for Emby transcoding is - "/mnt/cache/appdata/EmbyServer/transcode/transcoding-temp"

My Emby server is then configured to use the container path of "/Transcoding" which is pointed to the host path of "/mnt/cache/appdata/EmbyServer/transcode"

If I then play media on my LAN and select a low quality version, I can see the "/mnt/cache/appdata/EmbyServer/transcode/transcoding-temp" starts to become populated with files/folders....so I THINK Emby is correctly transcoding onto my SSD pool, and NOT within the docker image itself?

The only other x3 dockers I'm using are Swag/DuckDNS for reverse proxy access, and Krusader (which stays disabled until needed) which is why I think it's an Emby issue...

Can anyone help/advise?

[Q-Droid 989]

Can you attach the embyserver log and ffmpeg log from the time(s) when the alerts were thrown?

 

[samuelqwe 317]

Do you happen to use Infuse by any chance? 

[Luke 42079]

hi @PaulE123 

 

Hi there, let's look at an example. Please attach the information requested in how to report a media playback issue. Thanks!

 

[PaulE123 20]

15 hours ago, Luke said:

hi @PaulE123 

 

Hi there, let's look at an example. Please attach the information requested in how to report a media playback issue. Thanks!

 

Will do Luke, cheers. I'll grab the required logs etc later on

20 hours ago, Q-Droid said:

Can you attach the embyserver log and ffmpeg log from the time(s) when the alerts were thrown?

 

As above, cheers. 

15 hours ago, samuelqwe said:

Do you happen to use Infuse by any chance? 

Nope, don't use it.

[PaulE123 20]

Ok so here's the chain of events & attached logs:

19:51 - Telegram message to alert of disk utilization of image file docker.img

19:56 Telegram message to state utilization has returned to normal

ffmpeg log ending in 01_1 was generated at 19:51

ffmpeg log ending in 32_1 was generated a few seconds later

** there are x4 more ffmpeg logs all generated within the minute of 19:51, and all appear similar. I've posted the first two, and redacted some personal info from them. I can post the other x4 if needed, but they all appear the same.

The hardware_detection log posted here, is from a few hours previous to the error. There was another hardware detection log generated a few hours after the warning too, but none appear to correlate with the time of error.

The embyserver log is also from a few hours previous, and similarly, another one was generated a few hours after the error too. Both have been posted here, as one is much bigger than the other.

*** I'm not sure why there are x6 ffmpeg logs generated, is it possible the user was starting episodes and stopping them a few seconds later maybe? Could that in turn lead to my issue?

hardware_detection-63800759251.txt embyserver-63800759245.txt embyserver-63800784000.txt ffmpeg-remux-3ae9099d-b5a4-44e6-8e76-b93da5922a32_1.txt ffmpeg-remux-a0aab435-7072-45f2-a4de-91b74e428701_1.txt

[samuelqwe 317]

9 hours ago, PaulE123 said:

Nope, don't use it.

All good, I’ve been investigating a similar issue on my side and it seems to happen when I use Infuse. That’s why I asked if you used it.

Hopefully Luke can point out what’s causing the issue in your case.

[Q-Droid 989]

Nothing stands out. Your transcoding temp appears to be going to the right location. You might want to check logging and other activity from all containers to make sure those destinations are outside of the docker images. It seems to be a common thing with Unraid and many results show up when Googling the alert message.

One thing I did notice was that the remuxes did not throttle though that shouldn't trigger the alert if the path is external to the container.

[Luke 42079]

How much space was used?

[PaulE123 20]

13 hours ago, Luke said:

How much space was used?

The docker.img is set for 40GB, so given the alert said 100% utilization, I'm assuming something used up all 40GB

16 hours ago, Q-Droid said:

Nothing stands out. Your transcoding temp appears to be going to the right location. You might want to check logging and other activity from all containers to make sure those destinations are outside of the docker images. It seems to be a common thing with Unraid and many results show up when Googling the alert message.

One thing I did notice was that the remuxes did not throttle though that shouldn't trigger the alert if the path is external to the container.

How do you mean remuxes didn't throttle? Is it they didn't transcode and instead they used direct play?

[Luke 42079]

2 hours ago, PaulE123 said:

The docker.img is set for 40GB, so given the alert said 100% utilization, I'm assuming something used up all 40GB

How do you mean remuxes didn't throttle? Is it they didn't transcode and instead they used direct play?

How large was the video that it was converting? 

[PaulE123 20]

17 minutes ago, Luke said:

How large was the video that it was converting? 

A regular high definition 1080p TV episode, circa ~4GB or thereabouts Luke. I'm not even sure it was converting/transcoding, seems like it direct played and uploaded from my end? I could he wrong there, but the full file size of the file in question is 10x smaller than the docker.img 

[Q-Droid 989]

6 hours ago, PaulE123 said:

The docker.img is set for 40GB, so given the alert said 100% utilization, I'm assuming something used up all 40GB

How do you mean remuxes didn't throttle? Is it they didn't transcode and instead they used direct play?

You'd have to look at your containers to find the one(s) using up the space in the image file.

Not throttling is unlikely to be contributing to your problem unless the files are being created inside the container. Throttling is more of a workload efficiency feature for transcode or remux and it slows down the conversion once a reasonable buffer is reached. Your two posted sessions were very short and remux is very fast yet the converter continued at full speed until the sessions ended, past the "reasonable buffer" point. It could make the system use more resources than needed if it were to convert a full movie or episode to the end but a user only watches a few minutes or the session has to restart for some reason.

 

[PaulE123 20]

Just wondering if anyone else has an ideas on this? The only dockers I have are emby, krusader (which stays offline until needed), swag and duckdns for reverse proxy use under emby...i don't have anything else, and I don't think the mappings are off for any of them? 

[chacawaca 109]

go in setting, docker

turn off docker then you can change docker.img size

 

It can be recycle bin from krusader or other app that do a lot of log file.

[Luke 42079]

On 10/13/2022 at 6:05 AM, PaulE123 said:

Just wondering if anyone else has an ideas on this? The only dockers I have are emby, krusader (which stays offline until needed), swag and duckdns for reverse proxy use under emby...i don't have anything else, and I don't think the mappings are off for any of them? 

Hi.  Can you try sideloading our standard android app on the same device and see how that compares?

https://emby.media/emby-for-android.html

Thanks.

 

[seanbuff 1318]

On 15/10/2022 at 02:36, Luke said:

Hi.  Can you try sideloading our standard android app on the same device and see how that compares?

https://emby.media/emby-for-android.html

Thanks.

 

???

OP is talking about an issue with Emby Server on Docker. How is this related?

 

[Luke 42079]

15 hours ago, seanbuff said:

???

OP is talking about an issue with Emby Server on Docker. How is this related?

 

Because he's playing from the Android TV app.

[Luke 42079]

@PaulE123 are you able to try this?

[PaulE123 20]

On 10/17/2022 at 7:57 PM, Luke said:

@PaulE123 are you able to try this?

Hi Luke, sincere apologies I've only seen this now. I'm a tad confused, I do use the android TV app at home, but those with WAN access via my Emby Premiere may/may not use this...and I'm not sure there's a way to pinpoint what app is causing the docker.img to fill up? It hasn't happened since I originally posted in this thread, and the last instance of it before then was probably six months ago...but if you think it helps, I can definitely sideload the official app on my end anyway. 

@chacawaca Increasing the size of the docker.img file isn't really a solution, it's set to 30GB already which should be absolutely more than enough. Krusader is used extremely infrequently, and wasn't in use at all when this alert popped. The only other two dockers are swag and duckdns... 

[Q-Droid 989]

Have you checked the container sizes to see how much is used and by which ones? I think this is built in to unraid and visible from the docker tab. 

 

[PaulE123 20]

On 11/2/2022 at 8:21 PM, Q-Droid said:

Have you checked the container sizes to see how much is used and by which ones? I think this is built in to unraid and visible from the docker tab. 

 

Yep, it's easily doable from within the Unraid GUI (docker page). It shows (for my x4 dockers) the total size is 2.93GB, obviously well within the 30GB docker.img file size. The problem is, when this error pops up, it returns to normal within ~5 mins or so, giving me a very small window of opportunity to fix it. @Luke's suggestion above (sideloading the Android app) is something I'm sure about, because I the only Emby app I use at home is via Nvidia Shield (Android TV app)...

[Luke 42079]

On 11/5/2022 at 6:31 AM, PaulE123 said:

Yep, it's easily doable from within the Unraid GUI (docker page). It shows (for my x4 dockers) the total size is 2.93GB, obviously well within the 30GB docker.img file size. The problem is, when this error pops up, it returns to normal within ~5 mins or so, giving me a very small window of opportunity to fix it. @Luke's suggestion above (sideloading the Android app) is something I'm sure about, because I the only Emby app I use at home is via Nvidia Shield (Android TV app)...

Were you able to sideload?

[PaulE123 20]

On 11/6/2022 at 7:15 PM, Luke said:

Were you able to sideload?

Luke, am I to sideload/install the app on my phone, or on the nvidia shield? Also, how will that have any bearing on things if the issue is caused by transcoding by users over WAN and not me doing it over LAN (ie, what if the issue isn't being caused by me viewing/watching, and as such, it's irrelevant what app/client I'm personally using?)

[Luke 42079]

11 hours ago, PaulE123 said:

Luke, am I to sideload/install the app on my phone, or on the nvidia shield? Also, how will that have any bearing on things if the issue is caused by transcoding by users over WAN and not me doing it over LAN (ie, what if the issue isn't being caused by me viewing/watching, and as such, it's irrelevant what app/client I'm personally using?)

The shield, if that's the device that had the problem. Thanks.