Does XBMC have some settings related to network buffering? I was looking over internet and found only
Code:
<cachemembuffersize>5242880</cachemembuffersize> <!-- number of bytes used for buffering streams ahead in memory
XBMC will not buffer ahead more than this. WARNING: for the bytes set here, XBMC will consume 3x the amount of RAM
When set to 0 the cache will be written to disk instead of RAM -->
But it seems to me that it's not it.
I use Amazon plugin to stream movies through a vpn connection. It sometimes stops for a moment and I the buffer runs out.
Would this help, it's from IGOR blog:
A successor to compcache, zram, has been already integrated in the Linux kernel for a while now. This means that no additional compilation nor tweaking is required to benefit from compressing memory on the fly and massively reduced swapping.
As with compache, I wanted to nicely integrate the solution into the Ubuntu Upstart deamon – hence this short article. After a couple of minutes of playing the configuration was ready.
Create file zramswap.conf in /etc/init and put the following content in it.
01 description "Initializes zram swaping"
02
03 start on runlevel [2345]
04 stop on runlevel [!2345]
05
06 pre-start script
07
08 # load dependency modules
09 modprobe zram num_devices=2
10
11# initialize the devices
12 echo 1073741824 > /sys/block/zram0/disksize
13 echo 1073741824 > /sys/block/zram1/disksize
14
15 # Creating swap filesystems
16 mkswap /dev/zram0
17 mkswap /dev/zram1
18
19 # Switch the swaps on
20 swapon -p 5 /dev/zram0
21 swapon -p 5 /dev/zram1
22 end script
23
24 post-stop script
25
26 # Switching off swap
27 swapoff /dev/zram0
28 swapoff /dev/zram1
29
30 rmmod zram
31 end script
Now you can start the service with sudo start zramswap (it will be automatically started on after the reboot as well).
You will benefit from 2x1GB swap files, which will be compressed and stored in the RAM. Tested on Ubuntu 11.04.
PLEASE remember Im not the smartest guy in the room, so wait till someone else confirms this before trying at your own risk.
Compressing RAM would make sense, if we needed it! At this stage, I am getting an instinctive impression that it is almost impossible to get the Raspi to use more than 100 MB of RAM!
Even on the so-called 512MB Raspies (which only show 401 MB available), I've not yet seen more than 100 MB used, no matter how complex the video is (that said, I've not played raw BD iso files).
OK. Changed the cache to 0 and it seems to help. But I have to try more. Maybe I the network is just faster today.
But I don't know if this setting even work. The ram usage is the same around 77/148 MB whatever I put in those settings.
I watch a stream at 1.3 Mbit/s and the download speed when I watch it on my router is around this.
I wonder which part of software is responsible for this (XBMC or Amazon plugin). My Kindle Fire seems to download the movie at maximum speed (~3-4 mbits/s) so there is no hiccup.
I also found a thread about caching
http://forum.xbmc.org/showthread.php?tid=130938&pid=1097364#pid1097364
Setting cache to zero supposedly changes the cache to disk only but reading further posts put this to doubt. Generally I see that there is a very unfriendly attitude so I don't expect any progress soon.
It's sad the attitude to this is bad. In my case it significantly increased the playback performance.
Can you provide us with a sample file...
Do you have Avatar 1080p? Note: streaming from samba over wlan (edimax ew-7811un)
Does the downloading of the stream should stop after pausing? In my case it does. I'm using rtmp/rtsp stream
I checked the behavior with Youtube plugin this one I think don't use any DRM streams. XBMC downloads about 33 Mbytes of buffer. When I bring up stream info with o key it says cache:33 MB.
When DRM flash content is involved maybe rtmpdump is handling the stream and the caching is handled by some other lib?
I've played with this value and noticed no difference for me, from 0 to 100MB. I think it's only useful if you're streaming over the network where as I'm via USB.
Has anybody played with the cache settings in guisettings.xml?
Code:
<cache>
<harddisk>256</harddisk>
</cache>
<cacheaudio>
<dvdrom>256</dvdrom>
<internet>256</internet>
<lan>256</lan>
</cacheaudio>
<cachedvd>
<dvdrom>2048</dvdrom>
<lan>2048</lan>
</cachedvd>
<cacheunknown>
<internet>4096</internet>
</cacheunknown>
<cachevideo>
<dvdrom>2048</dvdrom>
<internet>4096</internet>
<lan>2048</lan>
</cachevideo>
(2nd Jan, 2013 03:46 PM)Koenkk Wrote: [ -> ]It's sad the attitude to this is bad. In my case it significantly increased the playback performance.
I don't think we have a bad attitude to your suggestion Koennk, just a skeptical attitude. I tried changing this setting and it made no difference to me. The reality is that the XBMC doco says this:
Quote:XBMC will not buffer ahead more than this
I would be very happy to have the majority of the Pi's 512MB of memory used to aid smooth video playback if that were in fact possible. I see very little reason to keep a significant amount of memory free 'just in case' when using a program like XBMC which has such a relatively singular focus - video playback - compared to a desktop operating system, for example.
For me it's more a matter of not refusing to take you suggestion seriously, or being insufficiently worried about memory usage. It's more a case of not being sure this will make any difference.
@rasperry_pd do you stream over wifi?
(6th Jan, 2013 05:33 PM)Koenkk Wrote: [ -> ]@rasperry_pd do you stream over wifi?
No I do not Koennk
I was going to suggest this in IRC as a substantial difference between us. It would be interesting to see if WiFi vs wired was treated any differently.
To be honest I do not trust the Raspi when it come to USB. Too many power issues ,and so on, to worry about. I have a my Raspi connected via a 30 CM cable ATM, it's that close to the router
I understand not everyone has this luxury.
I did notice that you had the happy success of 1080p over wifi with the latest firmware now though, so maybe it wasn't about this setting after all?
I like the option of upping the debug level to 3 that someone suggested elsewhere. That enables SMB debug logging. I would like to try it myself but will see how time permits. Maybe that will give us some good data?