2016-09-11, 08:16
2016-09-11, 08:49
(2016-09-09, 17:37)polo_joe Wrote: Resample method middle solves the problem. No more dropouts.@popcornmix
@popcornmix
Any chance we get this behaviour with gpu resampling?
2016-09-11, 11:04
Quote:Sorry I can not confirm that, 720p run well.
I use at deinterlacing "MMAL - Bob (half)".
Here I have only issues with 720p when I switch from 1080i channels. I use MMAL and "auto". With OMX there is no problem.
My TV channels all are H.264 encoded. When I stop/play the channel it's working fine.
I think the deinterlacer is still active after switch from 1080i to 720p
2016-09-11, 11:20
(2016-09-10, 21:09)Milhouse Wrote:Three consecutive Kodi crashlogs after install of and 1st boot of #0910(2016-09-10, 20:38)MikeKL Wrote: Thought that these recent clean build/boot then immediate kodi crash may hold some useful info? compared to kodi crash logs when not sure at all what exactly doing to cause an infrequent kodi crash after varied hours of use of a nightly build?
Yes, they're useful, but they point to EPG database related crashes which are a new type of crash not seen before (or at least recently). If this started with #0908 then possibly PR10369?
1st
2nd
3rd
Reminder that I was previously having crashes at initial boot of Krypton nightly build, which stopped occurring after combination of ensuring running only one pvr backend (tvheadend) and removing TV29.db during every re-boot of Pi (Currently still removing TV29.db at boot) http://forum.kodi.tv/showthread.php?tid=...pid2372450
2016-09-11, 11:29
@MikeKL thanks. Would it be possible to produce a crashlog that has debug logging enabled (just in case something useful is logged before the crash)? Do we know when (which build) this crashing started, I think your first crashlog is from #0908 - is this when it started?
2016-09-11, 12:07
(2016-09-11, 11:29)Milhouse Wrote: @MikeKL thanks. Would it be possible to produce a crashlog that has debug logging enabled (just in case something useful is logged before the crash)? Do we know when (which build) this crashing started, I think your first crashlog is from #0908 - is this when it started?Yes can try: is it possible to switch debugging on before a load of a nightly build and debugging will run afterwards?
(Reason I ask is subsequent re-boots after the three above crashes on #0910, I have not had a single kodi crash..and currently have debug swithed on)
Yes #0908 is first build for a while (where I have noted) kodi crash on 1st boot after an installation of a nightly build.
(Dont watch every boot, but most as I use the Libreelec dev update addon to install each nightly)
Can go back to #0907 to check/confirm if helpful?
2016-09-11, 12:15
Yes, add
to advancedsettings.xml
Knowing exactly when this started should hopefully provide a clue as to what is causing it.
Code:
<loglevel hide="false">1</loglevel>Knowing exactly when this started should hopefully provide a clue as to what is causing it.
2016-09-11, 12:55
(2016-09-10, 22:32)smp1 Wrote:(2016-09-10, 21:10)herrmeier01 Wrote: Here I still have stutter with Live-TV when I switch from 1080i channel to 720p channelSame here.
As far as I remember this was fixed in one of the earlier builds but that fix was later removed and never showed up again.
(2016-09-11, 11:04)herrmeier01 Wrote:Quote:Sorry I can not confirm that, 720p run well.
I use at deinterlacing "MMAL - Bob (half)".
Here I have only issues with 720p when I switch from 1080i channels. I use MMAL and "auto". With OMX there is no problem.
My TV channels all are H.264 encoded. When I stop/play the channel it's working fine.
I think the deinterlacer is still active after switch from 1080i to 720p
I am having the exact same problem. Only when switching from a 1080i H264 channel to a 720p h264 channel. With OMX enabled everything is good.
when a channel stutters you can also switch the deinterlacing method and then go back to "auto". this seems to disable the falsely running deinterlacing.
The last working build (with the mentioned fix) is 0726. After that i believe it was removed because it was causing crashes for someone.
the problem is that @popcornmix has not been able to reproduce this with his setup. therefore it is hard to debug.
But so far i have not come up with a way to reproduce this with a recording so that popcornmix can debug this.
Is there a way to force OMX only for LiveTV an keep using MMAL for the rest?
2016-09-11, 13:20
(2016-09-11, 12:55)niwa2 Wrote: I am having the exact same problem. Only when switching from a 1080i H264 channel to a 720p h264 channel. With OMX enabled everything is good.I'm having the same behaviour/issues on my rpi2.
when a channel stutters you can also switch the deinterlacing method and then go back to "auto". this seems to disable the falsely running deinterlacing.
The last working build (with the mentioned fix) is 0726. After that i believe it was removed because it was causing crashes for someone.
the problem is that @popcornmix has not been able to reproduce this with his setup. therefore it is hard to debug.
But so far i have not come up with a way to reproduce this with a recording so that popcornmix can debug this.
Is there a way to force OMX only for LiveTV an keep using MMAL for the rest?
2016-09-11, 13:57
#910 iptv stotter and stopped
runing on tvheadend server.
im install first libreelec 7.0.005 and updatet to the last #0910 build
second i make a Hard-Reset on this build and test the playlist on tvheadend.
http://sprunge.us/DZLT
and i have found one more bug, on the tvh client.
If I turn it on = crashes kodi
http://pastebin.com/dkSN7KYN
runing on tvheadend server.
im install first libreelec 7.0.005 and updatet to the last #0910 build
second i make a Hard-Reset on this build and test the playlist on tvheadend.
http://sprunge.us/DZLT
and i have found one more bug, on the tvh client.
If I turn it on = crashes kodi
http://pastebin.com/dkSN7KYN
2016-09-11, 15:19
(2016-09-11, 12:15)Milhouse Wrote: Yes, addOK with debug logging option enabled in advancedsettings.xml, went back-to #0907 then #0908, 9 & 10 and
to advancedsettings.xmlCode:<loglevel hide="false">1</loglevel>
Knowing exactly when this started should hopefully provide a clue as to what is causing it.
Frustratingly no kodi crashes in test builds with debug logging switched on...Kodi debug logs
#0907
#0908
#0909
#0910
2016-09-11, 16:09
Are there any plans to improve VP9 support?
It's claimed that decoding VP9 is 55% faster then hevc on ffmpeg for x86.
https://blogs.gnome.org/rbultje/2015/09/...hevch-264/
I tried some VP9 files, and they were slow and out of sync on the RPI3, while on my older (2010) x86 hardware (Intel U4100) VP9 1080p content played much better then hevc or even h264.
AFAIK until now VP9 decoding is optimized for x86, not for ARM (NEON). But when it's faster on x86, can't it be faster on ARM too?
It's claimed that decoding VP9 is 55% faster then hevc on ffmpeg for x86.
https://blogs.gnome.org/rbultje/2015/09/...hevch-264/
I tried some VP9 files, and they were slow and out of sync on the RPI3, while on my older (2010) x86 hardware (Intel U4100) VP9 1080p content played much better then hevc or even h264.
AFAIK until now VP9 decoding is optimized for x86, not for ARM (NEON). But when it's faster on x86, can't it be faster on ARM too?
2016-09-11, 16:59
(2016-09-11, 16:09)ElectricPim Wrote: AFAIK until now VP9 decoding is optimized for x86, not for ARM (NEON). But when it's faster on x86, can't it be faster on ARM too?
As you already should know Kodi makes use of ffmpeg to do software decoding.
This question should be directed to ffmpeg developers.
And as you already should know both Kodi and ffmpeg are OSS - feel free to develop such improvements and submit them for review to ffmpeg-devel.
2016-09-11, 17:06
(2016-09-11, 16:09)ElectricPim Wrote: Are there any plans to improve VP9 support?
VP9 is only really used by Google, who also provide all files in H.264 format, so no, VP9 optimisation is very low priority.
Searching a popular torrent site for HEVC gives almost 100k hits. Searching for VP9 gets 2...
