Login at Kodi Home

tuxen · 2012-12-06, 18:09

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

**popcornmix** · 2012-12-06, 18:30

(2012-12-06, 17:46)rbej Wrote: Try r12664

Do you think 12664 fixes the problem by adding swap, or fixing the memory leak?

tuxen · (This post was last modified: 2012-12-06, 19:37 by tuxen.)

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.

tuxen · (This post was last modified: 2012-12-07, 01:52 by tuxen.)

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

tuxen · (This post was last modified: 2012-12-07, 01:53 by tuxen.)

Ups! Double

lowridin_guy · (This post was last modified: 2012-12-07, 03:47 by lowridin_guy.)

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

rbej · (This post was last modified: 2012-12-07, 10:16 by rbej.)

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

lowridin_guy · 2012-12-07, 15:56

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

rbej · (This post was last modified: 2012-12-07, 18:02 by rbej.)

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.

LehighBri · 2012-12-07, 17:56

(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?

**popcornmix** · 2012-12-07, 18:21

(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.

lowridin_guy · 2012-12-07, 18:52

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

rbej · (This post was last modified: 2012-12-07, 19:12 by rbej.)

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.

Wanderlei · 2012-12-07, 19:08

(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.

evanspae · 2012-12-07, 19:09

(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 ...