[caravela]

as for boot time the system has to load the file to ram hence it might be slower to boot ( depends on the speed of the sd card).
After booting all files are in memory, so requesting a file, for example skins files should be faster.
No this doesn't affect video performance, videos could take less time to start thought ( libraries are in memory now)

Another thing that might improve performance could be mounting /storage/.xmbc/temp as tmpfs filesystem.

[Trixster]

One problem which I've found with r12577 is that if I pause a video the Pi will reboot itself after about 4 mins. This is before the screensaver kicks in. It happens regardless of file type or size and also happens regardless of whether the pi is overclocked or not. CPU usage seems to hover around 85% when a video is paused.

[PobjoySpecial]

...

[pplucky]

are your newer files accessible to the user that xbmc runs as

Yes, I can easily access and play these files if I manually go to the source. What I can't seem to be able to do is to make XBMC add these new files to the library when I request it to search for new content or update the library.

Any ideas?

[Milhouse]

Not everything is loaded into memory, right? The thumbnail cache can grow to several gigabytes, so I take it the media artwork speed is unchanged?

Does the ramdisk allow the Pi to be safely hard shutoff? That would be a benefit when taking power off the TV's USB port.

Its just SYSTEM that is being loaded into RAM - the XBMC Storage area is not being loaded into RAM, so media artwork speed will remain unchanged.

You should never "hard shutoff" the Pi or you will risk trashing the XBMC Storage partition (and if you don't trash it completely, you'll most likely lose the most recent file updates that have yet to be flushed from file buffer memory).

It's actually quite easy to "lose" an update such as a thumbnail that has been recently cached (ie. entry written to the texture db, but the converted image not yet flushed to SD card) if you power cycle the Pi (or it locks up) - when you try to view that same thumbnail after restarting the system, XBMC complains that it can't find the image in the texture cache (and will never find it no matter what you do - it would be nice if XBMC automatically re-cached the image to resolve this cache discrepancy).

If the Storage partition were mounted with the sync option then it might reduce the chance of data loss, though not sure what effect this would have on write performance - if the number of disk writes are low then maybe it's worth a try? Could it be added as an option to cmdline.txt eg. "sync|nosync[defaullt]"? If users are using MySQL then the number of disk writes to SD card will be relatively low (mostly log writes, plugin updates and newly cached images). I'd rather have the safety of sync than run the risk of a crash or reboot losing data that then remains forever "not found".

---

are your newer files accessible to the user that xbmc runs as

Yes, I can easily access and play these files if I manually go to the source. What I can't seem to be able to do is to make XBMC add these new files to the library when I request it to search for new content or update the library.

Any ideas?

Are you adding new content to a directory that is already defined as a media source, or are you adding these files in a new directory? In XBMC 11 I have a situation where I added a top level folder as a video source, and specified it recursively, and scraped it without a problem, but a while later I discovered that any new folders I create within that top level folder are not scraped automatically, I first need to manually specify their content (as Movies etc.). Unless and until I specify their content, these new sub-directories/folders will be ignored whenever I "Update Library" - maybe it's the same for you?

[tuxen]

I've seen this with ordinary scraped files.
Try go to files and choose look for new content on the folder instead of just update library?

Edit: sorry I see you already did that.

[PobjoySpecial]

...

[Milhouse]

How long does it take for the cached images to be written on the SD Card? My immediate response would be that it depends entirely on how much memory is free - Linux will buffer file data as long as possible to improve IO performance. If the system is not running short of memory (such as when running OpenELEC on a 512MB Pi) then the file writes may remain buffered for tens of seconds if not longer.

I've tried remounting /storage with sync (mount -o remount,sync /storage) and haven't noticed any adverse problems (performance related or otherwise).

@sraue: Could you consider adding a cmdline.txt option to mount /storage with the sync option?

---

@sraue: With the latest OpnELEC 3.0 Beta1 (release 2.95.1), the Info button on the remote is not working when browsing in Movies (works fine browsing TV Shows and Music).

I get the following entries in the log when clicking the Info button in Movies:

