Kodi Community Forum
OpenELEC Testbuilds for RaspberryPi - Printable Version

Kodi Community Forum (https://forum.kodi.tv)
+-- Forum: Support (https://forum.kodi.tv/forumdisplay.php?fid=33)
+--- Forum: General Support (https://forum.kodi.tv/forumdisplay.php?fid=111)
+---- Forum: Raspberry Pi (https://forum.kodi.tv/forumdisplay.php?fid=166)
---- Thread: OpenELEC Testbuilds for RaspberryPi (/showthread.php?tid=140518)



RE: OpenELEC Testbuilds for RaspberryPi - tuxen - 2012-12-06

Ok I tryid r12662 earlier though with same result. I will try r12664 was something committed in relation to memory?


RE: OpenELEC Testbuilds for RaspberryPi - popcornmix - 2012-12-06

(2012-12-06, 17:46)rbej Wrote: Try r12664
Do you think 12664 fixes the problem by adding swap, or fixing the memory leak?


RE: OpenELEC Testbuilds for RaspberryPi - tuxen - 2012-12-06

Heh.. I can add that it is consistent in openelec and raspbmc so it seems to point at XBMC? Just for info.

Edit: And It was/is present before r12500.


RE: OpenELEC Testbuilds for RaspberryPi - tuxen - 2012-12-07

By reading around it seems swap is not supported? ie no openelec workaround for now.. It's odd that none of this happen on 512MB they run for days. But on 256MB boards the problem is so consistent that you can predict it to a certain point in the movie.

Hope you guys find what's leaking all that memory on 256MB boards.

Best rgds tuxen


RE: OpenELEC Testbuilds for RaspberryPi - tuxen - 2012-12-07

Ups! Double




RE: OpenELEC Testbuilds for RaspberryPi - lowridin_guy - 2012-12-07

Not sure what happened to my post I made but I am also getting crashing within various plug-ins...Please see my log below.
I am running OE and I think it's also due to a memory leak of some sort.

http://pastebin.com/cPB0QwRE




RE: OpenELEC Testbuilds for RaspberryPi - rbej - 2012-12-07

Xbmc Frodo beta 3 and OpenElec 3.0 beta 4 is coming very soon.

Very important changes on RPI

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


RE: OpenELEC Testbuilds for RaspberryPi - lowridin_guy - 2012-12-07

Great news!! Will be waiting patiently for the release...


RE: OpenELEC Testbuilds for RaspberryPi - rbej - 2012-12-07

Look for my signature Wink

PS. Only my bulid r12669 include Xbmc Frodo Beta 3 revision ae60d24. Official r12669 include revision e979ca9 and no have 14 fixes for Rpi.


RE: OpenELEC Testbuilds for RaspberryPi - LehighBri - 2012-12-07

(2012-12-07, 10:07)rbej Wrote: Xbmc Frodo beta 3 and OpenElec 3.0 beta 4 is coming very soon.

Very important changes on RPI

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

I see the laundry list of changes in that pull request, but what does that actually mean from an end user experience? What improvements should we expect?


RE: OpenELEC Testbuilds for RaspberryPi - popcornmix - 2012-12-07

(2012-12-07, 17:56)LehighBri Wrote: I see the laundry list of changes in that pull request, but what does that actually mean from an end user experience? What improvements should we expect?

Mostly making sure OpenMAX components are freed when there is an error (e.g. out of memory, or errors in file) partway though starting up the playback.
Previously the components that had been created successfully were never destroyed, meaning xbmc had to be restarted to recover the memory.

There is also an improvement for when the audio stream changes within a stream. This can happen with live TV where the stream switches from stereo to 5.1 at an advert break, and it used to stall.

gimli spent a long time working on these and so rewrote a lot of the omxplayer code trying to get things working. There are a number of minor cleanups and bug fixes as a result. You may or may not see chages in behaviour because of these.

There is one other change, where the amount of audio and video data buffered in memory is increased. I'm not sure about this change.
I think it could improve performance (i.e. amount of buffering that occurs) for some streams. I believe it makes streams slower to start (as more buffer to fill).
I also think it won't help when there is no passthrough (when I looked into it, it was a different buffer of decoded audio that was the limiting factor).
There is a possibilty that 256M boards will have more out of memory issues.

Please test it and report back which streams are better and which are worse.


RE: OpenELEC Testbuilds for RaspberryPi - lowridin_guy - 2012-12-07

Any idea when this might be released or can we now go ahead and get the most recent nightly. Are these changes inlcuded in the recent nightly build of XBMC? Sorry for my noob ?'s


RE: OpenELEC Testbuilds for RaspberryPi - rbej - 2012-12-07

This fixes working perfect. No more leak memory and crashes when watching online movies. Smearing color is almost fixed. Very quick response after forward and rewind movie.


RE: OpenELEC Testbuilds for RaspberryPi - Wanderlei - 2012-12-07

(2012-12-07, 18:21)popcornmix Wrote: There is one other change, where the amount of audio and video data buffered in memory is increased. I'm not sure about this change.
I think it could improve performance (i.e. amount of buffering that occurs) for some streams. I believe it makes streams slower to start (as more buffer to fill).

I am very happy buffer is increased. I rather trade off slower start than get hit with buffering at random points in a movie.

Is it the system or gpu that runs out of memory? The memory allocation is very granular now, maybe slight tweaks from the standard 128/128 splits could help there.




RE: OpenELEC Testbuilds for RaspberryPi - evanspae - 2012-12-07

(2012-12-07, 18:21)popcornmix Wrote:
(2012-12-07, 17:56)LehighBri Wrote: I see the laundry list of changes in that pull request, but what does that actually mean from an end user experience? What improvements should we expect?

Mostly making sure OpenMAX components are freed when there is an error (e.g. out of memory, or errors in file) partway though starting up the playback.
Previously the components that had been created successfully were never destroyed, meaning xbmc had to be restarted to recover the memory.

There is also an improvement for when the audio stream changes within a stream. This can happen with live TV where the stream switches from stereo to 5.1 at an advert break, and it used to stall.

gimli spent a long time working on these and so rewrote a lot of the omxplayer code trying to get things working. There are a number of minor cleanups and bug fixes as a result. You may or may not see chages in behaviour because of these.

There is one other change, where the amount of audio and video data buffered in memory is increased. I'm not sure about this change.
I think it could improve performance (i.e. amount of buffering that occurs) for some streams. I believe it makes streams slower to start (as more buffer to fill).
I also think it won't help when there is no passthrough (when I looked into it, it was a different buffer of decoded audio that was the limiting factor).
There is a possibilty that 256M boards will have more out of memory issues.

Please test it and report back which streams are better and which are worse.

For me fixing and handling broadcast continuity changes (i.e audio going from 5.1 to 2.0 and back during a commercial break) will be a major breakthrough for the RPI! I desperately want to get rid of my windows media pc and this inability to handle these audio changes is the last remaining obstacle.............. but I have 256M board...with r12669 The WAF factor is very low because of the constant freezes at 5.1/2.0 audio junctions is so repeatable.

Thanks to all for their fantastic efforts ...




This forum uses Lukasz Tkacz MyBB addons.