Live TV not playing - it used to work just fine

[SeekingWisdom 1]

I use emby to record off my antenna and it used to work just fine for many years.  Last weekend I set up to record the Colts football in case I got interrupted and could not watch it live (this is what I always do).

When it came time for the game to start I started up emby on my roku and selected the game from the guide.  There was a long delay (the circle animation played in middle of screen) and finally percentages started to show up and finally (after a much longer wait than normal) it started to play the channel.  It played for maybe 10 seconds then started to buffer again and replayed the same video I saw the first time but this time it was maybe 10 seconds longer.  Then it started to buffer again - and the short play/buffer continued until you cancelled it.

At that time I had emby 7_4.7.6_+x86_64 installed (stable release).

I was not able to watch the game live.

I tried to watch the game while it was being recorded by playing the file being generated and that didnt' work either.

After the game was over I could play the recorded program and that worked like it used to (i.e. played back smoothly).

I have searched the forum and found "Problems with live tv since the update" from June 4 by BlackDub.  He said a beta version worked so I updated to 7_4.8.0.8_x86_64 (beta version).  I did this because in his post he said that version 0.7 worked but when I checked the beta versions the .8 downloaded.  This version did not fix the live tv play problem I am having.  I tried to update backwards to the most current stable release and it says I cannot go backwards. He was asked to include emby log files so I am attaching all the files from today (8/16).

If you need something else please let me know.

I would note that I tried to play live TV (channel 59.1 and note that this is not a show I every have watched it is what it was at the time of my test) on 8/16 which should be the most recent thing in the log file.  I did not try any recording - just play live tv and it did the same buffer play as previously described.

I would also like to say that during the time of the Colts broadcast (in first part of description) I tried to watch the channel live from the guide on my PC.  I used chrome and accessed the synology server and started emby.  I went to the guide and selected the channel the game was on.  When I did this it played just fine (no buffering).  Maybe this additional information will help determine the problem.

 

embyserver.txt ffmpeg-directstream-f5e5b873-75ed-4f88-b040-15c525fabcf8_1.txt ffmpeg-transcode-06ca06e9-4d9e-4f33-a1e5-68b854d395f3_1.txt hardware_detection-63796250168.txt embyserver-63796250149.txt ffmpeg-transcode-cb9b61b5-131c-4270-9af2-92b0ad4ba956_1.txt hardware_detection-63796236708.txt

Edited August 17, 2022 by SeekingWisdom
added additional info to end of my post

[SeekingWisdom 1]

It has been 1 week and I have not seen any response.

Is this the wrong forum to ask this question?

Have I asked a dumb question?

Am I missing needed information?

I know the forum is still active because other questions are being discussed.

I would really like to be able to watch live TV again.

[ebr 14939]

@cayars

[jathe 9]

2022-08-16 12:42:18.975 Info EncodingManager: Deleting segment /var/packages/EmbyServer/var/transcoding-temp/362D3C/362D3C_4.ts due to disk space.

 

Disk is full

[SeekingWisdom 1]

I have attached a screenshot using "storage manager" which is a tool provided by synology.  It says volume 1 total size of 32.47TB currently is 3.33TB used.

I have also attached a screenshot using FileStation which is a tool provided by synology.  The EmbyMedia folder is where the files are stored that get played by emby.  I did a properties on the EmbyMedia folder and it is 2.49TB and its location is on volume1 which is shown in my first attachment to not be full (all shown in the 2nd attachment).

I would also note that the file I have asked to be recorded is being recorded and saved on volume 1.  After the show is over I can play it back and it works correctly (as stated in my original post).  If the disk was full how is there room for this file to be saved?

Can you give me more information as it clearly is not full.  Maybe there is some setting in emby that needs to be chaged?

Edited August 24, 2022 by SeekingWisdom

[Carlo 4330]

Hi,

Are you playing this back remotely or from your own lan where Emby Server is installed?

Which NAS unit do you have?

One of the ffmpeg log files shows conversion/transcode rate of about 30% real time speed which is less than 1/3 what's needed minimum.

Can you show me what your Transcode menu looks like in Emby Server with a couple screen shots?

Carlo

[SeekingWisdom 1]