Code:

22:29:34 T:3043512848   DEBUG: LIRC: Update - NEW at 425229:166 0 KEY_INFO devinput (KEY_INFO)
22:29:34 T:3043512848   DEBUG: OnKey: launch_media_center (c3) pressed, action is Info
22:29:34 T:3043512848   DEBUG: LIRC: Update - NEW at 425625:166 0 KEY_INFO_UP devinput (KEY_INFO_UP)

but no Info panel appears (in fact, nothing appears on screen - the button press is just ignored).

The Info button is also ignored while browsing Videos -> Movies, Videos -> Files -> (select a movie source) and Videos -> Recently added movies. However the Info button works fine in Videos -> Recently added episodes, and all other TV Show related views/sources.

EDIT: I've just added a couple of new movies (via Update Library), and the Info button is working for these - looks like a full media library rescan is in order?

[pplucky]

Are you adding new content to a directory that is already defined as a media source, or are you adding these files in a new directory? In XBMC 11 I have a situation where I added a top level folder as a video source, and specified it recursively, and scraped it without a problem, but a while later I discovered that any new folders I create within that top level folder are not scraped automatically, I first need to manually specify their content (as Movies etc.). Unless and until I specify their content, these new sub-directories/folders will be ignored whenever I "Update Library" - maybe it's the same for you?

I'm really confused about all this, so my next step will be to trash my whole movie db, then rebuild the old files based on existing nfo files. After this, I will try scanning for new content so the new files are added then. I'm betting there's something "special" with my movies db file. Let's see.

[Milhouse]

Just rescanning my media library with OE 3.0 Beta1, and I've had the following messages appear:

Code:

01:49:29 T:2988438624   ERROR: COMXCoreComponent::DecoderEventHandler OMX.broadcom.image_decode - OMX_ErrorStreamCorrupt, Bitstream corrupt
01:49:31 T:2945139808   ERROR: COMXCoreComponent::GetInputBuffer OMX.broadcom.image_decode wait event timeout
01:49:31 T:2945139808 WARNING: JpegIO: Error 28: Unsupported color conversion request

It's no big deal, and it's undoubtedly correct that these messages should be output as its entirely possible that I've got one or two duff images in my media library that the R-Pi can't handle, but is there any way that these ERROR/WARNING messages could also include the name of the image file (jpg/tbn) that is causing the problem so that it can be replaced with a version the Pi is happy to decode?

[Milhouse]

I've now completed a full media library rescan (dropped old MyVideo73 schema and deleted Thumbnails folder and Texture13.db), and when pressing Info while browsing Movies, I get the pop-out Info panel, but its completely blank, so something still isn't right with the Info button for movie content.

Edit: Having just finished scanning in my TV Shows, this now also produces a blank Info panel.

[Ned Scott]

I guess the RAM disk could be used to protect the system for hard shutdowns. You'd always risk losing some data, depending on how often it syncs/writes the ram data back to the SD card. XBMC's DBs would need to be hosted in RAM somehow (symbolic linking?).

It wouldn't be an ideal situation, but I get the impression that most people are doing hard shutdowns anyways, so it might be worth exploring.

[popcornmix]

I only add to the library sparingly (~ once a month) and I don't run any add-ons. I know it's not preferred, but a forced shutoff would make things a lot easier. Is there anything else to worry about?

I guess you could backup the sdcard each time you update the library. Then if something gets corrupt on a hard poweroff you can get back to the old state fairly quickly.
Most of the time you get away with hard powering off, especially if you do it from an idle state (i.e. not scanning database, and when the sdcard activity led has been off for a while).

[Wanderlei]

Have the R-Pi people changed the default memory split if it is not defined by config.txt?

I am sure it was reporting 192mb free on (256mb) board. (When not defined on config.txt)

The config.txt creation has been working for me after updates and it adds my overclocking settings to the end but memory split is commented out. Maybe have this uncommented so everyone is on the same memory split by default.

[Nasp]

The recent version OpenELEC Beta 1, also have the new ram options like the night build 577 ?