(2013-12-26, 20:24)xbs08 Wrote: [ -> ]Could the mce be sending input signals much to fast for the rpi to keep along?
Not really. The architecture of the xbmc gui means that the scrolling speed is fixed (although influenced by the remote), and cover art is decoded asynchronously and displayed if ready in time.
It depends on the library display mode you are using whether the jpegs will show when scrolling fast.
I find I can scroll at full speed in fanart view, and every cover is visible (but not the larger fanart backgrounds).
The "wall" views tend to show some covers.
Some of the views with lots of text (e.g. low-list I think), I see no covers.
If you reduce the resolution of the cached artwork, you'll have a better chance of seeing more.
The artwork should appear soon after stopping, or when scrolling slowly.
This is all normal and occurs on all xbmc platforms. A really fast PC with fast disk may be able to show every cover and fanart, but if it doesn't keep up then that's not a problem.
Yes, using fanart view, artwork appears as soon as scroll stops and fanart loads instantly also after that.
This is not really a problem it's just that I find it a "bit odd" that the artwork doesn't "act" the same depending on the remote used.
No biggie
thanks for your time and explanations.
(2013-12-26, 14:45)popcornmix Wrote: [ -> ] (2013-12-26, 11:34)ntadej Wrote: [ -> ]My 1080i channels via tvheadend are still detected as 4K and not playable every time. I can provide a sample recording of one of those channel if it helps. (Not sure if it is related to Raspberry Pi or general XBMC.)
See:
https://github.com/xbmc/xbmc/pull/3680
I believe there has been a tvheadend fix, but that may not have made it into latest builds. There is also an xbmc fix which isn't accepted yet.
However I think this issue only related to the reported size and doesn't affect playback.
If you have a recording that fails to play, then providing a sample may help.
I've updated tvheadend to latest version and there are no improvements, just size seems to be detected correctly.
I have a sample recording for 1080i channel that fails (fails playing live or recording).
http://tano.si/tmp/xbmc/hdsample.mkv
(2013-12-23, 17:38)TBCdevil Wrote: [ -> ]@tuxen very good info. Looks like local USB drives are best avoided for proper use.
Sorry I think you missed the point. Which is Database writes or random small writes.
I'd sacrifice 25 Mhz over the added database write speed in a heartbeat. And I had to clock down no matter if I used a 1.8" hdd as now or a USB 3 stick, USB 2 was slow at database writes, 3 faster, but the 1.8 hdd the fastest so I choose that.
Its over 100 percent extra performance when measuring db operations, the 25Mhz you will never notice.
Samba from a PC to RPi is also extremely fast 7-8 MB/sec when mounted as a windows drive. All my movies are on the drive so 2watt and a self powering down hdd is surely better than sharing from a noisy power hungry PC? Uses less power than a NAS even.
But thanks
(2013-12-23, 19:48)allan87 Wrote: [ -> ] (2013-12-23, 10:54)tuxen Wrote: [ -> ]but it says a lot about where the bottleneck lies; the sdcard memory technology so anything that can speed this up without breaking any stability is more than welcome IMHO
My own experience with a class 10 card v. USB was different. I could not discern any difference in the speed of the interface between the two (navigating was very acceptable in both).
In terms of performance, I suspect that the issue pertains more to differences from one SD card to another rather than generic differences between SD cards and USB sticks:
- there is a well known issue of Raspberry Pi being fussy about which SD card one uses, regardless of class or size;
- many people have reported significant performance improvements when moving to USB;
- others have not seen performance improvements. I recall seeing benchmarks posted elsewhere with a particular SD card and USB drive having virtually identical read and write times.
What this suggests is that you have to be a bit lucky with your SD card, whereas most USB sticks are OK. Personally, I use an old, slow 128 MB SD card for 'flash' and a USB stick for 'storage'. My reason was to avoid corruption of the storage volume (particularly while using alpha builds). Two good reasons to use USB, I think.
If you read my post you will see that on 512MB boards and gpusplit of max 132MB the operating system plus openELEC is running completely from ram so GUI performance and likes are the same. Furthermore if you have a bigger gpusplit and its loaded from the sdcard you still won't see much difference because the SYSTEM is read only again no write operations can take place in system. But I'm not talking about sequential read speed here, its pretty equal. I'm not talking about overclocking either.
I know i mixed it a bit together but I'm talking about write operations exactly as documented here with fs2fs. I'm saying in my experience a modern USB 3 stick or harddrive will give you the same or higher small READ/WRITES to the database(s) a tremendous boost in write rates than ext4 on any sdcard STORAGE partition. The storage PARTION is write able and holds your databases, again I'm not saying the GUI will fly but depending on what addons you use and you library operations in most cases the system overall will seem faster.
If just using a simple addons without metadata such as xml lists or naviups, or another simple listings addon with no metadata or fill your library with a new tv-shows I agree not much speed can be gained switching to a faster storage media. Apart from the overclock trick some use because they have corruption with their sdcard at to high speeds.
And I totally agree with you on the sdcard's plus specific pi can lead to corruption. I'm highly aware of the experiences some have. Believe me I fiddled around with this issue ALOT I think I tested 50+ sdcard's and 50 USB sticks. Ofcause there where bad apples (needed squeezing or adjustment) and one even seemed to burn out, but the majority had no corruption errors at all so ofcause I chose a few of them (only around 7 where dodgy and some same as fully working ones). I would choose another path though if I had the problem and clock down until the sdcard was stable to.
But overclocking away, speed won't matter much if you use USB 2 memory sticks no, because the rely on almost the same memory technology as sdcard's. Move to a good USB 3 stick (closer to SSD technology) or a harddrive and database operations will be insanely faster, as high or higher than the numbers we see with f2fs.
I have plenty of data to support this if it can be of any help? I work at a place where they produce these things for other labels. Hence the abundance of components.
(2013-12-26, 20:24)xbs08 Wrote: [ -> ]Just tried gpu_mem 136M (CPU gets 111M) and it seems to have a positive effect during fast scrolling.
Now there's always 1 to 3-4 posters visible when fast scrolling.
Could the mce be sending input signals much to fast for the rpi to keep along?
I can scroll as fast as I like and the fanart is already loaded, again storage db operations moved to a small iPod HD 1,8". For example if I press page down 1 or 10 times in a row, all fanart and covers for next page are already loaded?!
OpenELEC 3.2.4, result has been the same since before 3.0.
(2013-12-25, 05:22)maratonomak Wrote: [ -> ]How about an advancedsettings.xml for the best performance ?
Its already included in your image, look in /usr/share/xbmc/system/ this advancedsettings.xml is trimmed for the release and is loaded before the /userdata/ advancedsettings.xml file. Any changes to existing settings or adding of settings is loaded afterwards and will be appended or changed to the value set in the /userdata/ file.
Rbej has a very few extra options you probably want to set but otherwise I recommend don't create it if you do not need it, again one is already provided. Check your logfile to help see how it works.
(2013-12-24, 22:18)sraue Wrote: [ -> ]a bit OT: :-)
The OpenELEC Team want to wish all of our users, Team XBMC, supporting manufacturers and developers a warm, lovely, healthy and joyful Christmas and that you will enjoy OpenELEC in the most useful way these days.
We would like to thank our users, project team and partners for their efforts in testing, reporting and fixing issues, adding features, creating how-to documents, and donations of hardware and funds to the project. We hugely appreciate your continued support!
http://openelec.tv/news/20-project/112-c...ishes-2013
greetings
Stephan
Thanks and merry Christmas to you Stephan.
And ofcause a big thanks for the best media center software solution out there from me and everyone I personally know who tried it.
F2FS on my USB was amazing for the first few days, but my OpenELEC is at a complete crawl at the moment, it's a nightmare to use.
Just lost my settings (F2FS) when RPi hanged
(2013-12-27, 20:22)xbs08 Wrote: [ -> ]Just lost my settings (F2FS) when RPi hanged
I'm getting that a lot - I backed up guisettings.xml to the desktop and copy it back over whenever it screws up.
Edit: What is the easiest way to back up my USB in Windows without making an image of the drive?
If you just want the xbmc instalation use winscp and backup .xbmc folder.
There's also a xbmc backup addon that I ran every week.
(2013-12-27, 17:03)tuxen Wrote: [ -> ]How about an advancedsettings.xml for the best performance ?
Its already included in your image, look in /usr/share/xbmc/system/ this advancedsettings.xml is trimmed for the release and is loaded before the /userdata/ advancedsettings.xml file. Any changes to existing settings or adding of settings is loaded afterwards and will be appended or changed to the value set in the /userdata/ file.
Rbej has a very few extra options you probably want to set but otherwise I recommend don't create it if you do not need it, again one is already provided. Check your logfile to help see how it works.
MashUp has the option to add Tuxens advancedsetting along with Mikey1234 and 0 cache advancesetting.xml. I'm currently using Rbej's, but i've tried the other 3 as well.
I can't notice any difference . Currently I'm on Rbej's build (Frodo) using his advancesettings.xml. Just trying to improve as much as I can
Thank you !
(2013-12-27, 16:34)tuxen Wrote: [ -> ]But overclocking away, speed won't matter much if you use USB 2 memory sticks no, because the rely on almost the same memory technology as sdcard's. Move to a good USB 3 stick (closer to SSD technology) or a harddrive and database operations will be insanely faster, as high or higher than the numbers we see with f2fs.
Are you saying that, as a class, usb3 sticks have faster memory? If not, I don't see how there would be a benefit over USB2, as the pi' USB interface is usb2, so the faster interface would not help.
(2013-12-28, 05:52)allan87 Wrote: [ -> ] (2013-12-27, 16:34)tuxen Wrote: [ -> ]But overclocking away, speed won't matter much if you use USB 2 memory sticks no, because the rely on almost the same memory technology as sdcard's. Move to a good USB 3 stick (closer to SSD technology) or a harddrive and database operations will be insanely faster, as high or higher than the numbers we see with f2fs.
Are you saying that, as a class, usb3 sticks have faster memory? If not, I don't see how there would be a benefit over USB2, as the pi' USB interface is usb2, so the faster interface would not help.
USB 3.0 sticks have much faster memory and controllers. Even in usb 2.0, they are faster then regular usb 2.0 sticks.
I noticed noticeble speedups in using xbmc using a ext4 formatted 16GB usb 3.0 Sandisk Extreme stick.