Cache testing
#16
I don't think these three settings will help your situation, and I don't know of any other cache settings in XBMC.
Reply
#17
Just to say this new caching scheme is working so much better thanks to popcornmix and a fix to omxplayer so my post #2 is now completely null and void. So far so very good - it's certainly an improvement on prior caching/buffering implementations.
Texture Cache Maintenance Utility: Preload your texture cache for optimal UI performance. Remotely manage media libraries. Purge unused artwork to free up space. Find missing media. Configurable QA check to highlight metadata issues. Aid in diagnosis of library and cache related problems.
Reply
#18
My own testing, iPad 4, Aug 22nd nightly. Wifi was intermittent and kept buffering while I was watching Star Trek in the bathroom (muhhahaha, too much information). I had actually not tried these settings on the ipad yet. Used all three settings, forced buffer, save cache to disk, and read rate x10 (arbitrary number to max it out). No buffering, no issues. I love it when a plan comes together :D
Reply
#19
Is anyone else having trouble with movies stopping after a little over an hour?

XBMCbuntu with latest from xbmc-xvba-testing, connecting wireless.

Media is stored on an UnRaid server, using NFS.

advancedsettings.xml contains :

<alwaysforcebuffer>1</alwaysforcebuffer>
<cachemembuffersize>0</cachemembuffersize>
<readbufferfactor>4.0</readbufferfactor>

Iron Man MediaInfo : http://pastebin.com/4spH5AqR
LOTR - Fellowship MediaInfo : http://pastebin.com/K0wsX3hd

I do not have debug log, as I did not have debugging turned on... I am re-playing LOTR to reproduce issue and get Debug Log.

Iron man ran for about 1hr 19 minutes.
LOTR ran for 1hr 17 minutes.

While each was playing, displaying the video information (pressing 'o') showed that in the first 45 minutes of playing the video, it had at least 4Gb in the cache... and still building. I walked away for a while and when I returned XBMC was back at the 'Movies' menu. XBMC did add a 'bookmark' in the library, so I could restart from the point it dropped. (That's how I know how long video played for)

Here is the normal (debugging off) log file : http://pastebin.com/9yts0Dmx

The 'Iron Man' playback begins at 14:45, with the LOTR following that.

I do have to say... when it is playing back, it is flawless.... makes wireless a real possibility when setting up an HTPC!

Edit: Debug Log - http://pastebin.com/shVjK0qD

LOTR only played for 45 minutes this time.

Please, if this is unrelated to the caching let me know... and I will bark up the correct tree. Thanks.
Reply
#20
(2013-08-26, 01:41)sdsnyr94 Wrote: Is anyone else having trouble with movies stopping after a little over an hour?

Looks like an unstable or flaky network/NFS connection.

MOD edit: removed log spam
Texture Cache Maintenance Utility: Preload your texture cache for optimal UI performance. Remotely manage media libraries. Purge unused artwork to free up space. Find missing media. Configurable QA check to highlight metadata issues. Aid in diagnosis of library and cache related problems.
Reply
#21
never post log snippets on the forum. it creates a mess
Read/follow the forum rules.
For troubleshooting and bug reporting, read this first
Interested in seeing some YouTube videos about Kodi? Go here and subscribe
Reply
#22
Sorry, just thought it easier to point out the sections of interest and it was only a few lines rather than an entire log. But fair enough.
Texture Cache Maintenance Utility: Preload your texture cache for optimal UI performance. Remotely manage media libraries. Purge unused artwork to free up space. Find missing media. Configurable QA check to highlight metadata issues. Aid in diagnosis of library and cache related problems.
Reply
#23
you can pastebin that specific part Smile
problem is all that text makes the forum database huge and is also indexed for searching.
also browsing makes it very awkward
Read/follow the forum rules.
For troubleshooting and bug reporting, read this first
Interested in seeing some YouTube videos about Kodi? Go here and subscribe
Reply
#24
True, but can't be arsed to do it again. Smile
Texture Cache Maintenance Utility: Preload your texture cache for optimal UI performance. Remotely manage media libraries. Purge unused artwork to free up space. Find missing media. Configurable QA check to highlight metadata issues. Aid in diagnosis of library and cache related problems.
Reply
#25
(2013-08-26, 08:30)MilhouseVH Wrote:
(2013-08-26, 01:41)sdsnyr94 Wrote: Is anyone else having trouble with movies stopping after a little over an hour?

Looks like an unstable or flaky network/NFS connection.

MOD edit: removed log spam

I would agree if I did not see such a large cache built up.. wouldn't that be the point behind caching? To handle a network that may get flaky?

To further test, I started playing 'The Dark Knight Rises' last night, and it dropped out after about 25 minutes. I then changed 'cachemembuffersize' from 0 to 5242880, and the movie played to completion.

I will try some more this evening, but is it possible that the large cache file being stored on the local HDD (by setting cachemembuffersize to 0) is getting corrupted somewhere? Is there anywhere in the debug log that states how large the cache buffer is, especially at the point where playback fails?
Reply
#26
(2013-08-26, 15:16)sdsnyr94 Wrote: To further test, I started playing 'The Dark Knight Rises' last night, and it dropped out after about 25 minutes. I then changed 'cachemembuffersize' from 0 to 5242880, and the movie played to completion.

My Pi crashes intermittently on internet streaming unless I set cachemembuffersize to 5242880 (am on OpenElec). Was worse setting it to 0... (don't think it's a good idea having the cache on a cheap class 4 SD cardSmile ) I tried removing it from advancedsettings.xml when I updated to latest stock build last month, but problem returned, so put it back in. I have a somewhat iffy internet connection so am pretty sure the problem is related to either stream dropout or corrupted packets (seems to be more likely to happen when I see more CRC errors & lower SNR margin on my ADSL modem).

On the subject of pasting logfile snippets, I appreciate the clutter & database busting effects of large dumps, but as a relatively novice user, a 2 line log snippet is often much more informative than a pastebin reference to the full log plus a response suggesting the likely problem. People are also less likely to specifically point to the relevant section of the logfile if they have to go through the added step of uploading to pastebin. And finally, its helpful to have RELEVANT log lines in the thread itself if you are searching on the forum for issues that create the same error in your logfile. Maybe an informal protocol of something 4 lines max?
Just my 2c on the matterBig Grin
Reply
#27
(2013-08-26, 19:12)mayoman Wrote: On the subject of pasting logfile snippets, I appreciate the clutter & database busting effects of large dumps, but as a relatively novice user, a 2 line log snippet is often much more informative than a pastebin reference to the full log plus a response suggesting the likely problem. People are also less likely to specifically point to the relevant section of the logfile if they have to go through the added step of uploading to pastebin. And finally, its helpful to have RELEVANT log lines in the thread itself if you are searching on the forum for issues that create the same error in your logfile. Maybe an informal protocol of something 4 lines max?
Just my 2c on the matterBig Grin

In fairness it was closer to 20 or so lines, I had intended to chop out a chunk of lines in the middle but didn't in the end as I was undecided if they were relevant. If it had been less than half a dozen lines I would have argued it was a disproportionate response to cull the extract entirely. I too think there should be room for manoeuvre on log posting, a few lines is OK, just be reasonable and don't post too much at which point flip it over to pastebin. And always use code blocks... Smile
Texture Cache Maintenance Utility: Preload your texture cache for optimal UI performance. Remotely manage media libraries. Purge unused artwork to free up space. Find missing media. Configurable QA check to highlight metadata issues. Aid in diagnosis of library and cache related problems.
Reply
#28
OK, so since I changed cachemembuffersize from '0', I have not had a single issue.... so I think that should rule out a network issue.

Is it possible that the file that was created on my local drive became corrupt while the cache was building? Is there any way for me to test that theory? Can anyone else reproduce the issue?

It is of course possible it may be a hiccup with the xbmc-xvba-testing build I used... I will also test from a Windows 7 PC with the latest nightly to see if I get the same results.
Reply
#29
(2013-08-26, 19:12)mayoman Wrote: On the subject of pasting logfile snippets, I appreciate the clutter & database busting effects of large dumps, but as a relatively novice user, a 2 line log snippet is often much more informative than a pastebin reference to the full log plus a response suggesting the likely problem. People are also less likely to specifically point to the relevant section of the logfile if they have to go through the added step of uploading to pastebin. And finally, its helpful to have RELEVANT log lines in the thread itself if you are searching on the forum for issues that create the same error in your logfile. Maybe an informal protocol of something 4 lines max?
Just my 2c on the matterBig Grin

its not all about database clutter, it also has to do with the information contained on the top of the log, which version it is, platform... etc

when you just snip 2 lines that show the error, a lot of the times the reason why error happened in a first place is just above, type of stream or local file, network protocol and other very useful info
Reply
#30
(2013-08-27, 15:38)amet Wrote: its not all about database clutter, it also has to do with the information contained on the top of the log, which version it is, platform... etc

when you just snip 2 lines that show the error, a lot of the times the reason why error happened in a first place is just above, type of stream or local file, network protocol and other very useful info

To clarify - I was not suggesting that log snippets be posted instead instead of uploading full logs to pastebin! I was just trying to encourage some feedback on their use in threads and, in particular, any formal or informal restriction on how long they should be.
(sorry about the thread hijackSmile)
Reply

Logout Mark Read Team Forum Stats Members Help
Cache testing0