20 Nov 2019 - TVDB Scraper v3.2.0 is now available which reinstates scraping. TVDB are still in the process of fixing a number of bugs so there may still be further breakages. See this post. 2901570 (post)

  •   
  • 1
  • 141
  • 142
  • 143(current)
  • 144
  • 145
  • 218
  •   
  Thread Closed
v17 LibreELEC Testbuilds for RaspberryPi (Kodi 17.0)
(2016-09-10, 21:07)popcornmix Wrote: Can you try disabling both CEC and GPU resampling and see if problem recurs?
Same story with disabled CEC and resampling low, medium. A few minutes freezes again.
If i can get a crashlog i will upload it.
(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?
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-10, 21:09)Milhouse Wrote:
(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?
Three consecutive Kodi crashlogs after install of and 1st boot of #0910

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) 2372450 (post)
rPi3B+, SanDisk Ultra 8Gb SD, Milhouse kernel_5.x LE ​Testbuild (Kodi 19 Matrix) -> Onkyo TX-SR608 AV Receiver -> Philips 42" LCD TV
KVIM2 Pro, SanDisk Ultra 8Gb SD, kernel_5.x LE Testbuild (Kodi 19 Matrix) -> LG 27UD69-W 4K Monitor -> AudioEngine A2+ Speakers
@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?
Texture Cache Maintenance Utility: Preload your texture cache for optimal UI performance. Remotely manage media libraries. Purge unused artwork to free up space. Find missing media. Configurable QA check to highlight metadata issues. Aid in diagnosis of library and cache related problems.
(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?
rPi3B+, SanDisk Ultra 8Gb SD, Milhouse kernel_5.x LE ​Testbuild (Kodi 19 Matrix) -> Onkyo TX-SR608 AV Receiver -> Philips 42" LCD TV
KVIM2 Pro, SanDisk Ultra 8Gb SD, kernel_5.x LE Testbuild (Kodi 19 Matrix) -> LG 27UD69-W 4K Monitor -> AudioEngine A2+ Speakers
Yes, add
Code:
<loglevel hide="false">1</loglevel>
to advancedsettings.xml

Knowing exactly when this started should hopefully provide a clue as to what is causing it.
Texture Cache Maintenance Utility: Preload your texture cache for optimal UI performance. Remotely manage media libraries. Purge unused artwork to free up space. Find missing media. Configurable QA check to highlight metadata issues. Aid in diagnosis of library and cache related problems.
(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 channel
Same 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, 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.
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?
I'm having the same behaviour/issues on my rpi2.
#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
(2016-09-11, 12:15)Milhouse Wrote: Yes, add
Code:
<loglevel hide="false">1</loglevel>
to advancedsettings.xml

Knowing exactly when this started should hopefully provide a clue as to what is causing it.
OK with debug logging option enabled in advancedsettings.xml, went back-to #0907 then #0908, 9 & 10 and
Frustratingly no kodi crashes in test builds with debug logging switched on...Kodi debug logs

#0907
#0908
#0909
#0910
rPi3B+, SanDisk Ultra 8Gb SD, Milhouse kernel_5.x LE ​Testbuild (Kodi 19 Matrix) -> Onkyo TX-SR608 AV Receiver -> Philips 42" LCD TV
KVIM2 Pro, SanDisk Ultra 8Gb SD, kernel_5.x LE Testbuild (Kodi 19 Matrix) -> LG 27UD69-W 4K Monitor -> AudioEngine A2+ Speakers
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?
(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, 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...
Log http://sprunge.us/XNQM
CEC - off, resample - low, threshold - 2
  •   
  • 1
  • 141
  • 142
  • 143(current)
  • 144
  • 145
  • 218
  •   
  Thread Closed
 
Thread Rating:
  • 19 Vote(s) - 4.63 Average



Logout Mark Read Team Forum Stats Members Help
LibreELEC Testbuilds for RaspberryPi (Kodi 17.0)4.6319