Live TV Random Stutter

[softworkz 4274]

2 minutes ago, Lyfesaver said:

here it is, the link I pointed to in this thread: https://emby.media/community/index.php?/topic/133860-live-tv-random-stutter/&do=findComment&comment=1402675

I gave the same solution there, haven't you tried it?

[Lyfesaver 73]

3 minutes ago, softworkz said:

I gave the same solution there, haven't you tried it?

The enabling Diagnostics? Yes I just did. And I restarted (just now, was trying to avoid as I had an active recording but decided to do it cuz you were actively helping me so heck the recording lol)

[Lyfesaver 73]

I am currently waiting for the transcoding page to finish loading but here is my device manager, I removing all the old stuff now tho

[Lyfesaver 73]

Fixed (I only chose to remove driver from the top one (the USB monitor)

[softworkz 4274]

Whats e1649Fwu?

 

When the server is loaded, please look at the Transcoding page (Advanced) whether you see the D3D9 QSV codecs now.

[Lyfesaver 73]

1 minute ago, softworkz said:

Whats e1649Fwu?

 

When the server is loaded, please look at the Transcoding page (Advanced) whether you see the D3D9 QSV codecs now.

[softworkz 4274]

That's awkward, can you please post the (latest) hw detection log?

[softworkz 4274]

Are you accessing the machine via Remote Desktop?

[Lyfesaver 73]

1 minute ago, softworkz said:

That's awkward, can you please post the (latest) hw detection log?

hardware_detection-63868552165.txt

[Lyfesaver 73]

1 minute ago, softworkz said:

Are you accessing the machine via Remote Desktop?

I currently am, yes. But I do have a monitor hooked up to the Arc card

[softworkz 4274]

3 minutes ago, Lyfesaver said:

I currently am, yes. But I do have a monitor hooked up to the Arc card

Ohhh. And you did all the driver installation via remote desktop as well?

[Lyfesaver 73]

13 minutes ago, softworkz said:

Ohhh. And you did all the driver installation via remote desktop as well?

Nooooo, all that work was done locally tho I did verify (back when I thought my forced transcoding was cuz I was remoted in) that installing drivers for the Arc was not effected when installed remotely, it is just the UHD/iGPU drivers that can (from what I read up).

Edited November 30, 2024 by Lyfesaver
typo

[softworkz 4274]

1 minute ago, Lyfesaver said:

Nooooo, all that work was done locally tho I did verify (back when I thought my forced transcoding was cuz I was remoted in) that installing drivers for the Arc was not effected when installed remotely, it is just the UHS/iGPU drivers that can (from what I read up).

When on RDP, the GPU driver is hidden away, so the driver installer might have installed those multiple instances that you had.

I just tested enabling D3D9 locally and it doesn't work anymore. It seems that Intel have removed support for that in their drivers just recently, so that's a dead end now. Sorry.

---

This is also busting my theory that Handbrake would be showing the D3D9 versions. I don't know handbrake very well. But wrt to that fork of ours, the explanation is simple: They don't have any hw detection. They are just showing what you could have and you need to manually disable what you don't have. That's still like we had it in server 3.x versions.

[Lyfesaver 73]

1 minute ago, softworkz said:

But wrt to that fork of ours, the explanation is simple: They don't have any hw detection. They are just showing what you could have and you need to manually disable what you don't have. That's still like we had it in server 3.x versions.

I dont understand that part

[softworkz 4274]

3 minutes ago, Lyfesaver said:

I dont understand that part

You said the other application would be showing the ARC GPU QSV Codecs, no?

Edited November 30, 2024 by softworkz

[Lyfesaver 73]

3 minutes ago, softworkz said:

You said the other application would be showing the ARC GPU QSV Codecs, no?

Yes.. well, Handbrake I can see it in the list and tested the actual encoding, but "that other media server" I dont know how to list so I only just tested that HW encoding works

[softworkz 4274]

27 minutes ago, Lyfesaver said:

Yes.. well, Handbrake I can see it in the list and tested the actual encoding, but "that other media server" I dont know how to list so I only just tested that HW encoding works

Okay. Do you know whether these used the ARC or iGPU?

But that doesn't matter a lot because QSV with ARC had been working before with Emby as well as I can see from the earlier logs. It was just messed up like crazy, I've never seen this before:

 

 

But let's make a Plan!

• Disable Remote Desktop altogether (temporarily)
• From now on only work locally - not even without any other RDP session (hence disable it to be sure)
• Check wether there's a BIOS update available for your mainboard, if yes, install it
• Check/enable Resizable Bar in the BIOS
• Disable Thunderbolt in the BIIOS if you have that
• Make a decision whether you ever want to use the iGPU (plus ARC) or just the ARC
  • if yes, plug your monitor into the onboard graphics (also assign the maximum memory instead of leaving Auto)
  • if no, disable the iGPU in the BIOS and plug the monitor into the ARC
• Start Windows 
• Uncheck the D3D9 switch in the diagnostics plugin
• Download Display Driver Uninstaller and run it
• Restart
• Install Intel Drivers - choose a version from 3 months ago
  (because I have a mix with iGPU and ARC for myself until 2 months ago and those drivers were working for this setup)
• Restart machine
• Start Emby Server and wait until the transoding page has loaded, then post the hw detection log

 

Edited November 30, 2024 by softworkz

[Lyfesaver 73]

26 minutes ago, softworkz said:

Okay. Do you know whether these used the ARC or iGPU?

But that doesn't matter a lot because QSV with ARC had been working before with Emby as well as I can see from the earlier logs. It was just messed up like crazy, I've never seen this before:

Those Handbrake/Other tests were done with the iGPU disabled in the BIOS. I prefer to not have it enabled.
If you look back on page 1 of this thread you will see the initial reason for this thread was that my Live TV was being transcoded when it shouldn't have been. The answer to that was simply because I primarily use Emby for Fire TV (not Emby for Android) and it had an option that other clients don't and that is "Allow Direct Play of Live TV" or something.

It took some time to find that solution but in doing so Carlo saw that I had no encoders installed and pointed that out (I had iGPU disabled) so he had me enable it just to help test.

But let's make a Plan!

• Disable Remote Desktop altogether (temporarily) OKAY
• From now on only work locally - not even without any other RDP session (hence disable it to be sure) OKAY
• Check whether there's a BIOS update available for your mainboard, if yes, install it I INSTALLED IT WHEN I WAS UPDATING DRIVER DURING THIS THREAD
• Check/enable Resizable Bar in the BIOS IT IS
• Disable Thunderbolt in the BIOS if you have that OKAY
• Make a decision whether you ever want to use the iGPU (plus ARC) or just the ARC JUST THE ARC (SEE ABOVE)
  if yes, plug your monitor into the onboard graphics (also assign the maximum memory instead of leaving Auto)
  if no, disable the iGPU in the BIOS and plug the monitor into the ARC IT IS PLUGGED INTO ARC ATM, WILL DO REST OF STEPS WHEN SERVER IS NOT IN USE
• Start Windows 
• Download Display Driver Uninstaller and run it
• Restart
• Install Intel Drivers - choose a version from 3 months ago
  (because I have a mix with iGPU and ARC for myself until 2 months ago and those drivers were working for this setup)
• Restart machine
• Start Emby Server and wait until the transoding page has loaded, then post the hw detection log

 

[softworkz 4274]

3 minutes ago, Lyfesaver said:

It took some time to find that solution but in doing so Carlo saw that I had no encoders installed and pointed that out (I had iGPU disabled) so he had me enable it just to help test.

But it wasn't always like that. In your first post (with the 19 ffmpeg logs), you did have encoders and decoders for the ARC, albeit with that crazy duplication. 
Only in the second post with logs (6 ffmpeg logs), you had no encoders.

 

15 minutes ago, Lyfesaver said:

Those Handbrake/Other tests were done with the iGPU disabled in the BIOS. I prefer to not have it enabled.

Ok, got it. If you want to use the ARC, then it's crucial that encoders are working.

The list above is just the maximum of measures I can think of - not meant to be your future configuration, but it's more effective to go for all at once and when that would lead to success, you can roll things back - one after another, though, so you can identify the cause of effect.

First of all though, let's hope that you will get to a sane configuration,

[Lyfesaver 73]

So it took me a few days because I only have a short window in the AM when I can take my server down without disrupting anyone in my family as I am an early riser and they are all very much not.

hardware_detection-63868887230.txt

I did everything you listed and I dont see any change.

On 11/30/2024 at 10:30 AM, softworkz said:

But it wasn't always like that. In your first post (with the 19 ffmpeg logs), you did have encoders and decoders for the ARC, albeit with that crazy duplication. 
Only in the second post with logs (6 ffmpeg logs), you had no encoders.

I have to disagree with you here, I have never seen anything listed under HW Encoders until Carlo said to turn on my iGPU. Maybe those first round of logs say different (I would be shocked if they did) but the transcoder page has never shown them. BTW, with the iGPU disabled the transcoder settings page is back to being instant. It is fully up before I can even navigate to it

Thank you again, softworks and Carlo for helping out so much. I hope we can fix this issue

[softworkz 4274]

2 hours ago, Lyfesaver said:

I have to disagree with you here,

There's nothing to disagree because your logs tell it very clearly.

For example: ffmpeg-transcode-e000b31b-4ffd-46cb-9854-08050dae8b6a_1.txt

It shows the weird duplication of devices: 

And it shows that qsv is usxed

It also shows successful progress:

And the filtergraph also confirms that it was done in hardware (entirely):

 

2 hours ago, Lyfesaver said:

I have never seen anything listed under HW Encoders

That's because you had set HW Acceleration to "Yes" (= Automatic), which I can also see from the log:

2 hours ago, Lyfesaver said:

I would be shocked if they did

Be shocked!

[softworkz 4274]

 

2 hours ago, Lyfesaver said:

I did everything you listed and I dont see any change.

The primary question is. Why does your system think it has TWO A380 GPUS? 

 

please execute these three commands and show the output:

wmic path win32_VideoController get Name, DriverVersion, AdapterRAM, VideoProcessor, AdapterCompatibility

wmic computersystem get model, manufacturer, HypervisorPresent, SystemType

query session

[softworkz 4274]

Even though we haven't got it working, we have burnt this down to a solid and clear problem: The GPU is detected and shown twice by the OS.

If you want to take another chance, you may try to install an OLDER driver version, like this one from May 2024: https://www.intel.com/content/www/us/en/download/785597/823163/intel-arc-iris-xe-graphics-windows.html

 

If that doesn't solve it, or you are tired of making more attempts, your way to go is this: https://www.intel.com/content/www/us/en/support/contact-us.html#support-intel-products_80939:227960

On this page, navigate like shown in this screenshot:

 

Then, try "Live Chat" or "Online Service Request".

VERY IMPORTANT 

Do not start telling stories about HW acceleration, ffmpeg, Handbrake or Emby. They cannot deal with that - obviously. 

You may mention it as a side note like saying that certain GPU features are not working properly, but your main story must be that the GPU is doubled. That should be something they can work on.

Thanks and good luck!

PS: We'd be glad to know about the outcome, so please let us know. 

[softworkz 4274]

Let me add the following: While I don't feel well about sending people elsewhere, I hope you understand that this is out of scope for Emby Support and we cannot guide you through further diagnosing, especially since it may get lengthy and unpleasant.

But here's what I would do:

• Next step would be to determine whether it's a software or hardware issue
• to do this, I would install a fresh copy of Windows on a secondary partition or HD. Maybe try Win 11 since your Win 10 22H2 is at the lowest end and will soon fall out of support
  • If Win 11 works, you may try a fresh installation of Win 10 22H2
    • If it works there, then something is messed up with your OS
    • If it doesn't work there (but on Win11), then it's an Intel driver problem
  • If it doesn't work on Win 11, then it's a hardware problem
    • You can try to reset BIOS settings and load defaults
    • You can try to put the ARC into a different PCI slot
    • You can try to put the ARC into a different PC
      • If it shows the same issues there, then the ARC is broken
      • if it's working there, then your mainbord might be defective or there's some incompatibility between your mainboard and the ARC

For testing "works, works not", the first criteria is the doubling of the GPU, when you see this, then there's no point in  even trying Emby.

[Lyfesaver 73]

Wow, thanks for all that info, and yes I am shocked as the only thing I did was update the driver between those two attempts but I guess that is what did it. Don't get me wrong, your knowledge vastly outdoes mine as I barely have an understand of how codecs even work. As a matter of fact I would be shocked again if my brain did not purposefully forget as much about codecs as it could after the many, many times I ended up in "Codec Hell" back in the early aughts Also, as I mentioned I am a pretty big moron so I get shocked a lot lol

 

That being said I really dont mind you pointing out the issue lies elsewhere and support would be better achieved thru them. After all the effort and good info you have provided you are clearly not "passing the buck", so to speak. All good.

As to the info provided, I will try that out and definitely let you know the results.