PDA

View Full Version : Alpha testers wanted for Java-based server



clumsyoik
2005-12-17, 16:19
Hi all,

I've been hacking on an new Java-based server implementation, and I'd like to get two or three volunteers to try it out before releasing to a wider audience. I have run it on Windows and Linux, but I specifically want a Mac owner to try it out. Windows/Linux users will need the Sun JDK/JRE.

I decided to completely rewrite the server rather than implement the features I want in perl. That's how much I hate perl :-)

In its current state, the server simply plays random Ogg and Flac tracks from the library, and displays the track time/album/artist. You can also skip forward if a rubbish track comes on.

This is pretty much the minimum functionality that is usable (for me, at least).

There are a few interesting features:

* The server is highly multithreaded. The aim is for UI latency to be completely unaffected by, well, anything.
* Transcoding is done to physical Flac files (to allow FFWD/REW, although that is not written yet)
* Allows the user to set a rating for a file (although nothing is done with the rating yet)
* Significantly lower resource usage than slimserver. Appears to run OK with -Xmx32M (ie 32MB JVM heap)
* Scanning of tags is fast, automatic and does not affect the UI.

Anyway, email clumsyoik@hotmail.co.uk if youre interested.

JJZolx
2005-12-17, 19:29
Hi all,

I've been hacking on an new Java-based server implementation, and I'd like to get two or three volunteers to try it out before releasing to a wider audience. I have run it on Windows and Linux, but I specifically want a Mac owner to try it out. Windows/Linux users will need the Sun JDK/JRE.

I decided to completely rewrite the server rather than implement the features I want in perl. That's how much I hate perl :-)

In its current state, the server simply plays random Ogg and Flac tracks from the library, and displays the track time/album/artist. You can also skip forward if a rubbish track comes on.

This is pretty much the minimum functionality that is usable (for me, at least).

There are a few interesting features:

* The server is highly multithreaded. The aim is for UI latency to be completely unaffected by, well, anything.
* Transcoding is done to physical Flac files (to allow FFWD/REW, although that is not written yet)
* Allows the user to set a rating for a file (although nothing is done with the rating yet)
* Significantly lower resource usage than slimserver. Appears to run OK with -Xmx32M (ie 32MB JVM heap)
* Scanning of tags is fast, automatic and does not affect the UI.

Anyway, email clumsyoik@hotmail.co.uk if youre interested.
How well can this coexist with the existing SlimServer? Does it use the same database as SlimServer when it scans? Same logic and tags for determining compilations, etc.? Is there any kind of remote interface, or is the interface a Java applet running only on the server?

clumsyoik
2005-12-18, 02:53
How well can this coexist with the existing SlimServer?
It is complete independent of slimserver, by design. They can coexist in the sense that this won't overwrite or break any existing slimserver installation. You certainly can't run them both at the same time.

You can install them on different PC's, and choose between the servers on the squeezebox. The discovery protocol is implemented so it is painless to switch between the servers.



Does it use the same database as SlimServer when it scans?

No. The slimserver database is very, erm, unoptimised, and one of the goals of this project is to have a fast database.


Same logic and tags for determining compilations, etc.?

None of this stuff has been written. At the moment, it simply plays random tracks.

However, I welcome input onto what the logic for determining compilations should be. Is the current logic OK? One thing I do intend to do is have better support for classical music.



