Throttle Cleanup

[softworkz 5066]

@Napsterbater- what's your issue? Anything unclear?

[softworkz 5066]

9 hours ago, Jdiesel said:

I was wanting to bring this up again to see what the current temperature on transcoding to ram is. I grabbed a high endurance SSD months ago to use as a dedicated Emby transcode scratch drive and was surprised to find that I've already blown through about 30% of it's expected life. At this rate I will be replacing it in less than 2 years. The majority of writes to the drive are due remuxing container incompatiblities or audio downmixing, not video transcoding. 

This is quite impossible when you do the math.

Let's assume that your SSD would have only 2GB capacity and transcoding a 2h movie would create 2 GB of data in transcoding temp.

High-endurance SSDs can do 10k to 100k writes per cell. Let's assume just 10k, which makes 20kh (20000h) of watching that movie non-stop. Means you could watch that movie 2.3 years non-stop. But now, your SSD doesn't have just 2 GB capacity. Let's assume 200 GB. This means that (due to  relocations done by the firmware),, there's a factor of 100, so you could watch that movie 230 years non-stop before your SSD is fully worn out. When 10 users are watching in parallel non-stop, then it would still take 23 years.

[yocker 1247]

5 hours ago, softworkz said:

As mentioned, explained in detail already:

I do agree with you! Media center transcoding should be done to a disk. The chance of files not getting cleaned up alone is reason enough to not use memory.

But trust me, the spare QLC sata disks i have lying around are not fit for anything but oversized USB flash drives, they are dram less and crap out at 35MB/s after a bit. (Pulled them out of dying machines people want me to fix).
I just do it in memory for now until i get hold of an appropriate disk for it and the server has no ill effects from it.

[Q-Droid 989]

Even low end SATA SSDs that are kept trimmed should easily handle the IOPS and read/write data rates involved in transcoding and streaming media.

 

[softworkz 5066]

4 hours ago, Q-Droid said:

Even low end SATA SSDs that are kept trimmed should easily handle the IOPS and read/write data rates involved in transcoding and streaming media.

Exactly! Transcoding requires a lot of compute power, but storing the results is not that performance critical that it would need a RAM disk. Not even an SSD.

Even more when looking out for using TVnext. It can write loads of data to transcoding-temp (for time-shift buffer and when working with full transponder data), so there's a requirement for storage space but not storage performance.

 

[bandit8623 213]

On 9/5/2024 at 10:53 AM, softworkz said:

Exactly! Transcoding requires a lot of compute power, but storing the results is not that performance critical that it would need a RAM disk. Not even an SSD.

Even more when looking out for using TVnext. It can write loads of data to transcoding-temp (for time-shift buffer and when working with full transponder data), so there's a requirement for storage space but not storage performance.

 

it doesnt always use more processing power.  it matters how its done.  softperfect has a direct i/o moide that bypasses some of the os stack.  so while in general it can add overhead...  how much really?  if you have free memeory laying around why not use it?

https://www.softperfect.com/board/read.php?16,29485

[softworkz 5066]

13 minutes ago, bandit8623 said:

it doesnt always use more processing power.  it matters how its done.  softperfect has a direct i/o moide that bypasses some of the os stack.  so while in general it can add overhead...  how much really?  if you have free memeory laying around why not use it?

You need to view it from a different angle: In case of heavy transcoding, the bandwidth of your memory gets often maxed out. So why do you want to add something that takes additional memory bandwidth on top of that when you could read/write the data elsewhere (a HD/SSD) which allows some part of the data take a different path than the one to memory (RAM)?

 

 

[bandit8623 213]

14 minutes ago, softworkz said:

You need to view it from a different angle: In case of heavy transcoding, the bandwidth of your memory gets often maxed out. So why do you want to add something that takes additional memory bandwidth on top of that when you could read/write the data elsewhere (a HD/SSD) which allows some part of the data take a different path than the one to memory (RAM)?

 

 

on slow ram sure. 6 channel ddr4 i highly doubt is getting MAXed out.  ive ran benchmarks on the ram disk its absolutley insane on speed.  and cpu never jumps much at all.  again though i have system with enterprise cpu ram

 

edit  6 channels

Edited September 27, 2025 by bandit8623

[softworkz 5066]

6 minutes ago, bandit8623 said:

on slow ram sure.  triple channel ddr4 i highly doubt is getting MAXed out.  ive ran benchmarks on the ram disk its absolutley insane on speed.  and cpu never jumps much at all.  again though i have system with enterprise cpu ram

