Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Topics - magog

Pages: [1]
Edit: There seems to be an issue with Java 1.4.2 from Innotek. At the moment Subsonic works with Golden Code Java 1.4.1 only! I've not yet rechecked if Tomcat would help to get around the issue Innotek Java.

Edit2: The second modified Subsonic drop (15th. Feb. 2008) includes the work-in-progress Extended Search I'm working on. This should allow you later when it's finished to search other subsonics friends have running when you are logged in to your own subsonic. Includes sophiticated user management so not everyone is allowed to search other subsonics.
Details described in this thread at the subsonic forum (includes screenshots):

Beside that this version also fixes the not working transcoding (conversion e.g. OGG to MP3) and recoding (lowering bitrate to save bandwidth).

There is a Streaming server based on Java available called Subsonic.
This application allows you to store all of your MP3, OGG,... files and allows you and other people (login has to be created) to access your music files.
The selection of albums you want to listen to is done in your webbrowser. Then the server sends an MP3 Stream (Shoutcast == MP3) to your music player (eg. z! or PM123 on OS/2, WinAmp on Windows,...).
You can find more details at the subsonic website:

Normally the computer (server) running Subsonic requires to have Java >=1.5 but I did again a hack so most of the important functions are working on OS/2 and eComStation with either Innotek Java 1.4.2 or Golden Code Java 1.4.1 only.
I'll fix some of the issues as good as possible with the upcoming test versions but for now you might want to try the current version.