Is there any kind of remote interface, or is the interface a Java applet running only on the server?
There is no remote interface (yet). In fact, the only controls that are available are "play", "volume up", "volume down", "skip forward". When I get round to writing a remote UI, it will likely be a Java application/applet. (Why would anyone write a local application as a bunch of web pages? I don't want to wait 5 seconds for a response to a mouse click)

CardinalFang
2005-12-18, 03:05
Hi all,

I've been hacking on an new Java-based server implementation, and I'd like to get two or three volunteers to try it out before releasing to a wider audience. I have run it on Windows and Linux, but I specifically want a Mac owner to try it out. Windows/Linux users will need the Sun JDK/JRE.

I decided to completely rewrite the server rather than implement the features I want in perl. That's how much I hate perl :-)

In its current state, the server simply plays random Ogg and Flac tracks from the library, and displays the track time/album/artist. You can also skip forward if a rubbish track comes on.

This is pretty much the minimum functionality that is usable (for me, at least).

There are a few interesting features:

* The server is highly multithreaded. The aim is for UI latency to be completely unaffected by, well, anything.
* Transcoding is done to physical Flac files (to allow FFWD/REW, although that is not written yet)
* Allows the user to set a rating for a file (although nothing is done with the rating yet)
* Significantly lower resource usage than slimserver. Appears to run OK with -Xmx32M (ie 32MB JVM heap)
* Scanning of tags is fast, automatic and does not affect the UI.

Anyway, email clumsyoik@hotmail.co.uk if youre interested.

I think this is a fantastic idea. Perl really is the wrong tool for this and Java is reasonably portable, plus it has good free development tools, excellent library support for UIs and file handling.

I do have a Mac, but I use Apple lossless, not FLAC - EAC doesn't run on Mac. I could coopy some FLAC file over I guess and see what happens. Would that be of any use to you?

docbee
2005-12-18, 04:33
if you need someone with a large database (about 35.000 titles) all in mp3, I could give it a test drive. Server is running with linux, hw is p3 1GHz, 384 MB.

As the current slim server has a somehow grown functionality, it might be a good idea...
1) to first specifing tag handling (it is hard to understand what slim server really does with compilations. it looks to be based on id tags and file path information as well, but no specs just an implementation that behaves somehow)
2) to have a second thought how to make the menu navigation much better. more audiotron like for example. the current drill down logic doesn't make good use of the 2 lines of the display.

Any approach to get rid of this perl mess is a step in the right direction. Good luck!

eulbeulb
2005-12-18, 05:05
If somebody could compile it with one of the opensource java compilers, it should be possible to run it without having java installed on one of the linksys nslu-2 units and without having to use an external hd.

That would be so great :-)

clumsyoik
2005-12-18, 07:03
if you need someone with a large database (about 35.000 titles) all in mp3, I could give it a test drive. Server is running with linux, hw is p3 1GHz, 384 MB.
Brilliant. ID3 tag support is my next job. If you send me an email, I can let you know when it's ready.

By the way, unless someone can convince me otherwise, I intend to support ID3V2 only. ID3V1 needs to die and I don't want to prolong its suffering.

docbee
2005-12-18, 07:31
my archive just uses v2 as v1 is far too limited. drop v1, as you can automatically convert v1 to v2, no one out there should have a severe problem with that.

CardinalFang
2005-12-18, 09:57
Brilliant. ID3 tag support is my next job. If you send me an email, I can let you know when it's ready.

Do you plan to support Apple Lossless via Quicktime or just formats that need no 3rd party decoders and are SB native?

Also, is this going to be an open source development or are you going to market it? Just asking to see if there's any opportunity to help, I'm more MIDP Javamyself, but have all the Java tools I need to hand.

danco
2005-12-18, 11:12
On 18/12/05 at 02:05 -0800, CardinalFang wrote
>I do have a Mac, but I use Apple lossless, not FLAC - EAC doesn't run
>on Mac. I could coopy some FLAC file over I guess and see what happens.
>Would that be of any use to you?

AIUI, the point about EAC is in its name. Ripping to FLAC just
happens to be one of its features.

And while you (and others) may choose to use Apple lossless, there is
a straightforward FLAC ripper for the Mac for those who want it,
namely xACT. I haven't tried a direct comparison of xACT coded FLAC
files versus iTunes AAC, though.
--
Daniel Cohen

clumsyoik
2005-12-18, 14:13
Do you plan to support Apple Lossless via Quicktime or just formats that need no 3rd party decoders and are SB native?

I have already implemented transcoding for Ogg Vorbis, so other codecs are certainly possible. I guess if it can be done in Perl then it can be done in Java. Patches will be welcomed :-)



Also, is this going to be an open source development or are you going to market it? Just asking to see if there's any opportunity to help, I'm more MIDP Javamyself, but have all the Java tools I need to hand.
It will be GPL. Source will be available shortly. Am currently looking for somewhere to put it...

clumsyoik
2005-12-18, 14:19
If somebody could compile it with one of the opensource java compilers, it should be possible to run it without having java installed on one of the linksys nslu-2 units and without having to use an external hd.