It depends on your goal. When you have such a high-end system, you might be aiming to be able to do 20 simultaneous 4k HDR transcodes with subtitle burn-in (uncompressed video frames copied back and forth bertween GPU mem and system mem.

The subject of this topic is that people want a smaller transcoding temp in order to use a RAM disk. But that's just nonsense. It doesn't give you any advantage - even when you have a system where it "doesn't hurt".

The nature and requirement for transcoding-temp is: average performance + large size
It is not: high-performance + small/average size

That's the bottom line.

[softworkz 5066]

Also, as I said before: Size requirements for transcoding-temp size will increase in the future, so that's rerally not a reasonable approach for Emby.

[bandit8623 213]

1 minute ago, softworkz said:

It depends on your goal. When you have such a high-end system, you might be aiming to be able to do 20 simultaneous 4k HDR transcodes with subtitle burn-in (uncompressed video frames copied back and forth bertween GPU mem and system mem.

The subject of this topic is that people want a smaller transcoding temp in order to use a RAM disk. But that's just nonsense. It doesn't give you any advantage - even when you have a system where it "doesn't hurt".

The nature and requirement for transcoding-temp is: average performance + large size
It is not: high-performance + small/average size

That's the bottom line.

that makes sense,  but if 128gb covers me for the little transcoding i do then all good right?  i just dont like the blanket statement ram disk BAD or wont work right.

my system is my home lab/steamlink/emby  ect server always running.  most is played direct as i have gig internet.  live tv is the biggest transcoder as its mpeg2.

having something thats there and works and it currently free is also a benefit.

[bandit8623 213]

3 minutes ago, softworkz said:

Also, as I said before: Size requirements for transcoding-temp size will increase in the future, so that's rerally not a reasonable approach for Emby.

sure that also makes sense.  if ill need more down the road ill make that change.  i have 128gb more ram just laying here not in use HA.  i work for a enterprise server refurbishing co.  only reason i get good hardware free/cheapo.  im not going out of my way to spend money on a ram disk.  its just something i already have

Edited September 27, 2025 by bandit8623

[softworkz 5066]

7 minutes ago, bandit8623 said:

i just dont like the blanket statement ram disk BAD or wont work right.

I have absolutely nothing against RAM disks. All I've said here was only about the specific use case as a transcoding-temp folder for Emby.

Of course, everybody is free to do what they want. I just want to avoid a situation where people are later complaining about the size requirements.With tvNext, when it saves full transponder data from a tuner, it makes about 25 GB/h. Plus the watched or recorded programs being saved separately plus - in case of transcoding - the transcoded programs, so when 2 programs are consumed, you may get 30 GB/h. With a quadro tuner and 8 consumed programs, this makes 120 GB/h. With a timeshift buffer of 6h, you'll need 720 GB transcoding-temp size in this example. 

[bandit8623 213]

25 minutes ago, softworkz said:

I have absolutely nothing against RAM disks. All I've said here was only about the specific use case as a transcoding-temp folder for Emby.

Of course, everybody is free to do what they want. I just want to avoid a situation where people are later complaining about the size requirements.With tvNext, when it saves full transponder data from a tuner, it makes about 25 GB/h. Plus the watched or recorded programs being saved separately plus - in case of transcoding - the transcoded programs, so when 2 programs are consumed, you may get 30 GB/h. With a quadro tuner and 8 consumed programs, this makes 120 GB/h. With a timeshift buffer of 6h, you'll need 720 GB transcoding-temp size in this example. 

sounds good!  my main complaint was with someone jumping into threads just saying the same thing "ram disk have no benefit"  so nothing you really said.

my point to them is there is benefit for some people.  they just kept referencing this thread..

thx again

Edited September 27, 2025 by bandit8623

[softworkz 5066]

4 minutes ago, bandit8623 said:

my main complaint was with someone jumping into threads just saying the same thing "ram disk have no benefit"

Oh, I wasn't aware of that. There clearly ARE workloads which benefit from a RAM disk. Albeit, mostly applications which were developed for using disk as storage and weren't anticipating cases where somebody has so much RAM. In that case, they could have developed it in a way to use the RAM directly. In other words, it's mostly older applications where you can achieve high gains.

On the other side, there are also completely idotic ways for using a RAM disk, like for example as swap drive  

(Emby transcoding-temp is somewhere in the middle: no benefit, on slower or loaded systems possibly even degraded performance, on powerful systems running low, no harm unless you run out of "disk space")

[bandit8623 213]

1 minute ago, softworkz said:

Oh, I wasn't aware of that. There clearly ARE workloads which benefit from a RAM disk. Albeit, mostly applications which were developed for using disk as storage and weren't anticipating cases where somebody has so much RAM. In that case, they could have developed it in a way to use the RAM directly. In other words, it's mostly older applications where you can achieve high gains.

On the other side, there are also completely idotic ways for using a RAM disk, like for example as swap drive  

(Emby transcoding-temp is somewhere in the middle: no benefit, on slower or loaded systems possibly even degraded performance, on powerful systems running low, no harm unless you run out of "disk space")

thank you! this was what i was trying to say from the beginning.  i should have been more clear!  

Edited September 27, 2025 by bandit8623