I have synology DS9918+

I am doing all of what has been described on my local network - nothing remote.

I have attached transcode 1 and 2 showing the Transcoding page

I just want to remind you that I have used previous versions of emby for many months and this all worked.  None of my hardware has changed.  I don't know when it broke.  I have kept updating emby as new versions come out.  Normally I just set it to record and then watch it at a later time.  This still works.  The last time I watch TV when it was recording (like I am trying to do now) was probably last year during the NFL season.  I almost never watch TV from the guide but i have in the past and it worked at that time.

I opened a ticket to synology and asked about the /var directory.  I cannot see it using file manager.  

[SeekingWisdom 1]

emby (from earlier in this thread): 2022-08-16 12:42:18.975 Info EncodingManager: Deleting segment /var/packages/EmbyServer/var/transcoding-temp/362D3C/362D3C_4.ts due to disk space

Todd: I have been talking to synology and want to summarize what they have said.

Synology: /var is a separate system partition that is not accessible via the GUI.  You can access this partition via SSH.

Todd: This is significant because I had previously stated that volume1 has a lot of room in it.  Thus the question is about the room in /var.

Synology: The var directory is less than 300M, which means that the error message you receive from the third-party software is incorrect:

195M ./var

Todd: I don't know what size the file was that emby was trying to create.  If it was 105M then it could reach the 300M size which I am assuming would be the limit given what synology said in their response.

How big is the file emby was trying to create?

Is there a way to specify emby should use some of the volume1 partition or must it be in the /var directory (a different partition)?

Edited September 4, 2022 by SeekingWisdom

[SeekingWisdom 1]

I have used SSH to view the /var partition.  I hope this will provide additional information.

Above you see the "/" is 79% used (/var location). You can also see volume1 partition which is what I can see using the GUI

Above is the EmbyServer directory (FYI)

I included the above so you could see the max size for the transcoding-temp directory.  There is nothing in it currently.

I would really like to get the live view to work like it used to.  Would sure appreciate help to get this working again!

 

[SeekingWisdom 1]

Here is some new additional information.

One difference with this version of Emby and the old one I was used to is the closed captioning is on by default when you select a channel from the guide.

All of the problems I have described to this point occur when the closed captioning is on (the default condition).

I am using a roku box and if you have a channel playing and click the down arrow a number of options appear at the bottom of the picture.  The right most option is "CC" or closed captioning.  If you select closed captioning it has 2 options "off (none)" and "Und (Default EIA_608)".   If I turn off the closed captioning then the channel plays without any of the buffering I have previously described.

If I turn the closed captioning back on then the buffering starts back up again.  It is reliably repeatable.

I have attached some log files hoping the information may be in them.

Let me know if you want me to do any other experiment or provide you with 

embyserver.txt ffmpeg-remux-3c7be17d-d797-46f6-9125-611886149c5d_1.txt ffmpeg-remux-a5e853ab-06e8-43f9-ac86-a0afa8f507f3_1.txt ffmpeg-remux-ecf79b4a-a5f8-4f82-9ea6-0cb69d6dd1c4_1.txt ffmpeg-transcode-63bc44f9-809b-40e1-a47b-cc4b1b517e1c_1.txt ffmpeg-transcode-926a7eea-26f1-44c3-83d3-5fd3a29099d2_1.txt

[SeekingWisdom 1]

Here is some additional information.

I started out by trying to figure out how to change the default to not use subtitles and was not successful in this.  But in the process I found that some channels play with subtitles and some have the buffering problem previously described.

I live in the Indianapolis, Indiana area.

Channels that played without buffering problems: 8.1 (CW), 13.1 (NBC), 29.1 (CBS)

Channels that played with the previously described buffering problems 6.1 (ABC), 59.1 (FOX)

I found a web site: "hd-report.com/hd-channels"

This web site says CW, NBC and CBS all use 1080i and that ABC and FOX use 720p.  Is this a coincidence that the 720p channels have the buffering problem and the 1080i do not?  Remember, that earlier versions of emby all worked without the buffering problem.  However, I never turn on closed captioning so maybe this buffering issue was always there (previous version of emby did not have closed captioning on by default)?

