Jump to content

Newest update refuses to connect


erikblues
Go to solution Solved by erikblues,

Recommended Posts

erikblues

What issue do you think needs fixing? We are simply asking ffmpeg to perform a conversion. It is very possible that for your system, the single thread count is the appropriate value.

 

oh sorry @@Luke, I just assumed this is a bug since:

  • Before the latest update I was not facing this issue when transcoding
  • I did not have an upgraded account yet, but I was able to transcode SD movies in realtime
  • now I cant convert an SD movie in 12 hours

So I feel like something in the newest version is incompatible with the DS414play,, don't you think so?

 

In another forum post (link below) a user complains about the same problem, but he is using the DS418play, which has more RAM available. In his case, emby server is "just" using more and more RAM, but he still has enough RAM to run the system. But since my DS415play only has 1GB, once the server hits the RAM cap I start getting I/O Wait issues.

 

Since I found a temporary "solution" for now, I think we can close this topic and continue this discussion in this post which is targeting what I think is the real issue: 

Emby 3.5.3 on NAS not releasing memory

Link to comment
Share on other sites

solabc16

Hello @erikblues 

 

I will look at this further next week, but just to avoid any ambiguity for other readers of the thread, this issue and the one you reference are different.

 

One is a suspected memory leak in the runtime environment, this is system resource starvation due to memory consumption by FFmpeg.

 

Had you previously tried using this experimantal feature (https://emby.media/community/index.php?/topic/43282-hw-transcoding-on-evansport-ds415playds214play-machines/?hl=ds415play) before upgrading?

 

Best

- James

Link to comment
Share on other sites

erikblues

Hi @@solabc16,

 

One is a suspected memory leak in the runtime environment, this is system resource starvation due to memory consumption by FFmpeg.

 

Good to know, I thought they were related. Thanks!

 

 

 

No, I was using the normal installation with only 3-4 plugins installed (as I have it now).

 

I also upgraded my account to a paid Emby account, so before this version I was only doing "real time" transcoding since file conversion is unavailable in the free version. But if I was able to stream SD movies in realtime (usually without problems), then I think the same movie transcoded should happen in less than 12 hours.

 

I also disabled all possible other apps that are installed on the NAS (download station, log center etc), to free up some RAM, but it is still not enough for what the NAS is consuming since the update as you can see in this graph of memory consumption in the last year (note, before the update the download station, log center, photo station and other apps were also running in the background and are now disabled. still, RAM usage is capping at 80%, which is when I/O Wait overflow starts):

5bfb1be1b3dcb_ScreenShot20181125at230153

 

 

Do you think the DS415play is to old to run Emby?

Link to comment
Share on other sites

solabc16

Hi @@erikblues

 

There's a lot of end users successfully running on this platform, so I definitely wouldn't put it in the category of 'too old'.

 

Of course, the experience will depend on what features you have enabled and how you are using it.

 

As with many software applications, not all hardware platforms will be capable of delivering all of the features at an acceptable level of performance.

 

When you mention 'I was able to stream SD movies in realtime' above, were these transcoding or direct playing? 

 

Best

- James

  • Like 1
Link to comment
Share on other sites

erikblues

When you mention 'I was able to stream SD movies in realtime' above, were these transcoding or direct playing?

Hi James,

 

They were transcoding, and sometimes it was unable to transcode them fast enough. Depending on the file, I would have to let it load for a while before playing and it would stay stuck again near the end (720-1080, 24min episode).

 

That is why I upgraded, so I would be able to convert the files before playing them.

 

But now, a file which I was able to transcode in “almost real-time” in 30-60mins now wasn’t finishing conversion in 12 hours.

 

Now that I changed it to “use one CPU thread” it is working. Slower, but it works. About 3-4 hours for the same file.

 

I hope this information is useful somehow. Thanks for all your effort guys. It’s really appreciated! :)

Link to comment
Share on other sites

solabc16

Hello @@erikblues

 

Thanks for the information, that's useful. I wouldn't expect the two different scenarios to use the same FFmpeg command line, so this is the most likely cause of the differing behaviour.

 

With your system set to “use one CPU thread", if you sort the processes by name in resource monitor, can you take a screenshot of the FFmpeg processes (like before) with a conversion running.

 

Best

- James

Link to comment
Share on other sites

solabc16

Thanks @@erikblues

 

This memory is used across all of the listed processes - they are not using 91.6MB each.

 

The same with FFmpeg, in this specific case. A different analysis would be needed if you had two or more FFmpeg processes running.

 

What you are seeing is the threads that are part of the process. These look ok and I wouldn't say 'taking up so much RAM'.

 

The DS415play is a dual core, four thread machine - this is why you are seeing the FFmpeg process running at a consistent ~25% CPU. This relates to the configuration setting "use one CPU thread” you made.

 

Best

- James

  • Like 1
Link to comment
Share on other sites

erikblues

Thanks for clearing that up @solabc16 

 

Since today the server is working MUCH better, even though I changed nothing in the settings.

 

Look at this 24h log:

Notice how between 12 and 14h the server went back to normal and is now handling the same conversion list (it has been running since yesterday) much better. RAM usage dropped during the same time, and I/O Wait went back to normal. This is the way the server was working before the update and is what I mean when I say that something isn't acting right since the update.

 

I generated a new log right away and hope it gives you some insight on this:

sendlogs_Weitenau_synology_evansport_415play_20181126T181631UTC.tgz  

 

 

 

 

 

 

5bfc38c2b86e1_ScreenShot20181126at191200

 

5bfc38da15d02_ScreenShot20181126at191209

Edited by erikblues
Link to comment
Share on other sites

erikblues

After 2 days running fine converting media, it sometimes spiked up but seemed to run smoothly most of the time.

But today for some reason it TOTALLY spiked again. Wasn't able to do "sudo ./sendlogs" because it gave me "ERROR: Failed to create the log archieve."

I had to stop the conversion to be able to send the log.

 

Any idea what is causing this? Maybe the size of the file being converted?

 

Log file:

 

sendlogs_Weitenau_synology_evansport_415play_20181130T205403UTC.tgz  

 

 

 

5c01a3a56e5a1_ScreenShot20181130at215244

Link to comment
Share on other sites

solabc16

Hello @@erikblues

 

Thanks for the update and the logs, I'll take a look at those in the morning.

 

I've fixed the issue that causes the ""ERROR: Failed to create the log archive.", that will be in the next release.

 

From what I've looked at so far, the variable at play here is the file itself being transcoded; anything else I believe to be coincidental. This will provide an additional data point, that should help us understand it better.

 

Best

- James

  • Like 1
Link to comment
Share on other sites

erikblues

@@solabc16

 

I've fixed the issue that causes the ""ERROR: Failed to create the log archive.", that will be in the next release.

 

From what I've looked at so far, the variable at play here is the file itself being transcoded; anything else I believe to be coincidental. This will provide an additional data point, that should help us understand it better.

 

That makes sense. 

 

I think now is time I should stop sending you logs and wait for the next release :P

but please don't hesitate to let me know if I can send you anything else that can help.

 

And thanks for correcting that log error James :)

Link to comment
Share on other sites

erikblues

Other file (much bigger file), 2 threads, running on full CPU for 24h.

 

Had some I/O when I tried to use the NAS while conversion was happening. After that is took a while to stabalize again.

 

Maybe it helps:

sendlogs_Weitenau_synology_evansport_415play_20181202T153932UTC.tgz  

 

 

 

5c03fc81f3f61_ScreenShot20181202at163359

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