• 1
  • 95
  • 96
  • 97(current)
  • 98
  • 99
  • 174
OpenELEC Testbuilds for RaspberryPi
(2013-02-22, 16:03)popcornmix Wrote: @rbej/MilhouseVH

https://github.com/xbmc/xbmc/pull/2249
is worth testing. It makes SSA/ASS subs and video overlay updates smoother. (include all the commits in the patch, even though are not Pi specific)

Might be worth testing a build with this in (also include this https://github.com/xbmc/xbmc/pull/2273 which is well worthwhile).

Leave out the "seek-before-zero" and "new stall" patches until we get a solution.

Apologies for the extended break...

So I finally installed this new test build, without seek and without new stall patches, also without resolution_change patch as that is no longer compatible when the 2249 buffering patch is included. also included the 2273 SSA patch.

My initial observation is that when starting an HD MKV, there is more buffering at the start of the movie - the "Buffering...30% (etc.)" lozenge appears when before this patch it didn't (or only very briefly - the Pi is wired to a GigE switch). This is with no special "network" settings added to advnacedsettings.xml (so no alwaysforcebuffer or freememorycachepercent specified).

In order to test SSA subtitles, I tried the Subtitle test files from the DVD5 Test Disc on a 1GHz (ARM) 500Mhz (Core) 512MB Pi/128MB GPU, and observed the following:

Embedded_sub-idx_MKV: Playback started quickly, played OK with subtitles visible and in sync, low cpu (25%) during playback
External_sub-idx: 100% CPU for some time (22 seconds) before playback started (not buffering, just slow to start), played OK with subtitles visible and in sync, low cpu (25%) during playback
ExtTestSRT: Playback started quickly, played OK with subtitles visible and in sync, low cpu (30%) during playback

Except with the last SRT test file, disabling subtitles while a subtitle is visible leaves this last subtitle permanently visible.

While browsing the SSA files, the CPU initially hit 100% for quite a while, I'm guessing this was while trying to extract images (Macross_Frontier seemed to take a long time). Once it had settled down to normal....

SSA - Amatsuki_20s-_Sub_Test_3.mkv: Quick to start, playback OK, subtitles look good, low cpu (30%) during playback
SSA - Kannagi_20s-_Sub_Test_5.mkv: Quick to start, playback OK, subtitles look good, low cpu (30%) during playback
SSA - Macross_Frontier_-_Sub_Test_1.mkv: Slow to start (100% CPU for 8-10 seconds), playback OK, subtitles look good, moderate cpu (40%) during playback.
SSA - Seto_no_Hanayome_1m20s-_Sub_Test_4.mkv: Quick to start, subtitles look fine, low cpu (25%) during playback. Other notes: Subs start at 1:17; Two sub tracks available, both tested OK.
SSA - SSA_15subtitles.mkv: Quick to start, subtitles look good, moderate cpu (50%) during playback. Other notes: 16 sub tracks in total, tested two or three all OK.
SSA - Zoku_Natsume_Yuujinchou_-_Sub_Test_2.mkv: Quick to start, playback OK, subtitles are OK but at two points the sub stays on screen too long (compared with vlc), low cpu (35%) during playback

With all of the SSA test files, disabling subs while subtitles are visible leaves the last subtitle permanently visible. Switching to a different sub track (eg. Russian to English in SSA_15subtitles.mkv) leaves the old subtitle displayed until the next subtitle is displayed.

Hard to say if any of the SSA subtitles were in sync as I don't speak Japanese, but they appeared to be!
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.
(2013-02-23, 00:12)hpbaxxter Wrote: With the "without seek" build, sometimes directly after booting, the first attempt to play a movie fails with black screen, counter at zero. When paused, the time passed is indicated correctly, when playing, 0:00:00 is indicated. A second and further tries always play the video correctly. I have a 256 MB RPi and it's the same with gpu_mem=100 and gpu_mem=128.

Slight advantage, however, for the build "without seek and new scheme buffering" on my part, as it behaves better when stressing the cpu while watching a movie ... which is not really a decisive use case for sure ;-)

Confirm. Without seek build - first play=black screen, second play and next=fine.

New scheme have minimal worse performance that old scheme.



(2013-02-23, 06:42)MilhouseVH Wrote: With all of the SSA test files, disabling subs while subtitles are visible leaves the last subtitle permanently visible. Switching to a different sub track (eg. Russian to English in SSA_15subtitles.mkv) leaves the old subtitle displayed until the next subtitle is displayed.

Did this occur in earlier builds?
I have to admit this is the first time I've ever tested these files. Any subtitled movies I have are usually of the srt variety.
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.
(2013-02-23, 05:19)rbej Wrote: On bulid without new scheme and no seek everything is ok and no audio sync issue??

The build without new scheme and no seek performs better when stressing the cpu while playing a 1080p/dts movie with high bitrates, as it stops the movie for about half a second several times and continues playing after each "buffering" without problems. With new scheme, however, the file continues playing, but without sound, and the sound returns after about five to ten seconds after the demanding task has finished (in sync, though). I prefer the movie stopping for a short time, and continueing with sound. I want to point out that if audio plays, there is never a delay between audio and video, and without a second task like transferring files to the pi, all builds behave quite the same. Maybe someone could check possible differences when streaming files over the network, as I have the files on a hdd directly attached to the pi (ntfs, usb).

