- This topic has 36 replies, 12 voices, and was last updated 16 years, 10 months ago by
.
-
Posts
-
Hello,
I have a LinkSys NSLU2 that I have “unslung” http://www.nslu2-linux.org/wiki/Unslung/HomePage. These things worked fine and I installed mt-daapd on it, the “nightly builds” and it works fine with my Roku Soundbridge. There is however one problem, the performance is quite lagging. When I e.g. “Brows Artists” I have to wait for a minute before all artists (~1500) are downloaded to the Soundbridge.
On the other hand, if I run firefly on a laptop with Windows, things are much better and the same operation is complete within a few seconds (and during that test I ran a compile simultaneously on a large source tree, so the machine was also under stress).
Are there any key tricks to make firefly on an unslung NSLU more responsive?
@uncleremus wrote:
Hello,
I have a LinkSys NSLU2 that I have “unslung” http://www.nslu2-linux.org/wiki/Unslung/HomePage. These things worked fine and I installed mt-daapd on it, the “nightly builds” and it works fine with my Roku Soundbridge. There is however one problem, the performance is quite lagging. When I e.g. “Brows Artists” I have to wait for a minute before all artists (~1500) are downloaded to the Soundbridge.
On the other hand, if I run firefly on a laptop with Windows, things are much better and the same operation is complete within a few seconds (and during that test I ran a compile simultaneously on a large source tree, so the machine was also under stress).
Are there any key tricks to make firefly on an unslung NSLU more responsive?
There are several problem with the slug — it’s under-cpu powered, under RAMed, etc. Turns out it’s really hard to make it perform well. 🙁
This particular problem, though, seems to scale okay by making an index on the fields you browse on. I was considering building indexes on those fields to help speed up the returns on browses.
If you are comfortable with playing around in the raw database with sqlite, you can do that yourself:
$ sqlite /opt/var/mt-daapd/songs.db
sqlite> create index idx_artist on songs(artist)
That should build the index, and it should use that index when doing browses by artist.
— Ron
Hmmmm, I’m having a problem when I try to follow your recommendation, I get this strange behaviour:
# ls -las /opt/var/mt-daapd
4 drwxr-xr-x 2 guest root 4096 Jan 27 23:11 .
4 drwxr-xr-x 3 root root 4096 Jan 18 07:15 ..
34220 -rw-r--r-- 1 guest everyone 34999296 Jan 27 23:11 songs.db
20 -rwxr-xr-x 1 guest root 18139 Jan 21 11:33 songs.gdb
# sqlite /opt/var/mt-daapd/songs.db
sqlite: No such file or directory
I also installed midnight commander, but I cannot run it, I get the same thing.
# mc
mc: No such file or directoryEDIT:
Found the problem, I think /opt/bin is not in my path, doing
# /opt/bin/sqlite /opt/var/mt-daapd/songs.db
SQLite version 2.8.16
Enter ".help" for instructions
sqlite> create index idx_artist on songs(artist)
...>
so I guess it is creating the index now
Hmmmm, I have no idea what to do now, I have never interacted with sqlite before. It still looks like its processing, but I guess it is not.
sqlite> create index idx_artist on songs(artist)
...>
...> .help
...> help
...> quit
...> q
...> sqlite close
...> close
...>
The first …> came immediately, or very shortly, after I entered return. My point being that it did not seem like the time it would take to index all those artists.
hehe, thats prolly the newbie SQL error/trap #1, ever 😀
you need to end all your commands with a semicolon
;😉
@rpedde wrote:
@uncleremus wrote:
Are there any key tricks to make firefly on an unslung NSLU more responsive?
If you are comfortable with playing around in the raw database with sqlite, you can do that yourself:
$ sqlite /opt/var/mt-daapd/songs.db
sqlite> create index idx_artist on songs(artist)
That should build the index, and it should use that index when doing browses by artist.
— Ron
Many many thanks, this worked very fine. I did as you said and restarted mt-daapd and got a lot faster access when “entering” an artist in the “Browse Artists” part of the navigation in the Soundbridge.
There is however one more thing I’d like to speed up and that is the initial download of artists, that is taking as much time as before, i.e. the part where I press “OK” in the “Browse Artists”-field.
This would be especially useful, since I am often browsing like this:
- Browse Artists? OK! …30s….
Frank Zappa? OK!…[now much faster thanks to your tip!]…
All Songs? OK! ….[also faster]….
PlayAnd then, when I want to change Artist, i have to go through all this again (at least I think so, I haven’t found another way with the Soundbridge).
So, if I could speed up step 1 above, that would make it even better.
@uncleremus wrote:
And then, when I want to change Artist, i have to go through all this again (at least I think so, I haven’t found another way with the Soundbridge).
So, if I could speed up step 1 above, that would make it even better.
Don’t forget that using ADD (to queue) on the remote rather than PLAY does not throw you back to the beginning of the search. So if you know what you will want to listen to after you’ve listened to Frank Zappa, then after adding him you can quickly step through to other artists and ADD them as well. Once all done, press PLAY to start. Should save you some time. 🙂
There is however one problem, the performance is quite lagging. When I e.g. “Brows Artists” I have to wait for a minute before all artists (~1500) are downloaded to the Soundbridge.
On the other hand, if I run firefly on a laptop with Windows, things are much better and the same operation is complete within a few seconds (and during that test I ran a compile simultaneously on a large source tree, so the machine was also under stress).
Are there any key tricks to make firefly on an unslung NSLU more responsive?
Well the NSLU is a different class in CPU power than a normal PC, but I cannot agree that it is running sluggish at all with about 3500 songs here.
Even a play-all takes only ca. 5 Secs. downloading all 3500 song titles. I am running DebianNSLU-LE here, but it wasnt much different with unslung before.
I think the key things to keep in mind are:
-
– Run 1-2 major applications on it. Maybe one minor in addition. Not more. The thing isnt a general server to run 20 server-apps at the same time as you can do with a PC running some linux-server install. Strip the unneeded rest!
– Run economic programs. Dont use apache/mysql if lighthpptd/sqlite will also do. etc.
– Use the latest nightly. It is way faster than the stables. Especially the transcoding is way better.
– De-underclock it unless it is alreadyI can run without trouble mt-daapd latest nichthly, samba and ntpd on my slug. It will run without rebuffering when I have it transcode an ogg from an AES128 encrypted partition. Even though it has to decrypt plus transcode/stream then. Theres even a bit reserve – small up/downloads via samba dont hamper it.
Now if I trash the thing by logging in via ssh and starting a big compile job, then it goes crawling of course. But is that a surprise?So the performance is more than enough, if one doesnt overwhelm the unit by trying to do everything at the same time. What you describe seems to indicate something is wrong, thats not the slow NSLU.
@mas wrote:
What you describe seems to indicate something is wrong, thats not the slow NSLU.
I have to agree. My “worst-case” browse is Browse Songs (I have 6685 today) and that takes about 14 seconds (maybe 2 or 3 more if streaming WAV and transcoding at the same time).
Setup NSLU2 at 266MHz (unslung to stick, but database on HDD), SB M1000 is wireless to router, router is wired to NSLU2.
- The forum ‘General Discussion’ is closed to new topics and replies.