Transcoding clean up

[speechles 2010]

Not if the client can't access the source directly.

 

Those clients can only do that, due to their networking capabilities.

 

It is still direct play, the protocol is really moot, as long as Ffmpeg isn't involved. The server is passing the raw unmodified file, over an HTTP endpoint it creates, rather than using the provided network/smb paths. Emby does this also, to keep track of resume positions, and watched statuses. With network/smb paths you lose these. So all emby apps are using http paths because they have to be.

 

When emby uses the term "direct stream" it should only be modifying the container. The streams therein shouldn't be altered in any way, else the term "direct" becomes a myth...but...emby does alter the audio stream and still considers this to be "direct stream". The reason for this is because plex does the same thing, so emby has to do the same otherwise emby looks inferior to plex. Thats the issue I was bringing up. Why does a direct stream produce transcode files??! Its because technically it isn't a direct stream when that happens, the audio was altered.

Edited October 10, 2017 by speechles

[CBers 7114]

Sorry I didn't confirm what it was before I deleted the contents of the folder. Just noticed there was about 20GB of data leftover

That's a lot of content

 

Keep an eye and report back.

 

What client do you normally use?

[Jdiesel 1328]

That's a lot of content

 

Keep an eye and report back.

 

What client do you normally use?

 

Rokus, I was watching live TV for an hour or two last night and a few other users were watching recorded shows and movies. Last reboot was about 24 hours prior to me deleting the files.

[Jdiesel 1328]

Since deleting the contents of my transcoding-temp folder I had a user watch two episodes of a local stored show. After completing playback and logging off both .m3u8 and the accompanying .ts files are still in the folder.

[ebr 15663]

That's a lot of content

 

Keep an eye and report back.

 

What client do you normally use?

 

One reasonably long live TV viewing session (football game) could create that.

[CBers 7114]

Since deleting the contents of my transcoding-temp folder I had a user watch two episodes of a local stored show. After completing playback and logging off both .m3u8 and the accompanying .ts files are still in the folder.

Might be worth raising it in the .net core thread.

[Luke 40068]

Yes please make sure to see how to report a problem. thanks.

[Guest asrequested]

One reasonably long live TV viewing session (football game) could create that.

I had 5 shows that totalled over 60GB. I had to shut down the server to delete them. When testing, last night, the new files were cleared as expected. But I'll keep watch.

[Happy2Play 9441]

Just tested closing the browser while a movies was playing and all files in transcode-temp folder were removed after a couple seconds.  So it would appear improperly stopping media isn't the issues.

[Jdiesel 1328]

Just tested closing the browser while a movies was playing and all files in transcode-temp folder were removed after a couple seconds.  So it would appear improperly stopping media isn't the issues.

 

I am currently working on generating some clean log files and came to the same conclusion, at least on the web app. I'm currently letting a file play to the end to see if it cleans the temp folder after.

 

Edit: Letting playback play all the way through makes not difference on the web app, the temp folder is cleared after playback. I will wait for a Roku client to play a few files and see if the temp files stick around in the temp folder. 

Edited October 10, 2017 by Jdiesel

[CBers 7114]

Any indication in your server logs if ffmpeg crapped out?

[Jdiesel 1328]

Any indication in your server logs if ffmpeg crapped out?

 

Interesting thought.

 

The ffmpeg logs from the streams that did not clear out of the temp folder all end with:

[segment @ 0x2231500] Opening '/var/lib/emby/transcoding-temp/e2f2343bba4b7a5abd0ffa3847f43b7b215.ts' for writing
[segment @ 0x2231500] Opening '/var/lib/emby/transcoding-temp/e2f2343bba4b7a5abd0ffa3847f43b7b.m3u8.tmp' for writing
[segment @ 0x2231500] Opening '/var/lib/emby/transcoding-temp/e2f2343bba4b7a5abd0ffa3847f43b7b216.ts' for writing
[segment @ 0x2231500] Opening '/var/lib/emby/transcoding-temp/e2f2343bba4b7a5abd0ffa3847f43b7b.m3u8.tmp' for writing
frame=31113 fps=959 q=-1.0 Lsize=N/A time=00:21:37.71 bitrate=N/A speed=  40x    
video:853454kB audio:50692kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: unknown

 whereas the logfiles of the files that ended and were cleared all end with:

[segment @ 0x13e8940] Opening '/var/lib/emby/transcoding-temp/03c1835f726384a04cc95b0b652b77c2.m3u8.tmp' for writing
[segment @ 0x13e8940] Opening '/var/lib/emby/transcoding-temp/03c1835f726384a04cc95b0b652b77c213.ts' for writing
[segment @ 0x13e8940] Opening '/var/lib/emby/transcoding-temp/03c1835f726384a04cc95b0b652b77c2.m3u8.tmp' for writing
frame=  957 fps=182 q=-1.0 Lsize=N/A time=00:00:40.40 bitrate=N/A speed=7.67x    
video:1105kB audio:606kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: unknown
[libx264 @ 0x14eba40] frame I:17    Avg QP:19.40  size:  6279
[libx264 @ 0x14eba40] frame P:331   Avg QP:23.13  size:  2093
[libx264 @ 0x14eba40] frame B:609   Avg QP:25.85  size:   544
[libx264 @ 0x14eba40] consecutive B-frames: 13.8%  2.5%  4.7% 79.0%
[libx264 @ 0x14eba40] mb I  I16..4: 39.8%  0.0% 60.2%
[libx264 @ 0x14eba40] mb P  I16..4: 11.5%  0.0%  0.0%  P16..4: 46.5%  0.0%  0.0%  0.0%  0.0%    skip:42.0%
[libx264 @ 0x14eba40] mb B  I16..4:  1.0%  0.0%  0.0%  B16..8: 12.3%  0.0%  0.0%  direct: 7.0%  skip:79.8%  L0:25.9% L1:37.1% BI:37.1%
[libx264 @ 0x14eba40] coded y,uvDC,uvAC intra: 49.6% 41.4% 16.8% inter: 12.5% 6.1% 0.2%
[libx264 @ 0x14eba40] i16 v,h,dc,p: 26% 49% 15% 10%
[libx264 @ 0x14eba40] i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 10% 39% 14%  5%  7%  3% 11%  2%  8%
[libx264 @ 0x14eba40] i8c dc,h,v,p: 50% 35%  8%  7%
[libx264 @ 0x14eba40] Weighted P-Frames: Y:12.1% UV:9.7%
[libx264 @ 0x14eba40] kb/s:226.64
[aac @ 0x17dc6a0] Qavg: 5487.658

[Jdiesel 1328]

I can confirm that transcoding-temp is not flushed after Roku playback ends. FFMPEG is ending with:

video:853454kB audio:50692kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: unknown 

[Happy2Play 9441]

This has to be environmental as my transcoding-temp folder is flushed after transcoding/direct streaming playback.

 

At least from local playback.  So is this only a remote back issue?

Edited October 10, 2017 by Happy2Play

[Jdiesel 1328]

This has to be environmental as my transcoding-temp folder is flushed after transcoding/direct streaming playback.

 

At least from local playback. So is this only a remote back issue?

Have you tested with a Roku client? I only see it happening with on my Roku clients and not the web or android client. It seems like ffmpeg is ending unexpectedly.

[Happy2Play 9441]

Have you tested with a Roku client? I only see it happening with on my Roku clients and not the web or android client. It seems like ffmpeg is ending unexpectedly.

 

I tried the Roku Emby beta and blue neon night, and both time the transcode folder was cleared.

[Jdiesel 1328]

I tried the Roku Emby beta and blue neon night, and both time the transcode folder was cleared.

Do you have auto play next episode enabled? I was able to replicate this on another Roku but autoplay next episode must be enabled and you must let it start the next episode before stopping the stream.

[Happy2Play 9441]

All my episodes direct play, I guess I could try lower the bandwidth to force transcoding.

[Jdiesel 1328]

Yeah you will need to transcode to replicate

[Happy2Play 9441]

So this has to be isolated to TV as movies clean up after themselves for me but I will test when I get the chance.

[leekingsnatch 5]

I've set my Transcoding temporary path to a RAM drive. I noticed that Emby kept crashing this morning. I checked the Transcoding temporary path and it was completely full and the files in there were from the day before and today. I was under the impression that Emby deletes those files once the playback stops, but that doesn't seem to be the case. 

 

Thanks

 

 

[mastrmind11 722]

I've set my Transcoding temporary path to a RAM drive. I noticed that Emby kept crashing this morning. I checked the Transcoding temporary path and it was completely full and the files in there were from the day before and today. I was under the impression that Emby deletes those files once the playback stops, but that doesn't seem to be the case. 

 

Thanks

https://emby.media/community/index.php?/topic/51705-transcoding-clean-up/

[leekingsnatch 5]

https://emby.media/community/index.php?/topic/51705-transcoding-clean-up/

 

What exactly am I supposed to be looking for in the thread you linked? According to Luke it's supposed to be cleaned up when playback stops which is not happening on mine. 

[Jdiesel 1328]

What exactly am I supposed to be looking for in the thread you linked? According to Luke it's supposed to be cleaned up when playback stops which is not happening on mine. 

 

@mastrmind11 just meant you should post in that thread rather then start a new one so all the information is in one place. Please post more details about you issue to help narrow done the problem.

[leekingsnatch 5]

@mastrmind11 just meant you should post in that thread rather then start a new one so all the information is in one place. Please post more details about you issue to help narrow done the problem.

 

Okay. mastrmind11 should tell me what he means since my mind reading skills are not what they used to be