I have included log files over the period where I was trying channels 6.1, 8.1, 13.1, 29.1 and 59.1 that I described above.

As I said, I started out trying to make no closed captions be the default.  To do this I went to the emby server and found emby /subtitles and changed preferred language from the default "any language" to "english" and changed subtitle mode from the default "default" to "no subtitles".  This did not appear to change anything when I selected live TV from the guide. 

Anyone know now to turn off subtitles as the default?

embyserver.txt ffmpeg-remux-71d04d84-4e54-46ac-92d8-a336e9c18bd9_1.txt ffmpeg-transcode-4c515de8-164d-4f1b-bd22-caa09ee00bdd_1.txt ffmpeg-transcode-63fdb71a-c350-418d-ab13-e1d927ad0993_1.txt ffmpeg-transcode-76cfb4ef-7eb3-41a4-8ec0-b8d1355278eb_1.txt ffmpeg-transcode-b895e22a-2430-48aa-8bf0-88aab2a1c593_1.txt ffmpeg-transcode-ebf17727-a0dd-4690-a1ec-8f26c5a8e1b4_1.txt ffmpeg-transcode-f2d7b737-4dc3-47bc-b091-13953eceb053_1.txt

Edited September 11, 2022 by SeekingWisdom

[SeekingWisdom 1]

Its been 14 days since my last post and no response.

Today I looked at Emby downloads and note the following:

emby-server-synology7_4.8.0.8_x86_64 beta version as 4.7.5 and 4.7.6 dont play live.spk

This is the name of the most recent download (downloaded from the non-beta although it says beta in the title).  I see that it says that 4.7.5 and 4.7.6 don't play live which I am assuming is it doesn't play the live off the air broadcast?  This is the problem that I have been reporting if that is what it is referring to.

I did not update my server with this version yet.

Does this release solve the problem I have been looking for an answer to?

Are the forums dead now and you don't get responses to problems?

[ebr 14939]

@cayars

[Carlo 4330]

On 9/10/2022 at 12:00 PM, SeekingWisdom said:

I have used SSH to view the /var partition.  I hope this will provide additional information.

Above you see the "/" is 79% used (/var location). You can also see volume1 partition which is what I can see using the GUI

Above is the EmbyServer directory (FYI)

I included the above so you could see the max size for the transcoding-temp directory.  There is nothing in it currently.

I would really like to get the live view to work like it used to.  Would sure appreciate help to get this working again!

 

You need to be careful trying to interpret this. / is it's own partition that lives on /dev/md0.  You do not want to use this area or have any files in this as Synology uses it during upgrades.  If it fills you will get locked out of your NAS!

/var is not part of /dev/md0 but is part of your first volume by default.
EmbyServer is installed on your first volume by default as well.  You don't want to access it as you did above, but instead use:
/volume1/@appdata/EmbyServer

@appdata is a special location in DSM 7 that can't be accessed via traditional GUI. It's the "master" view to installed packages. For example /volume1/@appdata/EmbyServer and then under EmbyServer you will see plenty of other virtual views and mappings.

When working via SSH on EmbyServer location you will want to sudo -i first to get admin/root permissions

[Carlo 4330]

On 9/11/2022 at 10:35 AM, SeekingWisdom said:

As I said, I started out trying to make no closed captions be the default.  To do this I went to the emby server and found emby /subtitles and changed preferred language from the default "any language" to "english" and changed subtitle mode from the default "default" to "no subtitles".  This did not appear to change anything when I selected live TV from the guide. 

Anyone know now to turn off subtitles as the default?

Click the person icon top right.
Next choose the App Settings menu choice.
Then from your user choices select the Subtitles menu.

You can then set the Subtitle mode however you want it.

Hope that helps,
Carlo

[Carlo 4330]

If you still get subtitles then it's likely due to:

the Remember subtitle track selection setting above.  I've stopped saving/remembering and only have it use forced subtitles. I used the clear saved track selections link in green above to clear out everything.

TIP: If you want to try those settings make a have a good backup on hand first in case you want to revert.

Emby's Server Configuration Backup works great for this because it can restore only a specific user's info.

I would suggest upgrading to 4.8.0.10 and trying your Live TV channels again. If you find a channel doing the buffering upload just the one log file and state what the issue is. IE buffering on Ruku client playing Channel 6  1080i. If possible test on a second client as well other than web and post that log as well.  That will provide the fundamental info without confusing the issue or adding to much info that makes it hard to follow.

Last point, make sure the option at the top of the logs menu is set to NO unless asked to turn on extended logging.

Carlo

[Luke 37129]

Hi, have you updated to 4.8.0.10? How does that compare?

[SeekingWisdom 1]

Sorry for delayed response - had some family issues last week which required my attention.

I made the changes suggested by cayars related to changing closed captioning default and the closed captioning is now off as the default.

Last night I downloaded 7_4.8.0_x86_64 because that is the stable version - it buffers like previously described.

This morning I downloaded the beta version 7_4.8.0.10_x86_64 - it buffers like previously described.

cayars asks "If you find a channel doing the buffering upload just the one log file and state what the issue is.".  I am not sure which one is "the one log file".  So I downloaded the ones over the period of the test.  These files (embyserver (3) and the next 5 files) resulted when I ran channel 6.1 ABC 720p on my roku box.  The default is now that closed captioning is off so at first the live channel selected from the guide played just fine.  I let it play for a couple minutes to insure the buffering did not happen.  Then I used the down arrow on the roku remote and selected closed captioning and enabled it.  That is when the buffering started as previously described.  After letting the buffering happen a couple times I then turned closed captioning off again and the live played just fine.

cayars asks "If possible test on a second client as well other than web and post that log as well."  I have 3 roku boxes on 3 different TVs and the emby app itself which I run after logging into the synology box but I do that in a web browser.  I am not sure if the 3 roku boxes are considered the same client or not.  Also not sure using the web browser and running through the emby app itself is disqualified because it uses the web browser?  I also have the emby app on my iPad.  I chose this because it is not a roku box or using the web browser.  If this is wrong please clarify and I will provide the proper results you want to see.  I followed the same sequence of closed captioning off (by default) followed by turning it back on.  On the iPad after turning closed captioning on the video never started to play again (I think I waited as long as it took on the roku box).  I then turned closed captioning off but the video never stared to play again.  I tapped the back arrow which took me back to the guide.  Then I selected 6.1 again and the video played without buffering (closed captioning was off).  The second test started about 10:20 and there were only 4 files with time stamps of 10:20 or later which I have also included.  The files embyserver (4) and the next 3 files are from the second test on the iPad.

Let me know what else I can do.

 

embyserver (3).txt ffmpeg-remux-dcc42bc8-8655-4c22-8d22-e94df0853d4c_1.txt ffmpeg-transcode-2ebf997a-5e2e-4ec2-8288-d10479babb83_1.txt ffmpeg-remux-4d29c8e3-6429-461a-a274-e105fdeac13a_1.txt hardware_detection-63800386655.txt embyserver-63800386459.txt embyserver (4).txt ffmpeg-directstream-304b5c42-3eb0-4f05-8246-de380dac6b02_1.txt ffmpeg-transcode-9a38cf85-0e70-4d7b-9ba4-9e4ff9d276be_1.txt ffmpeg-directstream-0f638f94-5bdb-4244-9245-6daa9d996bfd_1.txt

Edited October 3, 2022 by SeekingWisdom

[Luke 37129]

3 hours ago, SeekingWisdom said:

Sorry for delayed response - had some family issues last week which required my attention.

I made the changes suggested by cayars related to changing closed captioning default and the closed captioning is now off as the default.

Last night I downloaded 7_4.8.0_x86_64 because that is the stable version - it buffers like previously described.

This morning I downloaded the beta version 7_4.8.0.10_x86_64 - it buffers like previously described.

cayars asks "If you find a channel doing the buffering upload just the one log file and state what the issue is.".  I am not sure which one is "the one log file".  So I downloaded the ones over the period of the test.  These files (embyserver (3) and the next 5 files) resulted when I ran channel 6.1 ABC 720p on my roku box.  The default is now that closed captioning is off so at first the live channel selected from the guide played just fine.  I let it play for a couple minutes to insure the buffering did not happen.  Then I used the down arrow on the roku remote and selected closed captioning and enabled it.  That is when the buffering started as previously described.  After letting the buffering happen a couple times I then turned closed captioning off again and the live played just fine.

