Yeah I saw that in the settings but most channels are 1080p
Can you reproduce the issue with a recording?
I have never used recording for live TV, not sure if it’s even possible using the iptv simple client addon I’m using to watch live TV.
Is it relevant to try recording even if I never use it?
I tried some higher bitrate content with hw acceleration turned off, and it seems vero plays these just fine using software decoding. Will give it try with even higher quality when I get the chance
Hmm, this keeps causing issues for me. Even if I set hw acceleration for h264 to always be disabled, the V4k+ fails to play 1080p streams smoothly resulting in audio playing fine, but videos now play back in slow motion (think x0.25 speed)
So now I have no way of playing 1080p iptv streams reliably
This has to be a vero specific issue since my other two Pi3’s with osmc plays all streams without any issues at all.
Is there anything we can do to get around this @sam_nazarko?
I find for some live TV channels I have to manually set ‘deinterlace method’ to ‘disabled’, and the playback goes from weirdly choppy to ‘normal’…
Thanks, will try this and hope it works
Have seen there are a few new posts on here and wanted to give an update as I have been meaning to and kept forgetting. I had previously marked this as resolved based on @grahamh recommendation here since initially it seemed to fix my problem. But after a few days I noticed it only fixed the issue for some channels. But I kept finding more and more channels where the issue was still occuring. I was close to my return window on my Vero running out so I decided to return it since I simply watch too much Live TV and wasn’t sure if I was going to be able to solve the problem. So unfortunately I’m going to un-mark this as solved because I don’t want to point people in the wrong direction if others come across this same issue. But still definitely try @grahamh’s suggestion, maybe it will work for all of your channels even though it only worked for some of mine. And I hope @jappish84 finds a solution to their problem. Thanks everyone.
Thanks again for these suggestions! After turning off hw acceleration AND deinterlacing, all tested live TV channels seem to work as expected! I’m only on day 1 of testing but looks promising!
Wish there was a way to auto toggle hw-acceleration based on media source instead of just only ‘HD and up’
Since there’s currently no way of disabling hw acceleration on/off based on source i was hoping to find a command line that does this?
My idea is to let home assistant run the command through ssh and toggle the hardware acceleration on/off based on what’s playing. It’s pretty easy to distinguish live video from local video using the default kodi component in home assistant.
Sorry for the late reply, doesn’t seem to work on osmc
I tried http://<client-ip>:<client-port>/jsonrpc?request={"jsonrpc":"2.0","method":"Settings.GetSettingValue","params":{"setting":"videoplayer.usemediacodecsurface"},"id":1}
and http://<client-ip>:<client-port>/jsonrpc?request={"jsonrpc":"2.0","method":"Settings.GetSettingValue","params":{"setting":"videoplayer.usemediacodec"},"id":1}
while toggling the state of MPEG2, MPEG4 and h264 acceleration from always to never but always get the response that the state is true.
I’m guessing OSMC’s hw-acceleration (specifically the h264 one) is located somwhere else?
That is not a toggle and that particular command is just asking what the current value is. Also not the correct setting. What your looking for is…
To get the current value of the setting.
http://<client-ip>:<client-port>/jsonrpc?request={"jsonrpc":"2.0","method":"Settings.GetSettingValue","params":{"setting":"videoplayer.useamcodec"},"id":1}
To turn off.
http://<client-ip>:<client-port>/jsonrpc?request={"jsonrpc":"2.0","method":"Settings.SetSettingValue","params":{"setting":"videoplayer.useamcodec","value":false},"id":1}
To turn on.
http://<client-ip>:<client-port>/jsonrpc?request={"jsonrpc":"2.0","method":"Settings.SetSettingValue","params":{"setting":"videoplayer.useamcodec","value":true},"id":1}
Awesome, this works great! Thanks!
Yeah, I forgot to mention that I was using the "Settings.SetSettingValue"
in my previous post, but that ofcourse didn’t work since I was using the wrong setting-parameter.
Thanks again!
Your welcome. Just to add a bit more for anyone else that may be looking to do something similar what I did is copy the entirety of ~/.kodi/userdata/guisettings.xml
to a difference checker (specifically I accessed the file from Windows via SMB and opened it in Notepad++ and then copied it to the clipboard, then pasted it into www.diffchecker.com
) and then changed the setting in question in Kodi and backed out of the settings window so the change would get written out to the file. I then copied the text from the now changed guisettings.xml to the diff checker as well and used that to easily find what the proper setting was.
Wow, thanks for sharing! This is going in to my notes for future use
Of course anyone who uses TotalCommander can navigate directly to \\<IP of vero>\osmc\.kodi\userdata
and compare two files with a couple of clicks.
I tried using this method to identify only the h264 acceleration setting while turning it from always to never and comparing the file, but the h264 setting doesn’t seem to write anything to the guisettings.xml
file … any idea if it’s possible to just toggle the h264 setting?
Disabling hw acceleration completly off unfortunately affects live tv aswell since I guess it uses mpeg2 and mpeg4 streams. My idea is to disable h264 when live TV is played, and turn it on for every other scenario.
I’m not sure what to tell you as it worked just fine for me using what I described above. Maybe you missed the part about backing out of the settings page so the change got written to disk?
Always
<setting id="videoplayer.useamcodech264" default="true">0</setting>
Never
<setting id="videoplayer.useamcodech264">9999</setting>
HD and up
<setting id="videoplayer.useamcodech264">800</setting>
Yup, that was it, tried it again, this time making sure I backet out from the menu and it works. Big thanks again!
Glad to hear this is now solved.
Sam