Hard Drive pegged at 100% during recording, nearly unusable

[jcbeaver76 3]

I'm running 4.6.4.0 on a Windows 10 computer with a dedicated hard drive for media files.  When recording even a single show, the drive usage is pegged at 100% and makes Emby nearly unusable to watch something else.  Load times are delayed and everything is choppy.  Prime example is last night I was recording a pre-season football game and about an hour after the start of the game i started to watch from the beginning.  Since the game was still recording the play back was nearly useless.  Pausing every few seconds.

From a hardware standpoint I'm running a decent processor, plenty of memory and the disk that is getting maxed is a 2TB 5400rpm spinning disk.  In this past this was not a problem (old computer that died, albeit with different hardware).

Any thoughts?

[Carlo 4561]

Hi, How many drives do you have in this computer?

I ask this because DVR and Live TV playback of recordings in progress are one of the toughest things you can do in Emby IO wise at present.

Being able to set the transcode temp folder to a different disc then the recording will help. If you can add a cheap SSD to use for transcoding temp folder you're IO issue will be substantially reduced and breath new life in your system.

 

[jcbeaver76 3]

11 minutes ago, cayars said:

Hi, How many drives do you have in this computer?

I ask this because DVR and Live TV playback of recordings in progress are one of the toughest things you can do in Emby IO wise at present.

Being able to set the transcode temp folder to a different disc then the recording will help. If you can add a cheap SSD to use for transcoding temp folder you're IO issue will be substantially reduced and breath new life in your system.

 

I have 2.  An OS 500GB SSD and the media disk at 2TB 5400rpm.  I did move the "emby-cache" folder last night to the SSD but it might have already been too late.  It was previously on the spinning disk.

[GrimReaper 4749]

4 minutes ago, jcbeaver76 said:

I did move the "emby-cache" folder last night

You should move your transcode-temp folder (Dashboard>Transcoding tab>Transcoder temporary path). 

[GrimReaper 4749]

19 minutes ago, jcbeaver76 said:

OS 500GB SSD

It wound really be advisable, as @cayars said, to obtain some cheapo SSD for that dedicated function, else you'll be spending those TBWs quite a lot on your main drive and possibly invite instability throughout. 

 

[jcbeaver76 3]

41 minutes ago, GrimReaper76 said:

You should move your transcode-temp folder (Dashboard>Transcoding tab>Transcoder temporary path). 

Thanks.  I had the transcoding temp in the emby-cache folder and didn't change that location.  Forgot it was a separate setting.  Will give that a try

 

[rbjtech 5284]

I'm really not sure what a transcode temp file/location has to do with this - the OP is not transcoding - they are just writing a TS file I would imagine.

A mechanical HDD has physical heads that take time to 'seek' to other areas of the disk.  If you are recording a constant 'stream' to the disk from a DVR, then the disk has to seek away from that 'track' grab a piece of data from elsewhere, and then return to continue to write the next piece of live DVR.

It's this seeking which is slowing you down.

The answer is to have a 2nd or more drive to run parallel I/O processes.

I would suggest a 2nd mechanical drive dedicated to your DVR recordings( or an SSD if it's big enough, but there really is no need) - and then point emby to use it on the DVR config.

Yes Transcoding/Cache on an SSD will help other processes - but that is not the issue here.

 

Edited August 13, 2021 by rbjtech

[Carlo 4561]

The transcode temp directory is used for more than just "transcoding".  It's used any time a remux is done as well or to assemble TV streams.

 

[rbjtech 5284]

The OP is talking about recording not playback.

On my system, the Transport Stream is written directly to a dedicated disk - the emby 'temp/transcode' directory is not even touched.

Pretty easy to see this is 'Computer Management' as you can see all the files in use - or in perfmon if you want to see it graphically ...

As far as I'm aware, nothing is every 'transcoded' before it is recorded (unless done on the PVR device itself), only when it's played back you may need to transcode it .. ?

 

 

Edited August 13, 2021 by rbjtech

[Carlo 4561]

I understand.  Watch your transcode folder and start a recording and you will see it being used during the recording process. It will also be writing to the DVR recording folder as well.

[Q-Droid 989]

1 hour ago, rbjtech said:

The OP is talking about recording not playback.

On my system, the Transport Stream is written directly to a dedicated disk - the emby 'temp/transcode' directory is not even touched.

Pretty easy to see this is 'Computer Management' as you can see all the files in use - or in perfmon if you want to see it graphically ...

As far as I'm aware, nothing is every 'transcoded' before it is recorded (unless done on the PVR device itself), only when it's played back you may need to transcode it .. ?

 

 

You might want to watch what Emby does while recording. It creates a single file in the transcoding path for the incoming stream. It also creates a single file in the library directories for the video being recorded. What isn't clear without tracing or seeing the code is whether it's a write/read/write operation, but it's definitely happening. Then if you begin to watch the video while being recorded Emby begins to create the .ts chunks and the .m3u8 file also in the transcoding directory. So you end up with w/r/w for the recording and r/w/w/r for the streaming. A 5400 rpm HDD with low IOPS and sluggish seek might look pretty busy.

To the OP, is there AV software interfering with your media I/O?

Edit: the above is my experience with US OTA mpeg2 streams. I don't know how h.264 streams from IPTV or tuners with transcoding are handled.

 

Edited August 13, 2021 by Q-Droid

[rbjtech 5284]

My apologies guys, you are correct.  It appears temporary TS chunks are written as a single file to the transcode folder, and then moved/copied to the final TV folder, so a w (temp)/r (temp)/w (dvr) as you say @Q-Droid    I never saw this when I looked, as IOPS on the SSD were lost in the overall 'noise' on that drive, so it looked as if it were not doing anything.

So in summary, a 2nd disk is going to help the OP without doubt - for overall performance, emby running on a SSD, with the transcoding/cache on the SSD will likely eliminate all I/O issues.  If possible, a 3rd disk should be used for the DVR final storage location.  That way, other disk I/O from other playback (unrelated to TV) will not interfere with I/O of the DVR stream being recorded.

[Q-Droid 989]

I would still check for AV activity which might want to scan each file creation and update. I don't run Emby on Windows though I imagine that many who do also exclude media and working paths from monitoring.

 

 

[Luke 42083]

Hi @jcbeaver76 can we please look at an example?

Thanks.