transcoding-temp folder filling up

[ebr 14913]

Hi.  Unfortunately, I cannot reproduce this so we need to figure out what it is that is different about your setup that is causing it.  Can you reproduce this situation at will?

Does it happen with all users and all devices?

[Scott D 62]

No, I cannot reproduce at will.  It does seem to happen every night which has forced me to do a restart every morning to clear things up.

It happens across all users (Roku devices) and at different times.

With the minor updates .3, .4, .5 (as well as plugins) my system has been restarting on an almost daily basis.  So, I don't know if the issue has been resolved in the .5 or if it is simply empty due to a forced restart.

I'm sorry to hear that you cannot reproduce on your system, as it seems by other recent posts, the problem is not specific to me.  It was my hope that the extensive (debug) log files would have provided some insight as they are quite verbose.

I will continue to monitor on a daily basis until such time as the dot updates are slowed down.  It would be nice to know if the dot updates contain any changes that might solve the problem, or if there is no work being done on this issue and it is something being considered for the future.

[speechles 1917]

Lets figure this out. Where the ball drops. Using the ffmpeg log we can see where to start. We  need the ffmpeg log that corresponds to the files left in your transcoding directory. We need the ones that link to 9496D9...

http://REDACTED:8096/emby/videos/2174645/main.m3u8?DeviceId=5e939ebe-b5c4-58da-960d-f8af8d18abe0&MediaSourceId=ae3f5be46f2ba8ae41ad504b9e3a2acd&PlaySessionId=2b63efc9ab254441ba2ab345434605d2&api_key=97af52095fcc45c2be0ced0fbd3d1c22&VideoCodec=h264,hevc,mpeg2video&AudioCodec=ac3,aac,mp2,mp3,eac3,flac,vorbis,lpcm&VideoBitrate=1616000&AudioBitrate=384000&MaxFramerate=60&MaxWidth=3840&MaxHeight=2160&AudioStreamIndex=1&TranscodingMaxAudioChannels=8&SegmentContainer=ts&SegmentLength=3&MinSegments=1&AllowInterlacedVideoStreamCopy=True&BreakOnNonKeyFrames=True&ManifestSubtitles=vtt&h264-maxrefframes=16&h264-videobitdepth=8&h264-profile=high,main,baseline,constrainedbaseline&h264-level=51&aac-audiochannels=6&eac3-audiochannels=8&ac3-audiochannels=6&flac-audiochannels=6&lpcm-audiochannels=6&mp3-audiochannels=2&mp2-audiochannels=2&vorbis-audiochannels=6&TranscodeReasons=ContainerBitrateExceedsLimit

 

Okay there it is 217465. We can look in Server Log next by using the item ID of 217465. Below is the FIRST line in the log where you have this entry.

2022-06-17 13:59:59.786 Debug Server: http/1.1 GET http://‌‍‍REDACTED‌:8096/emby/Users/e3ccbbd0ba7f4620bf1652aed10eb5ae/Items/2174645?fields=Overview. UserAgent: Roku/DVP-11.0 (11.0.0.4193-95)

Below is the LAST line in the log where you have this entry.

2022-06-17 14:49:41.007 Info PlaybackReporting - EventMonitorEntryPoint: Saving final duration for Item : 5e939ebe-b5c4-58da-960d-f8af8d18abe0-e3ccbbd0ba7f4620bf1652aed10eb5ae-2174645
2022-06-17 14:49:41.019 Info PlaybackReporting - EventMonitorEntryPoint: Removing Old Key from playback_trackers : 5e939ebe-b5c4-58da-960d-f8af8d18abe0-e3ccbbd0ba7f4620bf1652aed10eb5ae-2174645

Somewhere in between is where the mystery is. The timestamps help keep us confined to the problem area.

