Skip to content

changed: upgrade memory based cache to filebased after having been full f #86

Closed
wants to merge 1 commit into from

3 participants

@elupus
Team Kodi member
elupus commented Mar 28, 2011

changed: upgrade memory based cache to filebased after having been full for 2 seconds without anything reading out of it

By starting out with a memory based cache, then replacing that with a file based one on need we avoid the rather large overhead a file based cache introduces. However it can currently not discern the difference between paused playback on a really fast network, and on a slow one. So if you play over http from local network for example and pause playback. The whole file will be downloaded to local disk at maximum network speed.

I'm hesitant to this feature. I suspect it must be possible to turn on and off. On embedded system we may not have diskspace enough to do this. And currently i don't think the file based cache handles the situation of running out of space well at all.

Comments are very welcome to how we should handle a feature like this.

@elupus elupus changed: upgrade memory based cache to filebased after having been fu…
…ll for 2 seconds without anything reading out of it

By starting out with a memory based cache, then replacing that with a file based one on need we avoid the rather large overhead a file based cache introduces. However it can currently not discern the difference between paused playback on a really fast network, and on a slow one. So if you play over http from local network for example and pause playback. The whole file will be downloaded to local disk at maximum network speed.
d633aea
@davilla
davilla commented Mar 30, 2011

Seems to work quite well under OSX. No issues that I can see yet. iOS testing tonight.

@elupus
Team Kodi member
elupus commented Mar 31, 2011

Nice to hear. I've realized a rather major bug with the file based cache thou which must be fixed before this goes in. If the free disk space of the local machine does not support the size of the streamed file, playback will break down.

So two things really needs to be fixed here. One verify available disk space. Define some limit as to how much free space we always must leave. Something like atleast 200 megs (computers do funny things when totally out of disk space).

Fix the SimpleFileCache to wrap around similary to how the new mem buffer does. So it doesn't break down with a limited amount of disk space.

@davilla
davilla commented Apr 2, 2011

what's a good way to trigger this ? iOS is fine but I don't really see the file cache getting created.

@elupus
Team Kodi member
elupus commented Apr 5, 2011

Normally it would just be pause playback on a file larger than 20megs+8video byterate, wait for the file cache to fill larger than 20+8videobyterate. (is visible in the codec info data)

@davilla
davilla commented Apr 5, 2011

humm, can't seem to force it. will beat on it some more.

@ghost
ghost commented Apr 22, 2011

hi elupus, tiben20 has also been experimenting with file caches

(for my benefit, because i made an addon that streams .avi, which was having buffering issues on slower connections)
http://forum.xbmc.org/showthread.php?t=98782 http://trac.xbmc.org/ticket/11416 (download links are in the trac ticket)

i've thought of 2 more things that could trigger it:

A) check whether stream supports skipping, if it doesn't, force file cache.
(prevents a bug on streams that don't support skipping where pausing for too long kills the stream)

B) allow addon coders to set in xbmc.player.play a cache file path (which also forces file cache)
(this lets us provide a cool Stream + Download option in addons) ---- tiben's patch does this

*PS for the streams that don't support skipping, another nice thing might be to support skipping within the already cached video, but refusing to try to skip beyond the cache limit because we know we won't be able to.

i hope my suggestions help!

@elupus
Team Kodi member
elupus commented Apr 23, 2011

the current filecache logic will not guarantee a complete download thou. if a seek request is made (not neccessarily by user, could be done by demuxer) it will just maintain some part of the file. So it would most likely be corrupt if you try to reuse it.

@ghost
ghost commented Apr 23, 2011

ah ok, AFAIK tiben's patch completely switches to use the curl download code used elsewhere in xbmc (like for downloading images) to guarantee a complete download. (if the stream is file cached from the very start, and the stream is not skipped around in)

i'll ask him to post on this discussion so he can coordinate.

apologies if i have hijacked this pull request with scope creep, maybe i should ask tiben to make a new pull request

@tiben20
tiben20 commented Apr 25, 2011

anarchintosh elupus is right about the current seek that will corrupt the download. My test were done with megaupload free account this is why i didn't see it right away.
I'll see if i can make the seek happen on what as already been cached instead of making it on the input stream directly

@tiben20 tiben20 closed this Apr 25, 2011
@tiben20 tiben20 reopened this Apr 25, 2011
@elupus
Team Kodi member
elupus commented Apr 15, 2012

This won't merge anymore and i'm not sure i see much point in it anymore.

@elupus elupus closed this Apr 15, 2012
@ghost
ghost commented Apr 19, 2012

i still see the point in it... pausing something to load (because it is a slow connection) and then finding it has not is very frustrating.

@ryanroth ryanroth referenced this pull request in garbear/xbmc Mar 12, 2013
@garbear garbear Savegames - success b3f95f2
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.