I've only observed a delay on subtitles for about one second compared to the same file played with vlc media player. This concerns all three builds and also the official 3.0 RC3 build. Tested it with pgs and vob subtitles on Pulp Fiction mkv remux and with spu subtitles on Die Hard mkv remux.
(2013-02-22, 22:49)rbej Wrote: I get time to compile 3 test build

without seek and big buffer

without seek

without seek and new scheme buffering

All 3 build include https://github.com/xbmc/xbmc/pull/2273 (fix ass subs for GLES)
This is a bit ambiguous. I'm not sure if without applies to just the first term or both. Can you confirm that:
"without seek and big buffer" means the "seek before zero" is absent and and the "big buffer" patch is present
"without seek" means the "seek before zero" is absent.
"without seek and new scheme buffering" means the "seek before zero" is absent and the "buffering" patch is present
You are created 4 patches.

- seek before zero

- new scheme buffering

- big buffer (Check free memory, and if plenty use full size buffers)

- resolution changes

Im created three test builds with different combination your patches.

- without seek patch and big buffer patch. new scheme patch and resolution patch is include.

- only without seek patch. big buffer patch, new scheme patch, resolution patch is include.

- without seek patch and new scheme buffering patch. big buffer patch and resolution patch is include

All my three test builds include to audio hdmi and analogue both patch https://github.com/xbmc/xbmc/pull/2232 and new ass subs patch (https://github.com/xbmc/xbmc/pull/2273)



From the test results I could deduce that "without" applies to both the first and second term. So "without seek and new scheme buffering" is the only build of them which doesn't have the new buffering scheme. I hope that I'm right here.
Edit: Sorry, haven't seen rbej's post early enough!
None of the video add-ons will install? After hitting Install you see downloading 0% and then nothing.

Also happens on OpenELEC 3.0 RC3.
(2013-02-23, 17:09)kraades Wrote: None of the video add-ons will install? After hitting Install you see downloading 0% and then nothing.

Also happens on OpenELEC 3.0 RC3.

It's working for me, tried with MTV.de add-on. So it was either a short server problem, or you have maybe broken something with too high overclocking settings I think.
I had to reinstall but it is working fow me as well now. Thanks for checking.
Rbej Frodo Brench

http://www.mediafire.com/?10456ccz13ard

- OpenElec build r13361
- Xbmc 12.0.2 Frodo (almost 100 new fixes)
- Rpi kernel 3.6.y (16.02.2013)
- Rpi firmware (20.02.2013)
- Pvr Addon (16.02.2013) with PVR TvHeadend 1.6.18 and MythTv 1.6.9 (21.02.2013)
- Xvdr Addon (22.02.2013)
- Gpu memory set to 100mb on default for Rpi 256mb (fix kernal killing Xbmc task on Rpi 256mb board) and Gpu memory set to 256mb on default for Rpi 512mb.

Only in my build:

- add Gui resolution change (taken from XBIAN)

- add new Network Cache.

- add Both HDMI and analog audio output

- remove battery level info from System Information and add info about build version (taken from XBIAN)

- Handle resolution changes during video stream

- NFS auto-update patches for USB/NFS/SMB on Rpi

- fix ass subs for GLES

---------------------------------------------------------------------------------------------------------------------

Please read this:

https://github.com/xbmc/xbmc/pull/1388

No more cachemembuffersize in advenced setting. Please delete it and add this:

<alwaysforcebuffer>false</alwaysforcebuffer>
<freememorycachepercent>5</freememorycachepercent>

1. alwaysforcebuffer: This will force everything ran through dvdplayer to be buffered that would not be normal buffered except Optical Media. This includes SMB, Local Files, OS Network Shares, etc.

2. freememorycachepercent: The amount of free memory to use as buffer size. Please note that of the percentage of free memory used ~75% will be used for forward buffering and ~25% will be used for the back buffer.

Add to advencedsettings <guires>XXXX</guires>

XXXX = GUI resolution. 480p,720p,900p,1080p. <guires>720</guires>, <guires>1080</guires> etc...

Update Instruction:

http://wiki.openelec.tv/index.php?title=...g_OpenELEC

For Rpi 512Mb set gpu_mem=256 and change GUI to 1080p.

For Rpi 256Mb set gpu_mem=100 and change GUI to 900p.

or clean install:

http://wiki.openelec.tv/index.php?title=...spberry_Pi

---------------------------------------------------------------------------------------------------------------------

Before update please remove this lines from config.txt

start_file=start_x.elf
fixup_file=fixup_x.elf

New codes now is included in start.elf and fixup.dat files.


---------------------------------------------------------------------------------------------------------------------

Thanks everything for help with this build



Rbej, the download link provided doesn't work, it says "The owner of this folder has not added any files."
I know. I have little problem with upload. Please of patience Wink



Is done. Please download and test it Smile



  • 1
  • 95
  • 96
  • 97(current)
  • 98
  • 99
  • 174

Logout Mark Read Team Forum Stats Members Help
OpenELEC Testbuilds for RaspberryPi12