18 Nov 2019- TVDB are still in the process of fixing a number of bugs that have broken the TVDB scraper and any add-on that relies on TVDB data. TVDB are still working to rectify the problems.

  •   
  • 1
  • 87
  • 88
  • 89(current)
  • 90
  • 91
  • 218
  •   
  Thread Closed
v17 LibreELEC Testbuilds for RaspberryPi (Kodi 17.0)
(2016-07-14, 10:06)the_jaguar Wrote: I ran into an interesting issue today - I was playing a 3D MVC ISO file that I ripped from my Blu-ray disk, and after being able to successfully play for a while, it abruptly stopped with about 25 minutes of the movie left (turns out that it stopped at the beginning of a new chapter). After trying to play that part multiple times with no success, I converted the ISO to an MKV (using makemkv) and I was able to play past the part where it had stopped earlier on VLC. When I try playing this file on Kodi, it plays fine but I can't fast forward/rewind/seek through the movie. The TV screen shows the frame for that second but remains stuck in that screen while the info bar shows that the movie is continuing to play. Is this a known issue?

Not something known about. If you can provide a sample file that shows the issue, that would be useful.
Otherwise a debug log (wiki) when the problem occurs may have some clues.
(2016-07-14, 14:01)hawkeyexp Wrote: Changing KEY_OK to KEY_ENTER is working for me with mxe remote.

For example
KEY_LIST
KEY_CONTEXT_MENU
KEY_CHANNELUP
KEY_CHANNELDOWN
COLOR BUTTONS
* and #
are still not working with build 0713
Thank you (and all others who helped) for your feedback!

I've finally been able to reproduce the issue and track down what's going wrong.

The next Milhouse build should include a patch that (hopefully) fixes the issue.

so long,

Hias
(2016-07-14, 15:31)HiassofT Wrote:
(2016-07-14, 14:01)hawkeyexp Wrote: Changing KEY_OK to KEY_ENTER is working for me with mxe remote.

For example
KEY_LIST
KEY_CONTEXT_MENU
KEY_CHANNELUP
KEY_CHANNELDOWN
COLOR BUTTONS
* and #
are still not working with build 0713
Thank you (and all others who helped) for your feedback!

I've finally been able to reproduce the issue and track down what's going wrong.

The next Milhouse build should include a patch that (hopefully) fixes the issue.

so long,

Hias
Many thank !
(2016-07-14, 02:25)smp1 Wrote: I noticed a nasty bug - sometimes when I switch from Kodi's GUI to an HD TV channel, I get a lot of frame skips. If I go to Video settings and switch the deinterlacing off and the on again (or switch the deinterlace methods back and forth) - the frame skips are gone.

This issue seems to be present in most recent builds. Not sure which is the last good one. There is definitely no such issue in build #0625.
I stuck at #0625 too because i get black screen when switching to some pvr-channels. Have to skip some seconds of stream to get picture. all builds i tried after 0625 have this problem here. Using RPi2 with argus pvr.
(2016-07-14, 19:25)Screech Wrote:
(2016-07-14, 02:25)smp1 Wrote: I noticed a nasty bug - sometimes when I switch from Kodi's GUI to an HD TV channel, I get a lot of frame skips. If I go to Video settings and switch the deinterlacing off and the on again (or switch the deinterlace methods back and forth) - the frame skips are gone.

This issue seems to be present in most recent builds. Not sure which is the last good one. There is definitely no such issue in build #0625.
I stuck at #0625 too because i get black screen when switching to some pvr-channels. Have to skip some seconds of stream to get picture. all builds i tried after 0625 have this problem here. Using RPi2 with argus pvr.

+1 Using #0707 with Argus PVR
Location UK; Media server Windows 7 with ArgusTV 2.3 with TBS6981 DVB-S2 x4 and DVB-T x 2:All network connections cabled on 1Gb router Raspberry Pi2 1GB x 2; RPI 3 x1; PiB+512MB x 3; TV Samsung 55" C8000; AV Denon AVR X2200W
(2016-07-14, 19:25)Screech Wrote: I stuck at #0625 too because i get black screen when switching to some pvr-channels. Have to skip some seconds of stream to get picture. all builds i tried after 0625 have this problem here. Using RPi2 with argus pvr.

