Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Already on GitHub? Sign in to your account

Network Cache Redux #1388

Closed
wants to merge 1 commit into
from

Conversation

Projects
None yet
Contributor

classicspam commented Sep 7, 2012

Based on PR 831

PR 831 Inclusions (credit goes to bobo1on1):

  • Use Free Ram Percentage as Buffer Size
  • Adjust Read Rate Based On Max Bitrate

Enhancements to PR 831:

  • move variables over to advanced settings under section ("alwaysforcebuffer" default false and "freememorycachepercent" default 50% max 80% with hard limit of 1GB and 0 value will force filecache. It also removes "cachemembuffersize" variable as it is no longer needed)
  • "alwaysforcebuffer" variable will cache everything run through dvdplayer (i.e. OS network shares, local media, etc) except Optical Media Drives
  • Memory buffer is straight percentage of free ram (i.e. if 50% free ram is used ~75% of the 50% will be forward looking buffer and ~25% of the 50% will be back buffer)
  • Rate limiting which fixes SMB issues with PR 831 as far as I can tell (no issues with testing for 1+ months on Windows, Linux and ATV2 devices) (1.25 times max bitrate up to 40 MB/s in which case it is throttled to max bitrate)
  • ios and linux fixes

Advanced Settings Notes: This PR adds 2 setting under advanced settings and removes the "cachemembuffersize" setting as it is no longer needed. The added settings are as follows:

  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. The current default is false due to it not really being a help to people who use hardwired connections (as they probably do not need buffering for SMB, 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. The default is 50% which is a good default for memory limted devices such as the atv2. The max is 80 percent and there is a hard limit of 1GB buffer size irregardless of free ram. Setting it to 0 will force filecaching (same as the way cachemembuffersize was used)

how can i try this with windows? i have issues with smb & vpn on a windows client!

@ghost

ghost commented Sep 10, 2012

if you don't know you shouldn't be in here. simple as that.

sorry but i try to get smb working more than 2 weeks and i really want to try it so i can give a feedback. just tell me if its possible please.

Member

arnova commented Sep 11, 2012

Everything is possible but without enough knowledge about both git and compiling/building I'd probably use my time/efforts for other things...

Contributor

mgehre commented Sep 11, 2012

+1 for making sshfs mounts usable

tompen- commented Sep 13, 2012

Should OMXPlayer.cpp also have ReadRate changes?

Contributor

huceke commented Sep 14, 2012

@tompen: yes. i'll add it when it is merged.

tompen- commented Sep 24, 2012

Tested on OMXPlayer with ftp and smb source. I noticed the following:

For Raspberry Pi, freememorycachepercent=50 as the default seems to be too high (especially when cpu is decoding audio). I don´t understand why, but my experience from testing: The more data we have in cache, the more horsepower is needed to play the movie without stuttering. On the Pi, I settled on a few MB cache, freememorycachepercent=5

Slightly offtopic for this PR: When streamed movie have temporary drop in network speed, so that cache is emptied and vq/aq is not entirely full, there is too much cpu cycles spent by the player repeatedly trying to fetch data from an empty cache. The result is too few cpucycles are spent for movie playback and by filecache to fetch new data from network. In this cornercase scenario, regardless of the configured cachesize, the movie stutters. This is not new and it is not caused by this PR. In my personal build I fixed it like this:
http://pastebin.com/FzDKsmfz

Member

bobo1on1 commented Sep 24, 2012

Ouch, why is Sleep(0) used there, using that means you're basically handing off the thread synchronization to the scheduler, which may or may not do a good job.

tompen- commented Sep 25, 2012

Sleep(0) was already there. I increased to Sleep(50) if cache is almost empty.

+50 on this, I'm unable to use xbmc because of the lack of caching for "LAN", since I connect to my sources with VPN + SMB, and the tunnel sometimes drops in speed, the video stops and it says "buffering" for 2 sec, then plays for 10sec then "buffering" again...

Instead of "alwaysforcebuffer" add an option to choose per source to cache or not

@doits doits referenced this pull request Oct 14, 2012

Closed

Networkcache #831

doits commented Oct 18, 2012

what's current status for this? any chance to include this in the next cycle?

Contributor

classicspam commented Oct 20, 2012

@tompen - I am curious for the Pi whether it is the network communications (i.e. the read throughput) or the memory subsystem (i.e. memcopy function in circularcache) causing the stuttering due to high cpu cycles. Since I do not have a Pi to play with, if you could run the following test - revert OMXPlayer to the state without any changes (i.e. static read rate of the avg. bitrate of the movie) to see if the skipping still occurs which should eliminate network throughput being the issue. This is of course assuming that you copied the changes from DVDPlayer to OMXPlayer...

Either way, possibly having a different default for the Pi may be in order if and/or when OMXPlayer changes are made, however only having 5 percent of free ram as the default across the board would probably be useless for any devices like the ATV2 which is memory limited but can handle a 30-40 MB buffer size (i.e. about 50 percent of the usual free ram) and basically any standard linux, windows, etc. boxes that people have that can handle decent sized buffers...

tompen- commented Oct 25, 2012

@classicspam

I have done further testing on Raspberry Pi. Sorry for the long post.
Problem I noticed is caused by disk io reads due to low memory condition for Linux.

As you do not have a Raspberry Pi I write this with lots of details:
I used a rev2 Raspberry Pi board with 256MB memory
(128/128 RAM/GPU memory split)
From Linux point of view we have a total of 128MB RAM.

I compiled latest OpenELEC, commit d5bea25.
This includes xbmc commit c2037d1 (23-Oct-2012).

I added this PR 1388, unchanged.
So for this test, as requested, I did not implement changes to OMXPlayer
(In the test I did a few weeks ago, the changes from this PR was implemented also in OMXPlayer.)

My advancedsettings.xml:
true
50

When playing a 1080p x264 movie, the OSD in xbmc displays 37MB cache is used.
This movie has DTS audio and the cpu downmix audio to stereo output.

Without this PR implemented, I know that I can play this movie flawless with average cpu usage of 75%. (DTS audio decoding is not hardware accelerated, so most of cpu usage is to handle audio).

With the above settings. I get around 0.001 fps. Movie is so slow I can easily see individual frame updates. The more I reduce freememorycachepercent, the better my movie playback works.

iostat reports the boot partition is doing huge amount of reads. cpu resources are wasted in io_wait status. On OpenELEC, the boot-partition is mounted readonly. Located in boot-partition is Linux kernel and the / filesystem as a squashfs. All application binaries are there. I do not have a swapfile.

When movie is playing, Linux have so little free RAM that a simple command such as:
cat /proc/meminfo && iostat
gives error message: "fork: Cannot allocate memory"

Below is my guessing/speculation on the cause:
On the Raspberry pi, with freememorycache=50 XBMC takes too much RAM so Linux does not have enough free RAM to keep enough filesystem cache.

I am guessing this PR does the check for available RAM before playback is started. And on a device with only 128MB memory, the startup of OMXplayer also needs RAM. So the 50% actually consumes more than 50% of available memory because the check of how much free memory we have happens sooner than optimal.

I think, for the PI a different default is needed. freememorycachepercent=50 is unusable.

Maybe this PR need not only to limit cache size to a maximum of 1GB as already done. I am thinking it also need to set a minimum cache size of a couple MB. And, the important point from my test, it needs to make sure we leave alone at least xx MB RAM for the OS.

Perhaps it is better to keep cachemembuffersize setting available. My idea: If cachemembuffersize exist, it override the freememorycachepercent. But if cachememorybuffersize does not exist, the freememorycachepercent should be considered. That gives maximum flexibility for the user.

As mentioned in my previous test, on OpenELEC, with my Raspberry Pi I get the best experience with freememorycachepercent=5. That corresponds to about 5MB cache + the vq/aq cache. With this setting iostat reports that linux is not doing any reads from boot partition during movie playback. I have not figured out exactly when problem starts, but I know the problem starts with big cache. With this setting the movie again play flawless for me.

Another idea I have: The network rate-limit maybe can be disabled if movie need to stop playback and do buffering and also if user have paused the movie. For people with really bad wireless networks and lots of RAM, I guess they will start movie, pause it and wait for 1GB cache to fill before they start watching movie. For them, an unlimited readrate during paused movie would be really good.

As a final note: I think this PR is for sure a big step in the right direction and should be added to xbmc. It would be very good for people that are streaming movies on wireless networks.

@JohnHoek JohnHoek referenced this pull request in xbianonpi/xbian Nov 16, 2012

Closed

Enable netwerk caching redux #1388 on XBian #81

anybody still working on this? This network cache patch is a good addition to xbmc, especially for not so good bandwich on wireless networks.

Contributor

classicspam commented Nov 18, 2012

I am waiting for a Rasberry PI to come in (back-order) to test regarding issues that @tompen was describing to see if I can adjust the code (i.e perhaps a 25 or 50 MB memory reservation before the percentage of free ram is used, or to use cachemembuffersize as a static override, etc). Anyways this PR will not be included in main until at least after Frodo goes live as there is a feature freeze...

@ghost

ghost commented Nov 20, 2012

I'm going to try to compile XBMC (for XBian) with this pr.

@ghost

ghost commented Nov 20, 2012

@classicspam It would be nice if you posted a sample advancedsettings.xml to make that part 100% clear.

@ghost

ghost commented Nov 22, 2012

Getting compilation errors with this pr applied

make[1]: *** No rule to make target `DVDInputStreamFile.o', needed by `DVDInputStreams.a'.  Stop.
make: *** [xbmc/cores/dvdplayer/DVDInputStreams/DVDInputStreams.a] Error 2

doits commented Nov 24, 2012

compiles fine for me at 914e708

edit, for reference, I use this patch: link to patch

@jabbera jabbera referenced this pull request in OpenELEC/OpenELEC.tv Dec 3, 2012

Closed

Enable network caching, add xbmc PR #2607 #1536

@classicspam Why not add an option to choose per source (ie when you add/edit a source) to cache or not, instead of alwaysforcebuffer?

Also, any news about this?

rbej commented Feb 13, 2013

Working perfect on Rpi. alwaysforcebuffer=true and freememorycachepercent=5

Koenkk commented Feb 14, 2013

I doubt if this patch has any use for the raspberry pi as it's using omxplayer and dvdplayer is being patched here..

Member

popcornmix commented Feb 14, 2013

@Koenkk
This applies fine for Pi. We use all the files changed here.

pivin commented Mar 1, 2013

Been testing with my friend over Wan for 1 month, with OpenVPN and SMB. Very impressive it works great!!

I noticed that it dosent work with ".iso" files. Is there a workaround for enabling cache on ".iso" files?
I'm using the Branch_SMBUseBufferFinalFrodo and compiled it on Febuary 27.

@classicspam classicspam PR 831 Inclusions (credit goes to bobo1on1):
- Use Free Ram Percentage as Buffer Size
- Adjust Read Rate Based On Max Bitrate

Enhancements to PR 831:

- move variables over to advanced settings under <network> section ("alwaysforcebuffer" default false and "freememorycachepercent" default 50% max 80% with hard limit of 1GB and 0 value will force filecache. It also removes "cachemembuffersize" variable as it is no longer needed)

- "alwaysforcebuffer" variable will cache everything run through dvdplayer (i.e. OS network shares, local media, etc) except Optical Media Drives

- Memory buffer is straight percentage of free ram (i.e. if 50% free ram is used ~75% of the 50% will be forward looking buffer and ~25% of the 50% will be back buffer)

- Rate limiting which fixes SMB issues with PR 831 as far as I can tell (1.25 times max bitrate up to 40 MB/s in which case it is throttled to max bitrate)

- ios and linux fixes

Advanced Settings Notes: This PR adds 2 setting under advanced settings and removes the "cachemembuffersize" setting as it is no longer needed. The added settings are as follows:

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.  The current default is false due to it not really being a help to people who use hardwired connections (as they probably do not need buffering for SMB, 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.  The default is 50% which is a good default for memory limted devices such as the atv2.  The max is 80 percent and there is a hard limit of 1GB buffer size irregardless of free ram.  Setting it to 0 will force filecaching (same as the way cachemembuffersize was used)

Merged again
36a8e36

Koenkk commented Mar 11, 2013

Not working anymore because 2 methods are removed (GetVideoBitrate() and GetAudioBitrate()). This was done in the following comit: 87047e9#xbmc/cores/dvdplayer/DVDPlayer.h

Hope you can fix this classicspam as I want to recompile my OpenElec with this patch. I have 4gb ram sitting idle while playing and would like to use it - plus it would be really nice to get my x16 fast forward a bit smoother.

slakbmc commented Apr 10, 2013

Hi classicspam! I need this in Frodo quite desperately. It would be really great if you cound fix it. Many thanks!

edit:\ Actually, if the missing "GetXBitrate()" methods is the problem, why not just change it to "m_dvdPlayerVideo.GetVideoBitrate()" as it's used in DVDPlayer.cpp now in line 3815? Would that work? I only have rudimental knowledge of programming but it seams reasonable to me.

mtisza commented Apr 11, 2013

I have a fix for the compilation issues around the API change. Short of creating a new pull request, I'm not sure how to request this PR be updated with the fix. So the link to my fork/branch with the fix is mtisza/xbmc@1f7ef33 If I should create a new pull request, please let me know.

Also I'm unsure is the devs want me to use the GetVideoStreamInfo/GetAudioStreamInfo API instead of calls to m_dvdPlayerAudio.GetAudioBitrate(), which is how I chose to do it. If you want me to change it just ask. I'm not even remotely familiar with the vast code of xbmc, so I took the easy way out for now.

I'm dying to see this PR in master, since I've had very good performance with it on my RPIs.

slakbmc commented Apr 12, 2013

You can also just compile the latest stable from xbmc.org/download with the original PR by classicspam. That's how I did it successfully. Works very well!

Contributor

NedScott commented Apr 12, 2013

@mtisza At this point it might be best to make a new PR.

Also, I suggest we make a thread on the forums for keeping track of those of you who have been testing this, to get some nice feedback collected in one place. Every time we comment on here it sends e-mails out to just about all of XBMC's devs and more, so using the forum and leaving a link on the PR would be good for the devs' sanity :) (and their e-mail boxes).

Looking forward to hopefully getting this in soon!

mtisza commented Apr 12, 2013

I've created a new pull request #2607 with the updates, and rebased with upstream/master.

Owner

MartijnKaijser commented Aug 18, 2013

See #3104

@guydev guydev pushed a commit to guydev/guydev_plex-home-theatre_enhancements that referenced this pull request Jun 21, 2014

@tru tru Improve caching
We had a very restrictive cache size and the readrate was pretty
limited. This improves on that, parts of this is borrowed from Pull
Request 1388 on XBMC. xbmc/xbmc#1388
bf9055a

@LongChair LongChair added a commit to plexinc/plex-home-theater-public that referenced this pull request Nov 21, 2014

@LongChair LongChair Dont check leafcoung on stection items, fixes #1388 5dcd1c8
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment