[jelle-e]

Hi all,

I have quite a large music library with 16.000+ artists on my Raspbmc. While the official remote doesn't support XBMC Frodo yet (and Tom's version also doesn't seem to do the job) I tried out Yatse's remote for XBMC. It works great with a large music library on my ZBox (XBMC 11 Eden) but not on my Raspbmc (Frodo alpha5).

I noticed that when I'm refreshing the library on my zbox it takes a while, no problem ofcourse, but when my HTC screen turns off automatically after about 30secs the refreshing stops in Yatse. Also not really a problem with the zbox because I just have to keep the screen on for 2 minutes or so... With Raspbmc it's a different story. The Raspberry takes so long to 'share' the large library that I have to keep the screen on (by touching the screen once every couple of secs) for about 10 minutes. After that amount of time, the syncing stops. I get no data and pressing refresh again results in a direct answer "No media."

Any idea as to why this problem occurs? Thanks in advance!

... by the way, I've always used the offcial remote and I liked it, but I'm starting to like Yatse already after one day of use. Thanks!

[Tolriq]

Hi,

Glad you love Yatse

Raspbmc is really slow due to hardware but there's also some build slower than other, you may want to try an other one to see, (please don't use nightlies since they contain pre 8th august Xbmc code but don't set the build date in revision so Yatse can't work well with those for the moment).

After that please activate debug mode in advanced settings and open an issue at http://yatse.leetzone.org/redmine/projec...get/issues (easier to follow / upload files) so I can check what's happening.

[Millencolin007]

Hi Tolriq,

I played around with raspbmc a bit myself since it doesn't work with Music Pump XBMC Remote and some requests like Files.GetSongs take forever on my raspberry pi. For ~10'000 songs it takes up to 5minutes to get a response from xbmc on my pi. The connection of most remotes will probably timeout before using the default settings.

[Tolriq]

hi,

for last frodo i do sync by 500 items chunks to correct this since frodo is now good at doing limits in db request.

the problem is that most rpi builds use the 4th august xbmc code base just 4 days before the needed change from strings to arrays

i hope this changes quick

btw for sync with older system i use 5mn timeouts enough for most systems.

[Millencolin007]

Since yesterday there is a new raspbmc build available, so people will hopefully start to update

I don't know if you have a pi to test yourself but I made some speed measurements to fetch the Albums so you can see how slow it really is. Below you see the execution time for different limit parameters on my raspberry pi. (~ 10000 songs in library)

Code:

curl  -H "Content-Type: application/json"  -d "{\"id\":1,\"jsonrpc\":\"2.0\",\"method\":\"AudioLibrary.GetAlbums\",\"params\":{\"limits\":{\"start\":0,\"end\":100},\"properties\":[\"style\",\"albumlabel\",\"artistid\",\"type\",\"description\",\"thumbnail\",\"genre\",\"title\",\"artist\",\"rating\",\"year\"]}}" http://xbmc:8080/jsonrpc

limit time
25 0m1.373s
50 0m2.588s
100 0m6.624s
150 0m11.034s
200 0m15.688s
250 0m19.972s
300 0m24.515s
350 0m28.503s
400 0m33.098s
450 0m36.879s
500 0m41.936s

[Mizaki]

Ouch! I'm letting the user enter a value for limits for the various libraries with AWXi. Maybe that's the way to go. Then they only have themselves to blame if it takes too long

[Tolriq]

Ouch too :p

I don't have rpi but I may try to get one it seems like a very fun geek tool

Your numbers confirm the problem as the same as ATV cpu power is really need to do the json encode.

I'm no C expert but perhaps there's improvement place to this in Xbmc.

The side effect of this is that until they update the libmicrohttpd the webserver is not powerful / stable enough to handle tons of quick requests. So reducing chunks to 25 may have side effect too vastly augmenting the risk of http failure during sync.

Can you please try the same request for songs to see if it's the same problem ?

But the solution seems to add to our remotes an option for small chunks or try to negotiate with atv / rpi builders to have something in the revision field to identify those machines.

[Millencolin007]

Haha, just tried the same with AudioLibrary.GetSongs. Takes only 24 minutes to execute without limit :-(

Code:

curl  -H "Content-Type: application/json"  -d "{\"jsonrpc\": \"2.0\", \"method\": \"AudioLibrary.GetSongs\", \"params\" : { \"properties\" : [\"title\", \"artist\", \"genre\", \"album\", \"track\", \"thumbnail\", \"file\", \"duration\", \"rating\", \"albumid\", \"artistid\", \"albumartist\"] }, \"id\" : 1 }" http://192.168.1.35:8080/jsonrpc

[Tolriq]

24 min is very fast :p

But I'm pretty sure there's a bug in Xbmc Frodo and Songs Albums thumbs, because I tried a temp install of last Frodo it ask me to rescan to get the thums I refused. And on this install on a fast PC songs syncs is now quite slow. Perhaps it tries to check something about thumbs in request leading to tons of file access.

I need to to more investigating on that before opening a ticket.

Is the ratio 25 / 500 item the same ?

[Millencolin007]

Here the execution time for GetSongs. Looks a bit better using limit but would still take ~10 minutes for 10'000 songs

Code:

curl  -H "Content-Type: application/json"  -d "{\"jsonrpc\": \"2.0\", \"method\": \"AudioLibrary.GetSongs\", \"params\" :  {\"limits\":{\"start\":0,\"end\":50}, \"properties\" : [\"title\", \"artist\", \"genre\", \"album\", \"track\", \"thumbnail\", \"file\", \"duration\", \"rating\", \"albumid\", \"artistid\", \"albumartist\"] }, \"id\" : 1 }" http://192.168.1.35:8080/jsonrpc | python -mjson.tool

25 0m1.608s
50 0m4.166s
100 0m6.415s
150 0m8.933s
200 0m11.613s
250 0m14.076s
300 0m16.665s
350 0m19.105s
400 0m21.619s
450 0m24.062s
500 0m26.454s

[Tolriq]

Those numbers are not cool

500 is faster than 25 seems all values are random impossible to really optimize