[steve1977]

That's even weirder. I am actually using one of your builds. I then SSHed into openelec (ssh root@IP-address) through terminal on a mac. When writing ./texturecache.py it didn't find the file, so I used the curl comment to download the utility (using the curl command from your other thread). When then just typing ./texturecache.py, I am getting the "access denied". Thoughts?

[Milhouse]

Using one of my builds, it won't find "./texturecache.py" (which means: "run the file texturecache.py from my current directory") because the version I supply is in the folder /usr/bin. Since /usr/bin is on your PATH, you can omit the "./" prefix and use just "texturecache.py" and it will find and use the installed version.

However, if you do decide to download into your current folder, do remember to run the "chmod +x ./texturecache.py" command, as per the instructions, otherwise you'll get a "permission denied" error.

I genuinely don't recognise the "access denied" error you claim to be seeing, so either you're mistyping/misquoting this error, or you've mistyped the command, or you've done something else wrong. Either way, a screenshot of all that you are seeing would help so that I have some context because I don't understand what you are telling me - it makes no sense.

[steve1977]

Probably a few things that I was doing wrong. I didn't chmod the file, which is probably the first issue.

What I did now is just type "texturecache.py" (instead of ./texturecache) in my current directory (after SSH), which works. I am not sure whether this is now using the one that I have downloaded or the pre-installed one.

I entered the comment as suggested for avatar and it gives me the following info:

OpenELEC:~ # texturecache.py jd movies avatar
[
{
"art": {
"fanart": "image://smb://192.168.1.xxx/E/Avatar (2009) [1080p bluray]/fanart.jpg/",
"poster": "image://smb://192.168.1.xxx/E/Avatar (2009) [1080p bluray]/poster.jpg/",
"thumb": "image://smb://192.168.1.xxx/E/Avatar (2009) [1080p bluray]/thumb.jpg/"
},
"file": "smb://192.168.1.xxx/E/Avatar (2009) [1080p bluray]/Avatar (2009).mkv",
"label": "Avatar",
"movieid": 451,
"title": "Avatar"
}

[Milhouse]

Probably a few things that I was doing wrong. I didn't chmod the file, which is probably the first issue.

What I did now is just type "texturecache.py" (instead of ./texturecache) in my current directory (after SSH), which works. I am not sure whether this is now using the one that I have downloaded or the pre-installed one.

If you did download anything, delete it with "rm ./texturecache,py" and you'll only be using the built-in version.

I entered the comment as suggested for avatar and it gives me the following info:

Good, all the metadata looks correct - you've scraped the movies using your SMB shares for artwork (not remote website locations) and also the movie file, so the delays aren't due to the internet etc.

It's hard to say where the slowness is coming from. You're using local SQLite databases, so at least for a change it's not a MySQL issue!

Have you tried NFS in place of SMB, if only to see if it makes any difference? Try scraping just a small subset of movies (no more than 6 movies) as test. Enable debug, scrape using SMB - upload the debug log. Then try scraping the same movies using NFS, again upload the debug log. Paste links to both debug logs.

[7s7]

Probably a few things that I was doing wrong. I didn't chmod the file, which is probably the first issue.

What I did now is just type "texturecache.py" (instead of ./texturecache) in my current directory (after SSH), which works. I am not sure whether this is now using the one that I have downloaded or the pre-installed one.

If you did download anything, delete it with "rm ./texturecache,py" and you'll only be using the built-in version.

I entered the comment as suggested for avatar and it gives me the following info:

Good, all the metadata looks correct - you've scraped the movies using your SMB shares for artwork (not remote website locations) and also the movie file, so the delays aren't due to the internet etc.

It's hard to say where the slowness is coming from. You're using local SQLite databases, so at least for a change it's not a MySQL issue!

Have you tried NFS in place of SMB, if only to see if it makes any difference? Try scraping just a small subset of movies (no more than 6 movies) as test. Enable debug, scrape using SMB - upload the debug log. Then try scraping the same movies using NFS, again upload the debug log. Paste links to both debug logs.

Hi,

I am having the same issues as Steve1977

And I am running NFS, all my metadata is being scraped locally.

Running Millhouse OpenElec 10Oct 2014 SD-USB install


# texturecache.py jd movies avatar
[
{
"art": {
"fanart": "image://nfs://192.168.1.120/volume1/Movies/Avatar (2009)-fanart.jpg/",
"thumb": "image://nfs://192.168.1.120/volume1/Movies/Avatar (2009).tbn/"
},
"file": "nfs://192.168.1.120/volume1/Movies/Avatar (2009).avi",
"label": "Avatar",
"movieid": 100,
"title": "Avatar"
},
{
"art": {
"fanart": "image://nfs://192.168.1.120/volume1/Movies/Avatar (2009)_2-fanart.jpg/",
"thumb": "image://nfs://192.168.1.120/volume1/Movies/Avatar (2009)_2.tbn/"
},
"file": "nfs://192.168.1.120/volume1/Movies/Avatar (2009)_2.avi",
"label": "Avatar",
"movieid": 101,
"title": "Avatar"
}
]

Cheers

Steve

[wrxtasy]

Lets back up a bit steve1977 and 7s7 seem to both be using a Milhouse Openelec testbuild. The question has to be asked why ?

The official Openelec for the RPi is v4.2.1 - Oct 4 2014, which I'm currently running. Its damn fast on an overclocked RPi, especially when using a low texture Skin like Eminence.

I likely run an even bigger movie database than both of you from a Mac using NFS and locally stored info and have nill problems, using just a cheap 16GB Sandisk micro SDHC.

@ 7s7 - Why the SD - USB ?
It certainly complicates the setup. How old is the SDHC and the USB ?

@steve1977 - First question, when did your issues start and what have you changed in your setup ? Was it after installing a testbuild ?
Maybe its SMB issues with the testbuild.

[7s7]

Lets back up a bit steve1977 and 7s7 seem to both be using a Milhouse Openelec testbuild. The question has to be asked why ?

The official Openelec for the RPi is v4.2.1 - Oct 4 2014, which I'm currently running. Its damn fast on an overclocked RPi, especially when using a low texture Skin like Eminence.

I likely run an even bigger movie database than both of you from a Mac using NFS and locally stored info and have nill problems, using just a cheap 16GB Sandisk micro SDHC.

@ 7s7 - Why the SD - USB ?
It certainly complicates the setup. How old is the SDHC and the USB ?

@steve1977 - First question, when did your issues start and what have you changed in your setup ? Was it after installing a testbuild ?
Maybe its SMB issues with the testbuild.

Hi Running SD-USB as it is noticably faster and actually it is an easy setup to update, at any time. Both devices are only months old, SD is a Sandisk Ultra sdhc (30mb/s) and the USB is a 8GB USB 3.0 stick. This is a recognized way to install Openelec on a Raspberry Pi (http://wiki.openelec.tv/index.php?title=...__28USB_29)
I am not overclocking my PI (perhaps I should).
Its only when I do a Library build for the first time that I notice this problem (of coarse after that there should be only minor library changes day to day)
I have only just started using Millhouse builds and understand that it can have possible bugs and I will wear that. I just noticed this thread and know the problem is not just with SMB as I am seeing the same and I am using NFS.

[wrxtasy]

Hiya I appreciate that the WIKI told you it may be the preferred way of installing, but one of the main reasons apart from speed was "This is to stop corruption of SD Cards with issues".

This corruption issue has now been pretty much eliminated I believe with the RPi. Also that WIKI is quite out of date - before the quick reliable SDHC's we now have came on to the market.

Yes you should overclock your RPi. You end up with massive improvements in skin fluidity and library browsing speed. Using NFS my 1080p movies start instantly, even over WIFI.
I would not be worried about reliability. With mine on a custom max over clock, the RPi never gets over 63 degrees C. No heatsinks and in an enclosed case. Reliable as.

Q. Have you asked Milhouse about test builds over in this thread:
http://forum.xbmc.org/showthread.php?tid...3&page=100

I remember reading that he was working on improved library scanning speed for Kodi.

[7s7]

Hiya I appreciate that the WIKI told you it may be the preferred way of installing, but one of the main reasons apart from speed was "This is to stop corruption of SD Cards with issues".

This corruption issue has now been pretty much eliminated I believe with the RPi. Also that WIKI is quite out of date - before the quick reliable SDHC's we now have came on to the market.

Yes you should overclock your RPi. You end up with massive improvements in skin fluidity and library browsing speed. Using NFS my 1080p movies start instantly, even over WIFI.
I would not be worried about reliability. With mine on a custom max over clock, the RPi never gets over 63 degrees C. No heatsinks and in an enclosed case. Reliable as.

Q. Have you asked Milhouse about test builds over in this thread:
http://forum.xbmc.org/showthread.php?tid...3&page=100

I remember reading that he was working on improved library scanning speed for Kodi.

Hi,

Overclocked my Pi

arm_freq=800
core_freq=300
sdram_freq=400
over_voltage=0

OMG how good is that...

Thanks for the advice.

Can I please ask what your overclock settings are.

Haven't asked Millhouse yet, but will study the thread and what's happening

Cheers

Steve

[wrxtasy]

Ha ha,
You will now get addicted to the Speed mate.
Firstly make sure you have a good power supply. I use a spare iPad one I had lying around.

Now grab ya goolies Steve and pray for no Toasted Raspberries -->>>

arm_freq=1100
core_freq=550
sdram_freq=600
over_voltage=6
over_voltage_sdram=4
avoid_pwm_pll=1
hdmi_force_hotplug=1
hdmi_ignore_cec_init=1

The last two hdmi_ are for a fast reboot of the RPi. It will not affect CEC operation.
Next try the Eminence skin, it uses a low number of textures and runs beautifully on an overclocked RPi. Even faster than Confluence.

You won't look back.

[7s7]

Thanks,

How do you go for heat load, I know you said you don't use heatsinks, but wouldn't that be a good idea (especially in Perth during the summer).

At ARM Freq 800 I was getting a CPU temp of 56deg went playing a show which i thought was OK but the ambient temp was only 22deg.
On a hot humid Melbourne day (40deg) that can rise the inside temp 5-8deg (even with air-con). So I would imagine that would have a great impact ont the CPU temp

Lovin' the speed I am getting now though, can't wait to get home and see what is like with those settings.

Cheers


Steve

[ActionA]

The pi is good to 85deg at which time, it will shut itself down to prevent any damage.

[Milhouse]

It won't shut down, it will throttle the CPU back to 700MHz.

[wrxtasy]

@ steve - We're not talking about a snag on a barbie here, this is silicon. Bits and bytes - digital jazz man. It loves the heat!

One piece of advice - if your see a square rainbow ! - get your eyesight checked ! - or failing that read this thread:

http://forum.osmc.tv/showthread.php?tid=15186

[7s7]

@ wrxtasy

Thanks for the advice, have overclocked and all looks Brilliant :-)

Seems to have fixed to slow library scan too..
Same setup but just overclocked is making library scan about 10x as fast (if not more).

Happy Man