Can you provide a link to a debug log from the latest build while reproducing this issue.
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-07-14, 19:25)Screech Wrote: I stuck at #0625 too because i get black screen when switching to some pvr-channels. Have to skip some seconds of stream to get picture. all builds i tried after 0625 have this problem here. Using RPi2 with argus pvr.

#0626 was the bump to ffmpeg 3.1. The ffmpeg bump is here to stay.

A debug log (wiki) from #0625 and one from #0626 would be useful. They both should include a similar channel switch, with a black screen occurring in #0626.
(2016-07-11, 06:33)smp1 Wrote: A couple of days ago I bought a DVBSky s960 DVB-S tuner. I tested it on RPi3 with TvHeadend on latest Milhouse builds and an official 7.0.2 Kodi 16 build.

I have to say that TvHeadend 4.2 performs shockingly bad in Milhouse builds compared to the official LE 7.0.2.
Now that I had enough time to test my USB DVB-S dongle on RPI3 - I stand by my initial observation regarding poor performance in Krypton.
Krypton has issues with HD channels, especially higher bitrate (~18mbps at peak) channels. I steadily get 1-2 h264 continuity errors during 1 hour of testing. In Jarvis I get absolutely no continuity errors. I used Bob deinterlace on both Krypton and Jarvis.

From what I've read - DVBSky S960 is one of the better dongles for RPi and Linux in general so it should not be an issue here.

Also, build #0625 is the last one that works more or less OK. It kinda went downhill since 0626 (new ffmpeg?).
(2016-07-14, 20:20)smp1 Wrote: Now that I had enough time to test my USB DVB-S dongle on RPI3 - I stand by my initial observation regarding poor performance in Krypton.

The DVB / deinterlace issue can be improved (at least to Jarvis levels, but hopefully beyond), but you'll need to run the tests I've suggested (and there will be more).

The ffmpeg/PVR issue is unrelated to that. We'll need to get decent bug reports and logs to the right people (fernetmenta/fritch).
I ran all your suggested tests, the v3d_limiter does nothing to improve things. v3d_freq=500 also has no effect.
(2016-07-14, 20:51)smp1 Wrote: I ran all your suggested tests, the v3d_limiter does nothing to improve things. v3d_freq=500 also has no effect.

I don't see any reports posted about this.

If you want this fixed it needs careful testing with detailed reports. Not just "it didn't work".
The v3d_limiter is a dial that can make the deinterlace fast, but impact heavily on sdram on one end, and slow, but have little effect on sdram at the other.
The v3d_freq (and perhaps core_freq) can be used to improve deinterlace speed to compensate for this.

Are you saying the new suggestions for v3d_limiter settings had zero effect at all?
I'm not suggesting any of them would necessarily be perfect, but I need to hear results like:
"with that setting the occurrence of corruption in the stream was reduced from every 10 seconds to every 30 seconds, but audio and video began to lag".
0x1080f1 = no effect. Didn't notice any error increase or decrease.
0x10fff1, 0x0210f1, 0x2080f1 = no testing is possible with those. It runs like a slideshow for a few seconds, then the video just freeze.
(2016-07-14, 21:10)smp1 Wrote: 0x1080f1 = no effect. Didn't notice any error increase or decrease.
0x10fff1, 0x0210f1, 0x2080f1 = no testing is possible with those. It runs like a slideshow for a few seconds, then the video just freeze.

Does enabling omxplayer help? That may be less aggressive about compensating when running behind.
For now we just want to know about what values are needed to stop the corruption.
Don't worry so much about it running slowly (that can be focussed on later).
I didn't try the v3d_limiter settings with omxplayer. I tried it with default settings, it doesn't help.
Not sure if this is helpful but I can completely stop the corruption if I press Esc during the playback and the video runs on the background of the transparrent menu. When the video is skipping frames there is no more corruption.
(2016-07-14, 22:17)smp1 Wrote: I didn't try the v3d_limiter settings with omxplayer. I tried it with default settings, it doesn't help.
Not sure if this is helpful but I can completely stop the corruption if I press Esc during the playback and the video runs on the background of the transparrent menu. When the video is skipping frames there is no more corruption.

If video is not running fullscreen, then deinterlace switches to half rate.
I suspect you would have the same effect by choosing "MMAL - Advanced (half)" or "MMAL - Bob (half)" as deinterlace method.
  •   
  • 1
  • 87
  • 88
  • 89(current)
  • 90
  • 91
  • 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