Announce: SMD, let's discover the music

[volpone]

...I suggest to try "apt-get -f install" indeed. It shouldn't get worst...

Thank's, apt-get -f install succeed !
Java 6 is now installed on my X86 ReadyNas.
- SMD importer is currently scanning my SBS library (discovery phase 1/2 for 67000 songs)...
- SMD rich client(Yggdrasil)is also up and running (on a Win7 Laptop)
More later ...

Volpone

[Ap15e]

Any news on http://forums.slimdevices.com/showpo...9&postcount=13 ?

[erland]

Any news on http://forums.slimdevices.com/showpo...9&postcount=13 ?

We've fixed it in the latest continuous build available in the continuous build repository, we will try to publish an official release within a week or so.

The continuous build repository always contains the latest version committed to svn with a 30 minute delay, it's is available through the below url if you want to try it before we make an official release. Just be aware that this repository is designed for developers so it can sometimes be updated quite frequently and it can sometimes contain partly unfinished and untested logic.

http://downloads.socialmusicdiscovery.org/smd-plugin/svn-alpha-repository.xml

[arztde]

I like the idea, is there any possibility to port it to slow machines like synology or etrayz? They are based on ARM CPU with no FPU inside. There are a lot of users that use such machines and for etrayz i can say there is no java 6 available as farisee. Maybee i am wrong in this.....

Maybee some other solution exists to port it?


P.S. OT Thanks Erland: I did found in your wiki how to get my TT C 2300 to run for VDR.

[pippin]

I think this will nit work out with the current implementation.
On my latest generation, dual core Mac and with a moderately sized library SMD needs several hours to scan. For comparison, SBS needs less than 15min.
Response times also are also much slower than my low-powered SBS.
I don't want to imagine this on a slow system.

No, with this implementation it's only for high-powered machines. It probably has to go through a learning curve of a few iterations before optimization for speed becomes a feasible goal.

[arztde]

No, with this implementation it's only for high-powered machines.

For what this anachronism in time? As i remebered you was yourself starting to announce that applications like iPeng never will never run before you did developed it for surprise of a lot of people.

My thinking in all this is that mostly in future people have no more PC towers with a lot of energy consumtion running all day. As i set up VDR for example i was wondering my fastest machine i have running is a eee PC and the rest are Nettops. So no chance to run an internal PCI TV card.

So i bought an old PC for 10 euros that i could do some demos. Be aware that power machines take 400 Euros just for electicity each year.

I see in this mistress a possibility. For idea develope an application that is not so deep integrateinside the SBS. Let it run on an external PC or nettop somewhere and let the SBS fetch and us the data from there.

Just to give ideas to think different. I think if on a NAS like synology runs the SBS a small plugin is enough to fetchfrom another more powerfull machine like a EEE PC the data. Fetch and pulling existing data should not take much Power of the system.

[erland]

I like the idea, is there any possibility to port it to slow machines like synology or etrayz? They are based on ARM CPU with no FPU inside. There are a lot of users that use such machines and for etrayz i can say there is no java 6 available as farisee. Maybee i am wrong in this.....

Maybee some other solution exists to port it?

I tried it on a Sheevaplug some time ago but there was something not optimized with the Java implementation so it used a lot of CPU even when it didn't do anything. We will investigate it later but it's not a priority among existing contributors in the near future. However, if there are some developer out there who like to help investigating this, please let us know that you like to join the project.

It could be related to OpenJDK which I used on the Sheevaplug, I don't think the Oracle/Sun JVM can be easily installed on a Sheevaplug so I didn't try anything else.

The scanning might take some time but I think that's acceptable because you are not going to do a full rescan in SMD very often, it's not like SBS where tags is the only persistent storage of your metadata, in SMD the SMD database will be the metadata source for many users and tags are just used for an initial import of a track. We haven't implemented any incremental scanning yet, so at the moment a second rescan takes a lot longer time than it will do in the end. If the scanning/import is still to slow on low power hardware, we can always consider allowing a faster computer to be used during scanning/importing and then use the slow system only when managing and browsing the SMD database contents. On top of this there are some other things that can be optimized in the scanning process, for example we currently recalculate the checksum based identity every time and this would be possible to cache and only re-calculate for files where the last modified timestamp has changed.