cayars asks "If possible test on a second client as well other than web and post that log as well."  I have 3 roku boxes on 3 different TVs and the emby app itself which I run after logging into the synology box but I do that in a web browser.  I am not sure if the 3 roku boxes are considered the same client or not.  Also not sure using the web browser and running through the emby app itself is disqualified because it uses the web browser?  I also have the emby app on my iPad.  I chose this because it is not a roku box or using the web browser.  If this is wrong please clarify and I will provide the proper results you want to see.  I followed the same sequence of closed captioning off (by default) followed by turning it back on.  On the iPad after turning closed captioning on the video never started to play again (I think I waited as long as it took on the roku box).  I then turned closed captioning off but the video never stared to play again.  I tapped the back arrow which took me back to the guide.  Then I selected 6.1 again and the video played without buffering (closed captioning was off).  The second test started about 10:20 and there were only 4 files with time stamps of 10:20 or later which I have also included.  The files embyserver (4) and the next 3 files are from the second test on the iPad.

Let me know what else I can do.

 

embyserver (3).txt 1.15 MB · 0 downloads ffmpeg-remux-dcc42bc8-8655-4c22-8d22-e94df0853d4c_1.txt 288 kB · 0 downloads ffmpeg-transcode-2ebf997a-5e2e-4ec2-8288-d10479babb83_1.txt 83.65 kB · 0 downloads ffmpeg-remux-4d29c8e3-6429-461a-a274-e105fdeac13a_1.txt 110.68 kB · 0 downloads hardware_detection-63800386655.txt 253.51 kB · 0 downloads embyserver-63800386459.txt 686.24 kB · 0 downloads embyserver (4).txt 2.44 MB · 0 downloads ffmpeg-directstream-304b5c42-3eb0-4f05-8246-de380dac6b02_1.txt 159.23 kB · 0 downloads ffmpeg-transcode-9a38cf85-0e70-4d7b-9ba4-9e4ff9d276be_1.txt 79.29 kB · 0 downloads ffmpeg-directstream-0f638f94-5bdb-4244-9245-6daa9d996bfd_1.txt 66.97 kB · 0 downloads

Hi, the closed captions are getting burned in with transcoding and it looks like your server is not able to do this quickly enough. We'll see what @softworkz thinks about it. Thanks.

[SeekingWisdom 1]

Here are a couple comments:

1 - this problem only occurs when closed captioning is on and the channel is 720p (1080i channels play with captioning just fine)

2 - I have the synology ds9918+ which has hardware acceleration which I thought was for transcoding - hardware acceleration is enabled (earlier in this thread is the emby transcoding page image and acceleration is enabled).

3 - if the server cannot handle this process "your server is not able to do this quickly enough" it seems to me like the cpu would be maxed out.  Here is ascreenshot showing the cpu load when playing the live channel without closed captioning followed by  when it is enabled followed by when it is disabled.  The CPu is about 13% when playing video without CC and 35% when CC is enabled and the buffering is occurring.

In the above image the time designated with the orange arrow is the time when the closed captioning is enabled with channel 6.1 720p and is the time the cpu is at about 35%.

4 - my system has an HD Homerun extended.  This device has 2 channels and hardware transcoding.  Is emby able to use this?

In summary I have a system that has hardware transcoding on the video stream, a server with hardware acceleration (which I think is for transcoding as well) and the cpu utilization is only 35% when the buffering occurs.  Also the 1080i channels work just fine with closed captioning enabled.

Maybe none of this applies to what you were saying.  If not perhaps a simple explanation would help me to understand.

Edited October 3, 2022 by SeekingWisdom

[softworkz 3341]

2 hours ago, SeekingWisdom said:

1 - this problem only occurs when closed captioning is on and the channel is 720p (1080i channels play with captioning just fine)

The one of your logs with a 1080i source is showing the hw acceleration to fail and then it falls back to software transcoding which is working at the required speed.

2 hours ago, SeekingWisdom said:

3 - if the server cannot handle this process "your server is not able to do this quickly enough" it seems to me like the cpu would be maxed out.

CPU is not the only bottleneck. In this case it could be the amount of assigned GPU memory or the GPU/CPU memory transfer bandwidth.
It could also be a driver or configuration issue.

What's special about the case we are talking about here is that it uses hw accel for decoding and encoding, but subtitle-burn-in is done in software (hw burn-in is not enabled yet).
Look at the following graphic:

The red arrows indicate where hw frames need to be downloaded/mapped from GPU memory to system memory and back.

This transfer could be limited by the board/system design of your device - possibly. Or maybe caused by low assigned GPU mem.

Such things can explain why CPU transcoding might be faster in that specific case.

[softworkz 3341]

Usually, I would have made a number of suggestions for things you should try, like enabling/disabling certain features and certain hw accelerations in order to get eventually and hopefully to a better understanding of the problem.

Often, there are a lot of things to try - which is tedious to explain (for me) and tedious to follow (for users).

What is meant to come to the rescue is our new Transcoding Tests plugin:

 

It allows you to test all possible combinations in a single row.
Ideally, we'll come to a diagnose much more quickly.

Please install that plugin and follow the instructions in the topic linked above.

For you to know the specific selections you need to make for your case, I've created a short clip:

 

 

[softworkz 3341]

@SeekingWisdom

Thanks again for your test results. A few notes first:

There are some known issues with VAAPI currently, that's why not all of the test runs ended successfully. 
QuickSync is not affected and it's also a bit faster then VAAPI most of the time, but roughly comparable and the same specifics apply to both in the same way.
Hardware Overlay is included in the transcoding tests, but it is not enabled yet for normal operation.

In the following graphics, I have filtered out the unsuccessful runs and those with "ScaleDownHalf" because in your examples there was no scaling either.
Now, let's look at the results with the first test file:

The fastest runs are with hardware overlay, which is not surprising.

But then - for sw overlay - we also see that the run (Run_9) with both, hw decoding and hw encoding is among the slowest runs. It is almost twice as slow as Run_1 (without any hw acceleration).

Of course, Run_1 takes a lot of CPU resources and the purpose of hw acceleration is not only speed but also offloading the CPU.
The best compromise in this case (when bound to sw overlay) is to use software decoding plus QuickSync encoding.

I won't show the second file's results (sw-only is fastest here and I don't know the reason yet), but with the peanuts test file, we get the exact same order:

 

Conclusions

This was the very first use the the TT plugin "in the field" and I'm very happy about it's usefulness.

The results have proven my assumptions from above in that the memory mapping/transfer is a bottleneck on your system.
(I don't know whether improvements are possible - connecting a display might make a change, if there's a connector at all or maybe also some BIOS settings, if that's accessible - I'm not familiar with the hardware)

Until hardware overlay will be enabled in Emby, your best option is to disable hw decoders for H264 and enable the QuickSync encoder.

Please try that and see how it works for your situation.

 

Attention Readers

Those results are specific to this user's system and setup. The conclusions above are not necessarily valid in general or transferable to other systems.
These are also specific to Closed Captions and may not apply in the same way to normal subtitles.

[SeekingWisdom 1]

31 minutes ago, softworkz said:

your best option is to disable hw decoders for H264 and enable the QuickSync encoder.

Is the transcoding setting (currently advanced) you are saying that should be off?

But only for H264 (which is probably most of the time) can this be set selectively for H264?

How do you enable quicksync encoder?

What type of stream do we have in the different test files (i.e. 720p, 1080i, etc)

Thanks for taking the time - I am going to try to follow up with synology to get their input for possible improvements.

 

 

Edited October 6, 2022 by SeekingWisdom

[softworkz 3341]

8 minutes ago, SeekingWisdom said:

Is the transcoding setting (currently advanced) you are saying that should be off?

But only for H264 (which is probably most of the time) can this be set selectively for H264?

Yes. Choose "Yes" for HWA transcoding, navigate away, go back there and choose "Advanced".

This will get you the default selections and you can modify from there.

Go to "Encoders" and move QuickSync H264 to the top. Then go to H264 decoders and uncheck both VAAPI and QuickSync.