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
  • 19
  • 20
  • 21(current)
  • 22
  • 23
  • 168
  •   
  Thread Closed
OpenELEC Testbuilds for RaspberryPi (Kodi 16.0)
No new build today - network/routing problems with BT (my ISP) mean it's impossible to reliably download (from git/github) or upload (to ftp server). Not sure when the problem will be resolved as BT are yet to accept there is even a problem despite multiple reports from users nationwide throughout the day. Ho hum.
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.
(2015-07-28, 23:02)Milhouse Wrote: No new build today - network/routing problems with BT (my ISP) mean it's impossible to reliably download (from git/github) or upload (to ftp server). Not sure when the problem will be resolved as BT are yet to accept there is even a problem despite multiple reports from users nationwide throughout the day. Ho hum.

If anyone is missing out I did a Milhouse-style build.
https://drive.google.com/file/d/0B-6zmED...sp=sharing

Highlights.
New firmware with fixes for timestamps (fix for time jumping to zero when seeking/ff/rew)
HD advanced deinterlace should now trigger turbo mode automatically.
Improved smoothness with ff/rew.
Some files where video stopped before audio at end of file should be improved.

Changes:

New firmware:
firmware: arm_loader: Make turbo request reference counted rather than boolean
firmware: di_adv: Request turbo mode when doing qpu deinterlace
firmware: video_decode: fixes to timestamp handling

newclock4:
[mmalcodec] Use both dts and pts for determining amount of queued data
dvdplayer - consider clock not last frame on screen when going rewind PR7655
@popcornmix and @Milhouse

I just noticed that in Kodi official release, it's using ffmeg 2.6.3, whereas for RPi/RPi2 version, ffmeg was bumped to 2.7.1 in built #0713. Is it possible that it's the ffmeg that lead to problem in x265/HEVC video playback?

Is it possible to have a build with rolled back to pre- ffmeg 2.7.1 (or ffmeg 2.6.3 specifically) for me to test?
(2015-07-29, 15:03)wchick132 Wrote: I just noticed that in Kodi official release, it's using ffmeg 2.6.3, whereas for RPi/RPi2 version, ffmeg was bumped to 2.7.1 in built #0713. Is it possible that it's the ffmeg that lead to problem in x265/HEVC video playback?

I don't think it's ffmpeg. I think it's a kernel update to firmware/mailbox driver which is heavily used by gpu accelerated hevc.
Note: gpu accelerated hevc is only in milhouse builds, so official OE shouldn't have this issue (but hevc performance is lower).
Thanks for keeping thing going popcornmix! Those latest firmware changes look nice.

What is the overclock recommendation for 1080i60 playback using advance deinterlacing at this point? I've been using gpu_freq=300 with success, but every now and then a news ticker will get jittery. It gets even more so when I bring up the playback information overlay to see if it is skipping frames.

Also, for using advanced deinterlacing, what are the recommended settings for "adjust display refresh rate to match video" (mine is on) and "sync playback to display" (mine is on and using method resample audio) ?
I just tested many movies on RPi1 and 2 (MP4/DVD/ISO/PAL/24p/25p) after "The "prefer pts" option is gone."
And all content play's super smooth via OMX=on and MMAL=off and No overclocking here.

Great ! Thanks popcornmix and Milhouse for all your works.
(2015-07-29, 15:13)popcornmix Wrote:
(2015-07-29, 15:03)wchick132 Wrote: I just noticed that in Kodi official release, it's using ffmeg 2.6.3, whereas for RPi/RPi2 version, ffmeg was bumped to 2.7.1 in built #0713. Is it possible that it's the ffmeg that lead to problem in x265/HEVC video playback?

I don't think it's ffmpeg. I think it's a kernel update to firmware/mailbox driver which is heavily used by gpu accelerated hevc.
Note: gpu accelerated hevc is only in milhouse builds, so official OE shouldn't have this issue (but hevc performance is lower).

How about OE 5.95.3, does it also uses gpu accelerated hevc? Please note that the OE 5.95.3 also has the same x265/HEVC playback problem as build #0714.
(2015-07-29, 15:15)zaphod24 Wrote: Thanks for keeping thing going popcornmix! Those latest firmware changes look nice.

What is the overclock recommendation for 1080i60 playback using advance deinterlacing at this point? I've been using gpu_freq=300 with success, but every now and then a news ticker will get jittery. It gets even more so when I bring up the playback information overlay to see if it is skipping frames.

Also, for using advanced deinterlacing, what are the recommended settings for "adjust display refresh rate to match video" (mine is on) and "sync playback to display" (mine is on and using method resample audio) ?