The problem on the Sheevaplug was that it was also slow when browsing and that really needs to be solved for it to work on low power hardware.

Still, my experience on the Sheevaplug wasn't too good, so at this stage I don't want to guarantee that it will work good on similar hardware in the future, but we will eventually at least spend some effort on trying to make it work. One important aspect is going to be memory, I don't expect it to work on devices with 128/256 MB memory, I suspect we are going to need at least 512MB as the device has to run both SBS and SMD processes.

[audiomuze]

Here's the scan time from a subsection of my library that I use for testing purposes. Granted, it's a Quad Core machine running 64 bit kernel with 8GB of RAM installed, but I don't find the SMD scan to be unacceptably slow. Bear in mind in the stats below SBS is doing an incremental scan whereas SMD is doing a full blown rescan.

~~~~~~~~~~~~~~~
Total Tracks: 20,948
Total Albums: 1,431
Total Artists: 819
Total Genres: 345
Total Playing Time: 1457:31:37

Music Scan Details
Discovering files/directories: /media/65ed9981-e55d-4943-85f0-a2f5610d3310/zTagged (22452 of 22452) Complete 00:00:12

Scanning new files: /media/65ed9981-e55d-4943-85f0-a2f5610d3310/zTagged (353 of 353) Complete 00:00:54
Pre-caching Artwork (24 of 24) Complete 00:00:08
Social Music Discovery phase 1/2 (20948 of 20948) Complete 00:09:46
Social Music Discovery phase 2/2 (1459 of 1459) Complete 00:08:41
The server has finished scanning your music collection.
~~~~~~~~~~~~~~~

As Erland says, there's lots of room to optimise and avoid unnecessary rescanning (and it will be done in time to come), but that's not the development priority right now.

@ Erland - another approach that could bypass recalculating the checksum would be to export it to XML and have puddletag write it to the metadata as a tag - that way it's a once off calc if the user wishes to go down this path.

[arztde]

The problem on the Sheevaplug was that it was also slow when browsing and that really needs to be solved for it to work on low power hardware.

I did not speak about to do the job directly on this low power hardware. I speak about to implement from beginning that the app can be installed on a power hardware somewhere inside the Network and do the job from there to an external squeezeboxserver.

For example. The NAS where is running the SBS have to low power to do this, but my joggler have enough power to do it. Or my EEE Box or my EEE PC.

Joggler is allways online in the kitchen but have if i am sitting in Living room nothing to do or special during the night he can do the Job. The low powered NAS what have a lot of people is also allways online. Or my EEE PC with 1GB RAM and Atom CPU.
At a later point Logitech can do some developement also to let this job doing the Touch or the radio like a etrayz i own or a synology. My suggestion is from beginning to find a way that this app needs not absolute to be stored and working on the same machine like the SBS is located.

If you realy think about server client application think about a shared user modell. Like a cluster that the maschines are able to share their power what is necessary like in a cluster. If this application runs as a server the place where the server should be located should be independant.

Logitech runs the way to support that 2 radios you can buy are able for stereo. If you have such a combination inside the Network of several squeezeboxes let them realy but together their RAM and CPU Power to help like inside a cluster to do this work together.

Something like this in all of honor your developement Erland is a escape from your power consumting plugins. I do not use them like the Ignaz plugin on normal use. if i need i put on my EEEBox that take the Data from my NAS. But to find a way of shared CPU and RAM Power is demonstrate in several projects. This idea will put the project to a much higher level. And such applications are proved over the Internet working anyways to share the power of differend PCs worldwide to help to give a application the necessary power.

Keyword is Distributed Computing:
http://en.wikipedia.org/wiki/Distributed_computing
Cluster-Computing
Meta-Computing (Englisch)
Grid-Computing
Cloud Computing
Peer-to-Peer
Client-Server-Architektur

[pippin]

For what this anachronism in time? As i remebered you was yourself starting to announce that applications like iPeng never will never run before you did developed it for surprise of a lot of people.

I don't understand what you are trying to say.

I NEVER announced that anything like iPeng would not work on anything. Actually publishing iPeng was pretty much the first thing I did here (back when it was still a skin) except for some calls for help on how to get SBS to run on Linux.