Here are the issues I found so far:

  • I had a problem to get the podcast from another website (don't know if the problem is only related to the page I tried or a general problem). The error was about the regex library (I think this is not included in Java 1.4.1 I tried...might work with Innotek Java 1.4.2 once the general problem with it is solved)
  • Search didn't show any results... EDIT: Had to start the indexing process manually as I didn't run it long enough so the automatic reindexing could start at 3:00 AM (see "Settings" --> "Search" at webinterface).
    The status on the left with the amount of artists, albums,... will also be updated once the indexing seems to be complete (may require an additional restart of jetty).

Beside the basic "subsonic.war" file you need a webserver which can be either Jetty (current version 6.1.7) or Tomcat 5.x! I suggest you try Jetty as it's very easy to install and use.
After you downloaded Jetty you can extract it everywhere you like. The subfolder "Jetty-<VERSION>" will be created automatically.
Get the ZIP of Jetty 6.1.7 here:

My special "subsonic.war" for Java 1.4.x can be downloaded here:

Later the current version can be found on my website ( - at section: "Projects" --> "Ports")

You need to extract or copy the "subsonic.war" file into the subdirectory "webapps" of Jetty.
Then remove the "cometd.war" from the "webapps" subdirectory. This is causing some problems as it's not compiled for Java 1.4.
By default Jetty uses Port 8080. The port can be changed at the Jetty.xml (see documentation) configuration file.
Here is the start script (startJettyOS2.cmd) I use to start Jetty (with Golden Code Java 1.4.1 installed at c:\java141):
Code: [Select]
mode 102,80
c:\java141\bin\java -jar start.jar

The mode line is optional but will show some more lines what Jetty and Subsonic are currently doing.
I you want to use Innotek Java 1.4.2 it might be enough to remove the path completely (if set as default Java environment - eCS 1.2+ default setting) otherwise you need to specify the location of the Innotek Java version (normally "C:\Programs\Java142\bin").

That's all you have to do. Then you can open your webbrowser. If you have started Jetty on the same machine you are now starting your browser enter the URL "http://localhost:8080/subsonic", or if it's another machine on you network you have to enter the IP address instead of the word "localhost". The port has to added except if you set it to port 80 instead of 8080.
If you just use "http://localhost:8080/" you will see the Error 404 together with a list of possible links to web-applications. One of them should be called "subsonic" if you then click on this one you get to subsonic as well.

You should see the Jetty login dialog. At the first time you can use "admin"/"admin" as login but then you should change the password of the admin user. While you are logged in you might also add other users.
Then of course it's time to setup the location of your mp3 files, the default upload path (location of the "incoming" directory if someone uploads files to your server),...

Finally you are ready to stream the music files that are stored on your system. You can select the files/albums with a click at the webinterface and then your music player should be started to play the stream send by subsonic. You might need to add the music player as "Helper application" so it will be started automatically.

Subsonic can also reduce the bitrate of the MP3 files and covert from one filetype to another (eg. OGG-->MP3) but needs external apps for this. So far I've not tried this, but LAME is one of the required 3rd party tools needed.

Ok, now I'm looking forward to hear some success stories. ;)

General Discussion / New Bounty @Kim
« on: 2007.08.01, 19:18:44 »
Hi Kim,

I sent a new Bounty suggestions via the form. Did you get it or do I have to type the "long" message again (I hope I don't have to).

Some hours after I did that I saw the announcement to use the forum instead because of spam.
It would be a good idea to remove the form completely if it shouldn't be used.


Last week I've found the project SWTSwing at
The goal of this project is to implement the SWT GUI-Framework using standard Swing components.

First I will lay things out for you and then I'll post a message from Christopher Deckers the main person behind SWTSwing. Before I talked to Christopher I got in contact with Dieter Krachtus who is working together with Christopher on the Eclipse on Swing project (EoS;
I got an older SWTSwing version from him, so I could execute the Paint example (see EoS website) on eComStation. After I got that working I began to spent some time with the Azureus code and created my own Azureus build. Together with the help of Retroweaver, which adds some functionality that has been missing in Java 1.4 but is available in Java 1.5 and Dieter's SWTSwing version I was able to start Azureus on eComStation. I even got to the main window (at the first tests it did stop at the end of the splash screen).
Here is a picture of Azureus running on eCS 2.0rc1 (I did post this 3 days ago at - german discussion forum):

You can get the full sized version here:
The application itself is not usable (see error messages in the background 4OS2 command line window)

So we are now back on the SWTSwing topic
Why is this project so important for us?
  • SWT is used for two applications everyone know...Azureus (Bittorrent Client) and of course Eclipse (Integrated development IDE for Java, C,...).
  • SWT has to be ported to every target platform (for example eComStation and OS/2)!
  • We currently don't have a working SWT port on eComStation and OS/2!

Ok, we don't have a working SWT port but there is work in progress. The push the project became last year did came to a stop around December 2006 and seems to be re-actived since about 5 weeks. Before we see a working SWT port there is still a lot work that needs to be done if it will be finished ever.

If you look at the wxWidget developers that are working for years now and what problems they still have you might get an idea how hard it is with very limited resources to get it working. Currently the wxWidget guys have problems with GCC 3.3.5 and also Open Watcom. Open Watcom doesn't support the required C functionality and it's the same with GCC. wxWidget is using more and more Unicode which is also causing problems. The other GUI Framework is Qt, we have a working Qt port, but it's also outdated (current eCS and OS/2 version is 3.3.1 and it's not a complete port -; Trolltech is currently using version 4.3.0 -

I can't blame any developer working on the stuff above. They are working on it in their free time and they don't get paid for it...ok the qt3 development may be supported a little bit by Maybe Adrian might tell us something if we ask.

SWTSwing seems to be very far in it's development as you can see when you look at the screenshots on the website. SWTSwing uses standard Swing that is part of Java since version 1.2 (was an additional package in Java 1.1.8 but maybe only because of IBM)
I don't know how many people beside Christopher and Dieter are working on SWTSwing, but what they did create so far is incredible!

Great so we can use SWTSwing to get applications running that require SWT?

No that's unfortunatley not possible because of two reasons:
  • SWTSwing is currently not Java 1.4 compatible, and we don't have access to newer versions of Java on eCS and OS/2
  • The application that's using SWT also has to be compatible with Java 1.4 as well

It may be possible to get them involved to add Java 1.4 compatible checks but we may need some developers that could work on this project. Even some users testing it would be VERY HELPFUL.
Another motivation might me our Bounty system!
I hope you all hear me. :)

I asked Christoper a few questions and this is what he said...
Hi Juergen,

Well, I knew this compatibility discussion was to come up some day.
Maybe discussing it further may help me find a solution.

A bit of background first. SWTSwing is quite a challenging project:
SWT is a moving target, and has a lot of advanced native-like
features. It brings competition to Swing, so Swing usually tries to
follow whatever SWT has, but of course with the delay implied by
waiting for a new JRE. This is why, to achieve a most complete
coverage of the SWT API, I need the latest official JRE. To give a few
- Absolute mouse location at any time (java 5)
- System tray support (java 6)
- Irregular shaped windows (planned for Java 7, I am waiting for it)

Compatibility concerns two aspects: using new constructs (generics,
enums) that imply a certain bytecode version, and the use of methods
from certain JREs.
Keeping track of compatibility is a really hard task. I did that
several times in the past and I know the various issues around it.
This is why I originaly decided that SWTSwing's goal would be to cover
a maximum of SWT, rather than supporting legacy JREs. On the other
hand, I knew there would be a need for these legacy JREs, so I set the
binary compatibility to Java 1.4, and never use 5.0+ constructs. This
allows an easer backporting of SWTSwing to earlier JRE versions by
external parties.

> After that I also tried to get Azureus working using the SWTSwing version from
> the Paint.jar. I recompiled Azureus for Java 1.5 and used Retroweaver to patch
> the bytecode to make it mostly Java 1.4 compatible.

I thought Retroweaver would just downgrade new Java 5 constructs to
Java 1.4. Since I use Java 1.4 compatibility, where does Retroweaver

> Dieter told me that the old compatibility with Java 1.5 has been removed from
> the current SWTSwing code.

It is not that it was removed, it is just that I could finally
implement more of SWT using Java 6, and get big applications like
Eclipse to work better.

> Is there any chance to get Java 1.4 compatibility back into SWTSwing.

Well, I have to do a bit of downgrades for Java 5 compatibility at
least. That means, as long as you don't use certain SWT calls that
definitely require a Java 6 API, the program would not break. Now,
what would happen if you launch a program that does call such API
(like Azureus using the system tray)? There are two approaches: let
the program break, which means SWTSwing would be useful for programs
making the checks themselves, or handle those cases to return default
values. The latter requires compatibility checks in the code itself,
or special downgraded releases of SWTSwing.

> Dieter is
> currently thinking about this and maybe he has already an idea.
> I would say a parameter like "" but maybe it's sometimes
> easier to at a try..catch around Java method calls to catch
> "java.lang.NoSuchMethodError" and execute a Java 1.4 compatible call if
> available (for example usefull for the "setLocationByPlatform()" method call -
> only used in two *.java files right now).

The version you have may be enough for a paint application, but can't
run Eclipse properly. I put a lot of work in what's currently in CVS,
and there are probably far more calls that require a later JRE.

> Having SWTSwing working on eComStation would be appreciated by a lot of people
> as we don't have a native SWT implementation (even if the work on a port has
> been restarted recently).
> Currently we can't use a great applications like Eclipse, Azureus and other
> popular Java applications. A Java 1.4 compatible version SWTSwing would be very
> helpfull to make those applications work.

Now we touch the important aspect of this issue: to know if
compatibility handling is worth the trouble. I would love to learn
more about who still use OS/2, or Java 1.4, and evaluate if I should
spend some time on this support or let that to external parties.
I originaly mentioned to Dieter having AOP using external pointcut
definitions in order to avoid damaging the code with compatibility
checks, but I know it would not solve all the cases.

If you can give me more insight as to where such compatilibity would
be useful, and if you are willing to help testing a few dev versions
in case I implement anything, then I may handle it in the code itself.
In the meantime I will think about it to try to find a clean solution
in case I decide to go for it.


Pages: [1]