That would be so great :-)
For some reason (I haven't investigated further), GIJ 4.0 gives a NullPointerException, in a place where the Sun JDK works fine.

Be assured GCJ/GIJ support is on my radar.

Mark Lanctot
2005-12-18, 14:21
clumsyoik wrote:
>
> It will be GPL. Source will be available shortly. Am
currently looking
> for somewhere to put it...
>
>

How about SourceForge.net?

See

http://sourceforge.net/docs/about

"SourceForge.net provides free hosting to Open
Source software development projects."

They have the infrastructure and bandwidth to
support lots of downloads of the software, track
and host multiple versions, maintain worldwide
mirrors, host help files and documentation, etc.

--
___________________________________


Mark Lanctot
___________________________________

Listener
2005-12-18, 14:42
Brilliant. ID3 tag support is my next job. If you send me an email, I can let you know when it's ready.

By the way, unless someone can convince me otherwise, I intend to support ID3V2 only. ID3V1 needs to die and I don't want to prolong its suffering.

Your project sounds interesting.

I hope you will consider supporting the Composer tag and perhaps Conductor and Orchestra/Ensemble tags as well for classical music.

What about OGG Vorbis tags in FLAC files?

Bill

stuorguk
2005-12-19, 03:15
I just stumbled upon this thread. Great news! I hate perl too. I did consider doing a C#/Mono version a while ago, but it seemed a too bigger project for me to handle right now (too many other commitments). I was hoping someone would do a perl frontend to Mono, and then we could slowly migrate parts of the code into one of the other Mono languages. I can do Java, so I will be keeping an eye on this project.

Stuart.

clumsyoik
2005-12-19, 04:10
I hope you will consider supporting the Composer tag and perhaps Conductor and Orchestra/Ensemble tags as well for classical music.

Do you just want to display the info, or do you want to be able to search for a specific composer? I am thinking about the menu/browse interface right now, so now would be a good time for some input...



What about OGG Vorbis tags in FLAC files?

It currently uses the VORBISCOMMENT fields from the FLAC header; if this is what you mean, then it already works.

Listener
2005-12-19, 10:30
Do you just want to display the info, or do you want to be able to search for a specific composer? I am thinking about the menu/browse interface right now, so now would be a good time for some input...


I recently participated in three message threads on this forum where I described my needs for a library of over 1000 classical albums.

--- three message threads

ANNOUNCE: New Beginners Guide in Wiki
http://forums.slimdevices.com/showthread.php?t=18649

Using Composer / Conductor / Band tags effectively
http://forums.slimdevices.com/showthread.php?t=18767

Enhancement requests for Classical or complex music collections
http://forums.slimdevices.com/showthread.php?t=18946

---

I need to browse in successive steps to find the tracks I want to play. My most common pattern is to specify a composer (Beethoven), then a work (Symphony no. 3), then a conductor (Szell/Cleveland). I've got lots of Beethoven and 8-12 CDs with a performance of Symphony 3. I normally have only 1 performance by a conductor but sometimes 2 or 3.

If I first browse on Composer, I then want to browse a list of works Symphony 1 through 9 (a list of 9 items.) If I browse on Album name and I've made that album name unique, I've got a list of about 100 albums to browse with names like "Beethoven - Symphony 1 - Karajan". That doesn't work well on a GUI interface and it does not work at all on the 2 line Squeezebox display.

Sometimes I'd like to browse in a different order. Maybe Arttist first and then composer.

The threads I listed above discuss the problem and some ideas for solutions in terms of the Squeezebox display and the web interfce. I think things could be done much better with a real GUI interface. iTunes allows you to customize the columns it displays in the main track listing. The 3 browser windows at the top seem like a good solution to me but I can't add a window pane for browsing Composer.

In an earlier message, you mentioned the current Slimserver database. As I mentioned in a message in one of the threads listed above, I think you could collect all the ID3v2 and VorbisComment tags in the music files and put them in one simple table with fields like (primary key, reference to track table, tag name, and tag value). The only processing needed before storing the tag information would be to replace short codes like "TCOM" with a full name like "Composer". Browsing and searching could use all tags in a first class way with simple regular Select statements. And it would be straightforward to let the user choose which tags to display in the track listing and the browser windows.



It currently uses the VORBISCOMMENT fields from the FLAC header; if this is what you mean, then it already works.

That's what I meant. Thanks.

----
I think that having a modern GUI interface would make the Squeezebox more useful for me and more attractive to a wider market of customers who just want to play music. I hope your project succeeds. Perhaps I could help in some way.

Bill