2022-06-17 14:42:09.756 Info Server: http/1.1 Response 200 to ‌‍‍REDACTED‌. Time: 6ms. http://‌‍‍REDACTED‌:8096/emby/videos/2174645/hls1/subs/792.vtt?PlaySessionId=2b63efc9ab254441ba2ab345434605d2&VttTimestampMap=900000&CurrentSubtitleStreamIndex=2
2022-06-17 14:42:10.862 Info App: AppendExtraLogData - Read graph file: C:\Users\Scott\AppData\Roaming\Emby-Server\programdata\logs\ffmpeg-transcode-a6c7c5d3-bef9-4edd-a894-ce5e7ddba508_1graph.txt
2022-06-17 14:42:10.864 Info App: AppendExtraLogData - Deserialized GraphData fileStream: 17,208.00 bytes Graph Count: 2
2022-06-17 14:42:10.865 Info App: AppendExtraLogData - File Deleted
2022-06-17 14:42:10.874 Info App: ProcessRun 'StreamTranscode a6c7c5' Process exited with code 0 - Succeeded

This is where ffmpeg has finally completed. It says file deleted?

C:\Users\Scott\AppData\Roaming\Emby-Server\system\ffmpeg.exe -loglevel +timing -y -print_graphs_file "C:\Users\Scott\AppData\Roaming\Emby-Server\programdata\logs\ffmpeg-transcode-a6c7c5d3-bef9-4edd-a894-ce5e7ddba508_1graph.txt" -copyts -start_at_zero -init_hw_device "qsv=qd0:hw,child_device=0" -f matroska,webm -c:v:0 h264_qsv -hwaccel:v:0 qsv -i "Q:\New TV Episodes\Big Sky (2020)\Season 02\Big Sky (2020) S02E05.mkv" -filter_complex "[0:0]vpp_qsv@f1=width=720:height=404[f1_out0]" -map [f1_out0] -map 0:1 -sn -c:v:0 h264_qsv -b:v:0 1616000 -g:v:0 72 -maxrate:v:0 1616000 -bufsize:v:0 3232000 -level:v:0 30 -keyint_min:v:0 72 -r:v:0 23.976024627685547 -profile:v:0 high -aud:v:0 1 -c:a:0 ac3 -ab:a:0 384000 -ar:a:0 48000 -ac:a:0 6 -metadata:s:a:0 language=eng -disposition:a:0 default -max_delay 5000000 -avoid_negative_ts disabled -f segment -map_metadata -1 -map_chapters -1 -segment_format mpegts -segment_list "C:\Users\Scott\AppData\Roaming\Emby-Server\programdata\transcoding-temp\9496D9\9496D9.m3u8" -segment_list_type m3u8 -segment_time 00:00:03.000 -segment_start_number 0 -individual_header_trailer 0 -write_header_trailer 0 -segment_write_temp 1 "C:\Users\Scott\AppData\Roaming\Emby-Server\programdata\transcoding-temp\9496D9\9496D9_%d.ts" -map 0:2 -map 0:0 -an -c:v:0 copy -c:s:0 webvtt -max_delay 5000000 -avoid_negative_ts disabled -f segment -map_metadata -1 -segment_format webvtt -segment_list "C:\Users\Scott\AppData\Roaming\Emby-Server\programdata\transcoding-temp\9496D9\9496D9_s2.m3u8" -segment_list_type m3u8 -segment_time 00:00:03.000 -segment_start_number 0 -break_non_keyframes 1 -individual_header_trailer 1 -write_header_trailer 0 -write_empty_segments 1 -segment_write_temp 1 -min_frame_time 00:00:00.000 "C:\Users\Scott\AppData\Roaming\Emby-Server\programdata\transcoding-temp\9496D9\9496D9_s2_%d.vtt"

That same job ID (a6c7c5d3-bef9-4edd-a894-ce5e7ddba508)  comes back to that same ffmpeg transcoding-temp ID (9496D9). The above is from the ffmpeg log. So lets see how much more of a6c7c5 we get. Is there a killTranscodingJob attached to the time when this occurs?

No.. The only time I see that happen is once the Emby server goes to shut down.

2022-06-17 15:04:32.358 Debug EncodingManager: KillTranscodingJob - JobId a6c7c5d3-bef9-4edd-a894-ce5e7ddba508 PlaySessionId 2b63efc9ab254441ba2ab345434605d2. Killing transcoding

It does get killed when Emby server goes to shut down. That much it is doing right. It knows it is still running that ffmpeg and has to stop it. It starts to look like the user may have exited the app with the home button. The log contains mixed Roku and with the obfuscated IP addresses it is hard to know if it is the same Roku. But checking the device-ID you can tell it is the same Roku.

 

Now the interesting part.

2022-06-17 14:49:40.992 Info SessionManager: Playback start reported by app Roku SG 4.0.55 playing Heart-Shaped Charm. Started at 0 ms

... snipped the uninteresting stuff in the middle ...

2022-06-17 14:51:30.034 Info EncodingManager: Transcoding kill timer stopped for JobId 257e753f-b954-4c87-9f89-49caa28f61ce PlaySessionId 61cd37900dc74666b1543a2fd73d95d2. Killing transcoding
2022-06-17 14:51:30.034 Debug EncodingManager: KillTranscodingJob - JobId 257e753f-b954-4c87-9f89-49caa28f61ce PlaySessionId 61cd37900dc74666b1543a2fd73d95d2. Killing transcoding
2022-06-17 14:51:30.035 Info App: ProcessRun 'StreamTranscode 257e75': Stopping ffmpeg process with q command for C:\Users\Scott\AppData\Roaming\Emby-Server\programdata\transcoding-temp\6E487A\6E487A_0.ts
2022-06-17 14:51:30.198 Info App: AppendExtraLogData - Read graph file: C:\Users\Scott\AppData\Roaming\Emby-Server\programdata\logs\ffmpeg-transcode-257e753f-b954-4c87-9f89-49caa28f61ce_1graph.txt
2022-06-17 14:51:30.200 Info App: AppendExtraLogData - Deserialized GraphData fileStream: 17,208.00 bytes Graph Count: 2
2022-06-17 14:51:30.208 Info App: AppendExtraLogData - File Deleted
2022-06-17 14:51:30.214 Info App: ProcessRun 'StreamTranscode 257e75' Process exited with code 0 - Succeeded
2022-06-17 14:51:30.215 Debug App: ProcessRun 'StreamTranscode 257e75': WaitForExitAsync took 179ms
2022-06-17 14:51:30.823 Info SessionManager: Session f07092c9bb50d499299b68f230d16133 has gone idle while playing
2022-06-17 14:51:30.825 Info SessionManager: Playback stopped reported by app Roku SG 4.0.55 playing Heart-Shaped Charm. Stopped at 42000 ms

At this point it is reporting stopped of an entirely different episode which started in the middle of playback of this other. Lets read the rest of the log...

2022-06-17 14:51:30.830 Info PlaybackReporting - EventMonitorEntryPoint: _sessionManager_PlaybackStop : Entered
2022-06-17 14:51:30.830 Info PlaybackReporting - EventMonitorEntryPoint: Saving final duration for Item : 5e939ebe-b5c4-58da-960d-f8af8d18abe0-e3ccbbd0ba7f4620bf1652aed10eb5ae-2187197
2022-06-17 14:51:30.847 Info PlaybackReporting - EventMonitorEntryPoint: Removing Old Key from playback_trackers : 5e939ebe-b5c4-58da-960d-f8af8d18abe0-e3ccbbd0ba7f4620bf1652aed10eb5ae-2187197

Somebody pressed the HOME button on the Roku. The progress updates stopped. But it looks like the srt->vtt kept going. It looks like it just kills the video transcoding but keeps the side car going? Not knowing everything I can only go so far into the rabbit hole.

@softworkz Do you have an idea what is going on here? But it really looks like the HOME button issue can you confirm? The user presses HOME on the Roku comes right back into the application and plays a different item. Since the SessionID would remain the same and no reported stop playback sent from the application it might assume it keeps the active encoding. The interesting files are ( ffmpeg-transcode-a6c7c5d3-bef9-4edd-a894-ce5e7ddba508_1.txt ) and ( embyserver-63791075073.txt ) both found in the last post by @ScottD found in the link below.

Thanks.

Edited June 28, 2022 by speechles

[ebr 14913]

8 hours ago, speechles said:

Somebody pressed the HOME button on the Roku. The progress updates stopped. But it looks like the srt->vtt kept going. It looks like it just kills the video transcoding but keeps the side car going? Not knowing everything I can only go so far into the rabbit hole.

No - that is not what likely happened.  See above where the OP laid out exactly what happened.

All the travels through the ffmpeg logs are unnecessary.  For some reason, the app did not send a stop report.  The issue is somewhere in the app.  My guess is it is related to the player status flag.

[Scott D 62]

There may be something to be said about what @speechles has to say about the HOME button being pressed.  Based on an unrelated post in another discussion, there does seem to be a problem with ROKU and the remote buttons becoming unresponsive at times.  Last night I was watching a show (media file) and at the end instead of watching credits I tried to back out of the episode by using the <- key on the remote.  NOTHING.  All of the keys seemed to be unusable.  The only way to cancel the playing and return was to press HOME button.  I have experienced this on several occasions. The transcode files remained and in the transcode-temp folder this morning.  I have also noticed in the past that after watching LIVE TV and then changing to a media file, that the remote keys will become unresponsive.

I do not have the time at the moment to sift through the log files and REDACT, but I will attempt to get the logs from last night posted later this afternoon.  

Attached for the moment is a screenshot of the activity page.  You can see where I (Irene) switched from watching LIVE TV ABC-15 to watching a media file at around 7:32 PM.  At 8:10 we started the next media file.  There is no ending of the first file being watched.  I do remember having to press HOME as the remote was unresponsive.  

I will upload supporting files later today.

Edited June 28, 2022 by Scott D

[ebr 14913]

13 minutes ago, Scott D said:

There may be something to be said about what @speechles has to say about the HOME button being pressed.  Based on an unrelated post in another discussion, there does seem to be a problem with ROKU and the remote buttons becoming unresponsive at times.  Last night I was watching a show (media file) and at the end instead of watching credits I tried to back out of the episode by using the <- key on the remote.  NOTHING.  All of the keys seemed to be unusable.  The only way to cancel the playing and return was to press HOME button.  I have experienced this on several occasions. The transcode files remained and in the transcode-temp folder this morning.  I have also noticed in the past that after watching LIVE TV and then changing to a media file, that the remote keys will become unresponsive.

I do not have the time at the moment to sift through the log files and REDACT, but I will attempt to get the logs from last night posted later this afternoon.  

Pressing "Home" during playback on the Roku is definitely an issue but, based on your last server log, that is not what happened here.  For some reason, the app did not send a stop report between one item finishing and the other item starting.  That is evident in the server log.

But, also, to your actual symptom you are trying to solve - the server IS recognizing that the playback has stopped after a period of no reports:

2022-06-17 14:51:30.034 Info EncodingManager: Transcoding kill timer stopped for JobId 257e753f-b954-4c87-9f89-49caa28f61ce PlaySessionId 61cd37900dc74666b1543a2fd73d95d2. Killing transcoding
2022-06-17 14:51:30.034 Debug EncodingManager: KillTranscodingJob - JobId 257e753f-b954-4c87-9f89-49caa28f61ce PlaySessionId 61cd37900dc74666b1543a2fd73d95d2. Killing transcoding
2022-06-17 14:51:30.035 Info App: ProcessRun 'StreamTranscode 257e75': Stopping ffmpeg process with q command for C:\Users\Scott\AppData\Roaming\Emby-Server\programdata\transcoding-temp\6E487A\6E487A_0.ts
2022-06-17 14:51:30.198 Info App: AppendExtraLogData - Read graph file: C:\Users\Scott\AppData\Roaming\Emby-Server\programdata\logs\ffmpeg-transcode-257e753f-b954-4c87-9f89-49caa28f61ce_1graph.txt
2022-06-17 14:51:30.200 Info App: AppendExtraLogData - Deserialized GraphData fileStream: 17,208.00 bytes Graph Count: 2
2022-06-17 14:51:30.208 Info App: AppendExtraLogData - File Deleted
2022-06-17 14:51:30.214 Info App: ProcessRun 'StreamTranscode 257e75' Process exited with code 0 - Succeeded
2022-06-17 14:51:30.215 Debug App: ProcessRun 'StreamTranscode 257e75': WaitForExitAsync took 179ms
2022-06-17 14:51:30.823 Info SessionManager: Session f07092c9bb50d499299b68f230d16133 has gone idle while playing

So that should have cleaned up your transcoding temp folder.  If it didn't, then there is an issue there that needs to be looked at as well.

[Scott D 62]

Here is another sample of what is going on.  This just happened this morning.

I have not had the opportunity to discuss with the user, but it is my belief that the LIVE TV stream may have not been playing properly.  On another issue, when playing older (SD) content, there is a problem with transcoding where the top 1/3 of the screen has a green bar, and what looks like old school ghosting.  This may be the reason the stream was stopped and started a few times.  But that is just my guess at the moment.

See attached!

activitylog.db embyserver.txt ffmpeg-transcode-1be96254-fb4b-4fc5-973c-34f5eb2e0c61_1.txt ffmpeg-transcode-8d8d3619-fecc-4a2e-86de-44aeed3ab6d7_1.txt ffmpeg-transcode-ecb740bd-e5b1-421b-a140-cf3af77d6be8_1.txt ffmpeg-transcode-f25fd9a3-b6d4-436d-92f7-779aba28bc49_1.txt

[ebr 14913]

13 minutes ago, Scott D said:

Here is another sample of what is going on.  This just happened this morning.

Okay, that is a very different situation - your symptom you are looking at - the transcode temp folder - may be the same but starting and stopping a live TV channel is a very different internal operation from advancing to a new episode in a play queue (your original report).

Your original report is some strange situation where the app didn't send a stop report when it should have.  I don't know how that happened but we are taking steps to prevent it in the app.

In this new situation - you can see all start and stop reports are sent properly by the app.  This new situation, I believe, is the case where a channel is started but never really starts playing so the user tries again (and maybe again, and again).  In that situation, sometimes the server does not get the transcoding process shut down since it never got fully going properly.

 

[Scott D 62]

ebr, with respect, I never mentioned the problem as originating from advancing from one episode to another.  My original problem, and remains to be, the transcoding-temp folder filling up.  I have provided log files that are from the timeframe that the offending files are created and are not deleted.  I have provided to the best of my ability just what the user was doing at the time the problem occurred.  Why they are not deleted is outside my knowledge base.

It seems to me that this is a server issue and not necessarily a ROKU issue.  While the samples may be different, the original problem remains the same.  The transcoding-temp folder is filling up to the point that it will create issues with storage and future transcode sessions.

While I am not a coder, it would seem a fairly easy option to look for - "if any activity + any currently attached users = none", clean-up the transcoding-temp folder.  Or, add a date stamp to the temp folders.  If they are more than 2 days old, delete them.  I would much rather dedicate the processor power to re-transcode than to have fragments hanging around in the event it needs to be used in the future. 

I do this manually every morning and several others have written code for different platforms to accomplish this.  I personally prefer to have you do the coding so that changes in the future to the server do not create additional problems (i.e., user plugins that become deprecated due to server changes that create issues).

This is just my 2 cents on the issue.  I realize there are many other issues that are of a higher priority, but it would be nice to see this resolved so that extended absence from the server does not result in total failure.

[ebr 14913]

52 minutes ago, Scott D said:

ebr, with respect, I never mentioned the problem as originating from advancing from one episode to another.  My original problem, and remains to be, the transcoding-temp folder filling up

Yes, I understand.  It was just the last few cases of this that you provided were actually the result of the Roku app not sending that stop command.  I think we will have that taken care of (even though I could not reproduce it) but there still may be cases where transcodes don't get cleaned up properly under other situations.

In short, your basic issue - the transcode temp folder filling - can have a multitude of causes so we need to try and chase each of them down.

Thanks.

[Scott D 62]

As I stated earlier on, I (we) use primarily ROKU devices.  There are a few occasions when other devices are used, such as apps built into tv's. but the majority is on a ROKU.

Time permitting, I will provide log files and details to the cause when it happens again.

[ebr 14913]

23 minutes ago, Scott D said:

Time permitting, I will provide log files and details to the cause when it happens again

Yes, please continue to do that.  I believe your last example was the situation with a live TV channel that doesn't start properly and we are aware of that situation.  In fact, that really should be the only situation that truly leaves a transcoding process stranded at this point.

One thing to be sure and try and train your users on is to never exit active playback with the Roku "Home" button.  Always back out first.

[Scott D 62]

Spoke with user Bruce_Kelly about the issue this morning.  Situation is as follows.

Attempted to watch Live TV and after about a full minute of the progress circle sitting at 99%, backed out to the guide and tried again.  Rinse and repeat a few times until the decision was made to pass on watching Live TV.  Used the <- button to return to the guide each time.

Edit - side note.  I have personally seen a problem recently with SD TV signals being transcoded poorly.  Green bar across top 1/3 of the screen and double image (ghosting) in the remainder of the video image.  HD signals appear to be working without issue.

Edited June 28, 2022 by Scott D

[ebr 14913]

1 hour ago, Scott D said:

Spoke with user Bruce_Kelly about the issue this morning.  Situation is as follows.

Attempted to watch Live TV and after about a full minute of the progress circle sitting at 99%, backed out to the guide and tried again.  Rinse and repeat a few times until the decision was made to pass on watching Live TV.  Used the <- button to return to the guide each time.

Okay, that confirms my suspicion.  Thanks.

[Scott D 62]

1 hour ago, Luke said:

Hi @rmayott can we please look at a specific example? Please go over an example and attach the emby server log from when this happened. Thanks !

 

[Luke 37064]

Hi @Scott D, we'll help you here in your topic. The other topic is for another user and I'd like for them to answer the same questions. Thanks.

[Scott D 62]

Seems Emby is like an uncontrollable child...just can't leave it alone for a moment.

I left my server yesterday morning after doing my morning ritual of restarting to clear the transcode folder.  Noticed today that I was getting messages about the remaining space on my hard drive.  What normally is around 200 Gb of a 500Gb SSD, I have 27 Gb remaining.

While I don't have the time to attach log files as I am working remote, this has gotten to the point where I just can't leave the server alone for even a minute.

When I return I will post logs, even if they are huge.

A quick look at the files created, it seems another problem that is occurring is that Emby is not releasing tuners from HDHomeRun.  I currently have 2 tuners open and no one is online.

Things that make you go HMMMMM.

[Luke 37064]

Are you still running into this, and if so, is it still only with Roku?

[Scott D 62]

I have this problem daily.  I have been restarting every morning for quite some time to keep the folder clear.  Got tired of providing info only to be told it is a user error.  I have had the problem on my local device and I am always careful to exit the roku app in the "proper" manner.

Best fix is to restart daily.

But, thanks for asking.

[Luke 37064]

1 hour ago, Scott D said:

I have this problem daily.  I have been restarting every morning for quite some time to keep the folder clear.  Got tired of providing info only to be told it is a user error.  I have had the problem on my local device and I am always careful to exit the roku app in the "proper" manner.

Best fix is to restart daily.

But, thanks for asking.

It's not user error. We just haven't chased down the scenario that's causing this yet. I know you said it involved some of your users, but can you reproduce personally?

[Scott D 62]

Yes, it has happened to me personally on devices attached to my network.  It is a hit and miss, but it has happened to me.

Not to confuse the issue, but I have been having the transcode folder filling up for a few years now.  I have recently been experiencing several other issues with the Roku app that have been occupying my time.

1.  After playing live tv for at least 30 minutes and switching to a media file, the remote will become unresponsive toward the end of the media file.

2.  Live TV recordings no longer play in the original format.  They must be converted to a lower bitrate in order to play.

3.  Live TV on a few channels will not play.  Seems to be something in the resolution/framerate causing the problem.

4. When exiting a Live TV viewing session, the  <- returns to a blank sceen with only headers showing.  Must press <- a second time to return to the home screen.

5. bif files are no longer being created on the completion of a Live TV recording.

6. HDHomeRun tuners not being release and filling the temp folder.

All of these problems began with a recent update (I believe around the end of May).  It has been a few minor updates ago.  So while I have found a patch to the temp folder filling up, my time and effort has been focused on the other issues.  Once I can get them to be repeatable at will, I might post the log files.  But in all honesty, it is a little disheartening to go through the effort of replicating the problem, capturing and redacting all the log files, putting together all of the documentation, writing a description of the problem, posting the information only to be told:  try the next update, looking into it, can't duplicate, user error.

Since we (I) have no idea if any of the problems have even been looked into, providing more and more examples seems to be pointless.  I patiently wait for the next release of the server and the next release of any apps.  Hopefully, the promise of "try the next version" will pay off in the near future.

For those that have NO ISSUES, I would love to hear the hardware configuration so that I could duplicate the set-up.  I would really like to be at a point where I can set it and forget it, with only routine maintenance (every other week or so).  Till then, I will continue with the process I have established.  It ain't broke.

 

Side note - Not sure if his helps.  Some of the above problems have been narrowed down to the lower end versions of Roku players.  Specifically the Roku Express+.  Specifically the Live TV viewing.  I can view a channel on a StreamingStick+ but cannot view the same channel at the same time on a Roku Express+.  Both are running the current version of the app and both are on the same network.  Also related to playing a recording of a Live TV program when the framerate is 60fps.  All other channels work with no issue.

Edit - Just went back and checked and the transcode folder filling up has been reported by myself as far back as 2018.  It may have been reported by others even before that time.

Edited October 19, 2022 by Scott D

[ebr 14913]

6 hours ago, Scott D said:

1.  After playing live tv for at least 30 minutes and switching to a media file, the remote will become unresponsive toward the end of the media file.

This is corrected in the new release of the app that should go out soon.

6 hours ago, Scott D said:

Live TV recordings no longer play in the original format.  They must be converted to a lower bitrate in order to play.

3.  Live TV on a few channels will not play.  Seems to be something in the resolution/framerate causing the problem.

We need to look at specific examples of these.

6 hours ago, Scott D said:

When exiting a Live TV viewing session, the  <- returns to a blank sceen with only headers showing.  Must press <- a second time to return to the home screen.

We're still trying to chase this down.

6 hours ago, Scott D said:

bif files are no longer being created on the completion of a Live TV recording.

This is not related to the Roku but would need to look at a specific example.

6 hours ago, Scott D said:

HDHomeRun tuners not being release and filling the temp folder.

This is the problem in this thread which should be solved for most people.  We just have to figure out why it isn't yet for you.  It is also a server issue.

[Luke 37064]

@Scott DHi, are you still having an issue with this?

[Scott D 62]

If you are referring to the original post subject, the answer is yes.  I have gotten around the problem as stated by doing a daily restart of Emby.  Thanks to a community (I can't remember the screenname) user, a plugin to schedule a restart was added to my server and it has performed admirably. I have it scheduled to restart on Sunday and Wednesday.  This seems to be sufficient to prevent the drive from filling completely.

Occasionally, an empty folder will be left behind.  But that is nothing compared to the gigs of data that accumulate prior to the restart.

[Luke 37064]

Can you try removing the daily restart and see how things compare?