Adjust display refresh rate to match video is recommended.
Sync playback to display is recommended with dvdplayer. (with omxplayer it's less important).
If "PLL adjust" works for you, then it is theoretically better. It can make small adjustments to audio/video sync without resampling audio, so avoids pitch warbles and works with passthough.
Some displays/receivers don't like it and you can get audio/video dropouts. Resample audio is the safer choice.

If you switch deinterlace to "bob" do you still get the same stutter?
We are hoping gpu_freq=300 is enough for 1080i60 advanced deinterlace, but it is quite close and a bit more may be safer.
Try removing "force_turbo", set "over_voltage=2" and "gpu_freq=400" and see if it works better.
(2015-07-29, 13:50)popcornmix Wrote: If anyone is missing out I did a Milhouse-style build.

Thanks @popcornmix!

I probably won't be in a position to upload a new build tonight either - BT have just announced they've identified the fault in their network, but will only be able to implement the fix overnight. I'll publish a new build (with all the missed updates) once the fix is in, whenever that happens.
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.
hi,
with the build #0729-gc37b5a7 my first RPi2 with hifiberryDACplus hang-off (freeze) with videoAddons (MTV.de).
Not able to handle this hardwired network rpi2. (fresh install)

The second rpi2 on my LCD TV over HDMI makes this Job better, but stops on playing between two Videos with this build

...switch back to #0721 and all work fine on both RPi2.
(OT)

Have any people testet here Windows 10pro?

I'm not able ( and also other people in the net) to share files on this System over smb - after 2 days a click on my Win7pro backup and all's right with the world.

Windowsdisaster²

:-)
(2015-07-29, 18:55)Milhouse Wrote: I probably won't be in a position to upload a new build tonight either - BT have just announced they've identified the fault in their network, but will only be able to implement the fix overnight. I'll publish a new build (with all the missed updates) once the fix is in, whenever that happens.

Oh no! Don't BT know how important your internet connection is?

I'll try making another build as I've got a few new fixes for testing.
I've been giving Isengard branch some care and attention as release is imminent (OpenELEC and OSMC are close to releasing, but I've got a chance for a few last minute fixes).
Getting a build out with the new fixes in gives a chance to spot regressions before Isengard final is in widespread use.
will the "advanced deinterlacing" (which is *fantastic* by the way) also be included in the openelec isengard release?

Thanks,
Max
(2015-07-29, 22:42)maxodolo Wrote: will the "advanced deinterlacing" (which is *fantastic* by the way) also be included in the openelec isengard release?

Not the first release. It's currently just a bit too risky (e.g. people enabling it without overclock and getting stuttery video).
When we get to a point where it is seamless (e.g. no overclock needed, or fully automatic overclock) then it might be added to Isengard branch.

I'll think about adding an advancedsetting to unlock it...
Another Milhouse-style build:
https://drive.google.com/file/d/0B-6zmED...sp=sharing

newclock4
  • [omxplayer] Set audio properties for passthrough
    We weren't setting the stream_channels property for passthrough for omxplayer (we do with Pi Sink)
    That means we were using 2 in number of channels of the AudioInfoFrame packet, rather then 0
    which is 'refer to stream header' which is correct for passthrough

  • [omxplayer] Allow automatic switching back to omxplayer after it has been disabled
    Omxplayer gets disabled when it is unsuitable (e.g. software decoder required, or ALSA audio or AC3 transcode).
    However if you play another file without quitting dvdplayer, it doesn't reconsider.
    E.g. play divx3 file and omxplayer is disabled. If you then launch a h.264 file while first file is still playing it doesn't switch
    back to omxplayer as you might expect.
    This patch allows a switch back to omxplayer mode

  • [rbp] Leave 3D framepacking output disabled by default

  • [omxplayer] Support per refresh rate display latency settings
    See here

  • [mmalrenderer] Wait for vsync before submitting to mmal when display sync is disabled
    This avoids an issue where video occasionally goes stuttery after a seek, until the next pause/play or seek.
    The issue is when display sync is disabled, and framerate of video matches display, and render times are coincident with vsync
    you find that depending on timestamp/scheduling jitter, you may or may not get an update each vsync resulting in stuttery video.
    Some scheme to force render times to be dependent on vsync is required. We do this by blocking in RenderUpdate unto next vsync.
  •   
  • 1
  • 19
  • 20
  • 21(current)
  • 22
  • 23
  • 168
  •   
  Thread Closed
 
Thread Rating:
  • 10 Vote(s) - 5 Average



Logout Mark Read Team Forum Stats Members Help
OpenELEC Testbuilds for RaspberryPi (Kodi 16.0)510