Hi folks,

tRio now has a SourceForge presence. See http://triot.sourceforge.net/index.htm. We are still struggling to get it working with RioBoot, but otherwise it's starting to look good.

Cheers
Paul

Folks, in case you haven't worked it out, clicking in the link in my previous post doesn't work because of the dot on the end. This will work: http://triot.sourceforge.net/index.htm

This looks really promising, great job so far.

First, my usual comment... can you include HPNA support?

That said, I went ahead and substituted another kernel/il-binary in the meantime and it seems to work. I'm seeing some screen corruption and playback is a bit jerky. Are others seeing the same? Is there anything special in your kernel?

By the way, I am using RioBoot on Win2k. The only problem other than the usual replacing of /dev/* are all the symbolic links in bin. Just replace them with copies of busybox.

Dave,

I'm afraid I've been hacking away at the audio drivers like a trojan, and so you'll definately need my zImage (it does some special IOCTLs to find out exactly where we are playback-wise quite often - that's probably where your skipping is comming from).

Please let me know whats required for the HPNA support. Or otherwise use my versions of the audio stuff in the kernel sub-directory (place them in drivers/char) and my empeg7212.h (can't remeber where it goes, but it sounds like you know what you're doing).

The screen corruption is something I'd like to get a handle on though. Could you please PM me with your machine spec (os, cpu, memory) and a copy of your trio.xml and I'll look into it from there.

Cheers
Paul

I'm having trouble getting past the tRio "Waiting before retry" splashscreen. I'm running JReceiver 2.3 on Redhat 8.0 and tried both JReceiver options in the config file. I think my DHCP server is OK since I can run the old receiver.arf just fine when its in my /tftboot/192.168.1.xxx directory.

Any suggestions?

Franky

Hi!

The spec sheet look promising!

I tried to setup my win2k with original server but I can't get past the "waiting before retry" message.

Here's are a few observations:

- In installation manual you ask to replace in trio.xml f:\dist\ by installation directory...There's no f:\dist\ but there's f:\code\ so I replace all of them with my installation directory. Is it ok?

-Still in trio.xml, should I change the broadcast address to my local network? ie my ip are 192.168.0.11 for the server and 192.168.0.23 for the receiver, should i change broadcast to 192.168.0.255 instead of 1.255???

- In trio.bat, there are two possible lines to launch trio host.. the first one is not supposed to create a window on the host PC BUT when I use it, it creates a window which stops at "creating UDP socket. local port 19680, timeout: 15000"
Is it normal?

Included is a copy of my trio.bat and trio.xml, if ever you need them to help me

EDIT: Is there any way to attach? if not, I can email if needed


Thanks!

Patrick Giasson

Disregard attachement question, just found how:

In the empeg forum, the "preview post / attach" is checked by default, that's what suprised me here..


So here are my settings

Regarding your question about the broadcast address:
Here is mine, My MP3 server is a multihomed machine. The Nic the Rio is connected to is IP 192.168.2.41 on the MP3 Server. This works. I have been beta testing with Paul.

I hope the example helps steer you in the right direction.

<application name="player" title="Player" scope="global" class="trio.player.TRioPlayerApp" menu-server="jrec" content-server="jrec" send-method="broadcast" broadcast-address="192.168.2.255" multicast-address="230.0.0.1">

<servers>
<server name="arm" title="Audio Receiver Manager" descr="Origional software supplied with Rio Receivers" class="trio.player.TRioPlayerARMServer" url="http://192.168.2.41:12078"/>
<server name="jrec" title="JReceiver" descr="Open source audio server - hosting the Rio and beyond" class="trio.player.TRioPlayerJRecServer" url="http://192.168.2.41:8080/jrec_serv/servlet/RPC2" user="trio" password="XXXXXXXX"/>
</servers>


As for the TRIO.BAT question. Both lines will open a DOS screen that needs to stay open (at this time). The second entry (the one not marked as "Silent"), will start a java screen emulating the display of the Rio when the rio iis active.

Use the first section in TRIO.BAT (the one marked "Silent") as it takes less memory.

Hope that helps.

Franky,

When you get the "Waiting for retry" thing, it's usually a network/DHCP configuration issue. In tech-speak, what the tRio s/w on the Receivers does is Broadcast a request on port 19680 to find a tRio server. This fails if it doesn't have a 255.255.255.255 entry in its routing table.

The reason its working with your old receiver.arf is that it doesn't use broadcasts in this way. Would you mind mailing me your dhcp config file (/etc/dhcpd.conf on my suse machine).

Cheers
Paul

Patrick,

Firstly your trio.xml looks just fine - I'll fix that thing about f:\dist vs f:\code in the instructions.

About the "waiting for retry", it looks like you're having a similar problem as FrankyG (see his post above). Are you running your own DHCP server on your machine, or are you leaving that up to the Audio Receiver Manager software?

If you are running your own, please let me know what your settings are for your Receiver(s).

Cheers
Paul

I'm running the official software for now, so default DHCP

It seems it's ok, because I can see the receiver in "Audio Receiver Manager" with a valid IP. Also, if I can get the "waiting before retry" message, doesn't it mean that it found the server and the receiver.arf??

Still searching...

Patrick

Don't know if it's normal:

trio.bat seems to call a file that doesn't exist in my %java_home%\lib folder

java -X"bootclasspath:%TRIO_HOME%\lib\pja-mod.jar;%JAVA_HOME%\lib\rt.jar" -Dawt.toolkit=com.eteks.awt.PJAToolkit -Djava.class.path="%JAVA_HOME%\lib\tools.jar;%TRIO_HOME%\lib\trio-0.1.1.jar;%TRIO_HOME%\lib\commons-logging.jar;%TRIO_HOME%\lib\commons-beanutils.jar;%TRIO_HOME%\lib\commons-collections.jar;%TRIO_HOME%\lib\commons-digester.jar;%TRIO_HOME%\lib\commons-lang.jar;%TRIO_HOME%\lib\jrcommon.jar;%TRIO_HOME%\lib\jrutil.jar;%TRIO_HOME%\lib\jrclient.jar;%TRIO_HOME%\lib\xmlrpc.jar" trio.TRioServer "-c%TRIO_HOME%\trio.xml"


tools.jar is nowhere on my hdd... is it normal?

All other referenced filed can be found at their supposed location (TRIO_HOME or JAVA_HOME)

Patrick

Patrick,

Don't worry about the tools.jar thing - it's not required - remove it if you like, but there's no harm in leaving it in there.

Regarding your "Waiting to retry" problem, you're right that it is managing to find and load tRio's receiver.arf. But there must be some wierd network problem that's stopping it getting through to the tRio server. Could you please check the following for me:

1. Although you're using the origional sw, are you sure you're not running a seperate DHCP service.

2. Do you have a firewall running? If so, is anything coming up in its logs? Maybe give it a try with the firewall down, but don't forget to bring to back up again.

3. Are your Receiver(s) and Host PC on the same sub-network? If not, then this would explain it.

4. Is there anything else unusual about yout network set up? Wireless router or the likes?

5. Could you run a "netstat -r" from the windows command prompt (or DOS window) and send me the output.

If all this fails, I'll have to send you a special debug version of receiver.arf. I'll load this onto the download page this evening (GMT), but hopefully you won't have to use it.

Sorry you're having such a time of it.
Paul

You really know what you're talking about!!

I've got a linux box with DHCP enabled (from when I tried Jreceiver). Altough it managed to work, I didn't understand why my receiver got a IP outside the range the manager was told to...

Trying trio now....

Looking good so far

Thanks for your help!

Patrick

Patrick,

Glad to hear you're getting places at last. Would you mind sending me the DHCP config from your Linux box so that I can have a look. There's no reason why tRio won't work with a DHCP server and I'd like to pin-point the problem. (My DHCP config is in /etc/dhcpd.conf.)

Cheers
Paul

Here it is...

Be aware that I'm not very good and there may be some errors, but when I tried JReceiver, it worked well...


Patrick

FYI,i tried jreceiver 0.2.3 but the client chokes and gets stuck on 'buffering'. jreceiver shows a message about 'being out of memory', this may be because my database has 50K songs or the the 2000 limit that jreceiver implements may not be working.

Have moved to original sonic receiver manager, imported 25k songs. works so far (no volume control).

bill

Bill,

This is interesting. When you say it gets stuck on 'buffering', does this mean that you manage to get through the music menus okay?

1. How many different artists do you have and how long do you wait then you select the Artist option from the menu?

2. And the same for albums?

When you say you have no volume control, have you tried turning the wheel from the Playback Panel. But yes, the Volume buttons on the remote need to be hooked up - not a big job.

Cheers
Paul

I am trying to use this with RH Linux 7.2, JReceiver 0.19. I am able to get to menus to select music, can select a song, but am unable to play it. When I press play, I get a 'buffering' message, and this on my console:

### startPlayback. streamStatus: 0, pbStatus: 0
PlayerStream (/192.168.0.128) - streamStart()
Bad music server http response opening tune connection: 503: Service UnavailablePlayerStream (/192.168.0.128) - sent Purge(). dataLen: 0
PlayerStream (/192.168.0.128) - discarding DataRequest - tuneSeqNo mismatch. tuneSeqNo: 0, startTuneSeqNo: 4, streamTuneSeqNo: 4
PlayerStream (/192.168.0.128) - discarding DataRequest - tuneSeqNo mismatch. tuneSeqNo: 0, startTuneSeqNo: 4, streamTuneSeqNo: 4
PlayerStream (/192.168.0.128) - discarding DataRequest - tuneSeqNo mismatch. tuneSeqNo: 0, startTuneSeqNo: 4, streamTuneSeqNo: 4

Also, do you have a tRio.sh for linux yet? I jerry rigged one, but I am not sure it is working completely.

Lastly, has anyone got this to work with Linux?

I got it to work with Solaris, so, yes, to what I assume your question actually is. I've got a pretty good trio.sh, but I can't get to it right now (it's on the other side of my currently defunct DSL line). I sent it to Paul. Maybe he'll be nice enough to post it here or elsewhere.

Appologies to Bitt and Shawn for omitting to include their scripts in the distribition. Please find Bitt's attached, but I'll include both in the next version.

As for your playback problem, could you please send me a copy of your trio.xml and I'll have a look.

Cheers
Paul

Also note that I had to use Java 1.4.0. Not 1.3.x, 1.4.1, or any other version. It had to be 1.4.0.

Thanks for the script. I also am using Java 1.4.0. I have attached my trio.xml

Oh, and Paul, it's ``original'', not ``origional'', as you frequently spell it in the docs and config files.

Well .. after a few false starts with tRio .. I made some progress [not working yet though.]

running readhat 7.2 , jreceiver 2.4

Here are a few suggestions first :P
1. include linux/unix trio.sh and trio.xml files
2. link to this message board or at least post the link .. SOMEWHERE on your sourceforge website.

now . I had a false start initially .. I thought it was my .sh file .. or bad xml or something . but it turns out that I was running jre 1.3.1_02.

after installing j2re 1.4.0_03 last night .. I was able to get tRio to boot up. I was then able to connect to the server and generate playlists (which i think is a particularly COOL idea .. the interface takes a little getting used to .. and the screens are painful .. but I can modify the screens :P)

however .. I was unable to actually PLAY anything.
It choked .. just sat there.

out of frustration .. i restored my .arf in tftpboot/ip# for all 3 of my receivers just to make sure jreceiver was working ok. it was.

One wierdness I should report .. I turned off jetty, restored my .arf and restarted jetty .. but the one rio I was using as a test box continued to try to find the tRio .. it just kept cycling between the looking for music server / found music server / *FREEZE* / rince-lather-repeat.

I physically unplugged the receiver for about 15 mins and that seemed to do it. [I had unplugged it for 40 seconds and about 2 mins .. and that didnt touch the problem]

just posting that last bit so if anyone tries to revert .. they don't freak out

Hi,

Sorry to hear you're have a rough time of it. I'm going to PM you to find out the details of your problem rather than clutter up this thread.

Cheers
Paul

I was having the same problem with it hanging when attempting to play it. I was getting a 503 error to to a java.lang.OutOfMemory.Error. I changed my jetty.sh file to include a line to increase java heap size like this:

JAVA_OPTIONS="-Xms16m -Xmx128m"

I am using JReceiver 0.1.9. Currently it only works for one Rio at a time, and I still get intermittent 503 errors. I also haven't really figured out the optimal amounts of memory to allocate. Finally, the application seems to be quite CPU intensive (I'm running it on a Celeron 1.1GHz and I go from ~15% to ~75% usage).

Is anyone else finding excessive CPU figures like this? On my dual PII 400 system, the CPU is usually less than 5% during "normal playback". If I scroll madly through the menus then this goes up to between 10 and 20%.

I wonder it this isn't caused by your JRec 0.1.9 issues. Let's see how it looks when we've got you sorted out.

Cheers
Paul

Great job on trio. The synching of rios is just awesome. I got it up with ARM very easily. I'm going to try jrec as teh artist/album thing is something I have been wanting for a long time.

Two quick questions:

1. I have 3 rios, how do I name them. Right now they come up as recevier 1, 2, 3 in trio.
2. is there/will there/can there be a way to order the songs by album/track instead of alpha? I have always hated the alpha sort thing.

Thanks, and great job.

Hi,

To rename your Receivers, close down tRio and then edit trio.xml and change the <unit> entries. You should find something like this:

<unit ip="192.168.1.6" type="receiver" name="Receiver 1"/>

Just change the name= bit to what ever you want.

On the track order thing, it's been working for ages via JReceiver - but it's not possible via ARM.

Cheers
Paul

I'm having the "waiting for retry" problem, too. I'm using:
Win2000 domain with Win2000 DHCP server, server machine ip 192.168.16.2 (it's also the gateway to the net).
WinXP for music server (DHCP assigned IP 192.168.16.17)
Java SDK 1.4.1_01. (has anyone gotten this to work with this version of Java?)
Original RIO server software.
RIO and Music server box both plugged in to Netgear 8 port switch (not a hub, a switch).
New server software installed at "c:\program files\trio-0.1.1"
Tweaked trio.xml to replace "f:\code" with "C:\program files"
Changed server ip in trio.xml to 192.168.16.17, didn't change the ports.
Changed broadcast-address to 192.168.16.255
multicast address still 230.0.0.1
replace receiver.arf.

Rio boots with the new .arf, it displays a trio splash screen.

TRIO server starts with the following output
Start of TRioServer
Start of ClockApp thread
Loading TRioPlayerLayout: scrolling
player app - Starting TRioUnit App thread
ImageTranslation: byte-binary
Creating sockets
creating udp socket. local port: 19680, timeout: 15000


ipconfig on the music server shows:
Ethernet adapter Local Area Connection:

Connection-specific DNS Suffix . :
IP Address. . . . . . . . . . . . : 192.168.16.17
Subnet Mask . . . . . . . . . . . : 255.255.255.0
Default Gateway . . . . . . . . . : 192.168.16.2

finally, netstat -r on the music server shows:
Route Table
===========================================================================
Interface List
0x1 ........................... MS TCP Loopback interface
0x2 ...00 08 a1 12 c0 50 ...... CNet PRO200WL PCI Fast Ethernet Adapter - Packet Scheduler Miniport
===========================================================================
===========================================================================
Active Routes:
Network Destination Netmask Gateway Interface Metric
0.0.0.0 0.0.0.0 192.168.16.2 192.168.16.17 20
127.0.0.0 255.0.0.0 127.0.0.1 127.0.0.1 1
192.168.16.0 255.255.255.0 192.168.16.17 192.168.16.17 20
192.168.16.17 255.255.255.255 127.0.0.1 127.0.0.1 20
192.168.16.255 255.255.255.255 192.168.16.17 192.168.16.17 20
224.0.0.0 240.0.0.0 192.168.16.17 192.168.16.17 20
255.255.255.255 255.255.255.255 192.168.16.17 192.168.16.17 1
Default Gateway: 192.168.16.2
===========================================================================
Persistent Routes:
None

Any suggestions?

I've replaced Java runtime with 1.4.0_03, but that didn't do the trick (at least not by itself).

I then shut down my Win2K DHCP (and physically unplugged it from the network to make real sure I wasn't getting an address from it) and turned on the DHCP from the default RIO server. It now works. What I need to know now is how to find out what the difference between the Win2K and the RIO DHCP server is. A way to see what DHCP settings the RIO got would be very useful. Keeping my Win2K DHCP server shut down is not a viable long term solution.

The synchronous playing is awfully cool. A little delicate (the units easily get confused, or locked, or stop making sound although the screen still shows the song playing and the time ticking away, or I've also managed to steal the lead away from the "master" rio to one of the "slaves" several times).

One issue I have is that I usually use a home built music server that I can run as a Win2K service on my domain controller. That way, my music works without anyone needing to be logged in, and autorestarts after a power interruption. Anyone know of a way to run a java application like this as a service on win2k? Failing that, is the interface between the trio client and server documented? As a last resort, I could (yech) reimplement the server as a C++ app that I could fold into my home brew server.

One final note is that this is working also for 2 receivers that are NOT on the same switch as the server, but are daisychained one switch away from the server.

Anyway, great job!

Hi,

Yes, shutting down the local DHCP server seems to solve the "waiting before retry" problem 9 times out of 10. The problem is to do with the code on the Receivers getting a "host unreachable" error (or something similar sounding) and I think it's because your DHCP config is not supplying the correct routing table entries for the receiver. The answer may be to set the "default router" to your server box.

Yes, the syncing is a bit tempramental and needs to be made more robust. I tracked down one bug with it today, but I'm sure there are many others. Hopefully by v0.1.3 it'll be more stable.

I have had tRio running as a Windows Service before (have a look in the /bin directory - but it's very out of date). It uses a product called JavaService (see http://www.alexandriasc.com/software/JavaService/index.html ) which is free.

Let me know how you get on with the DHCP stuff

Cheers
Paul

Well your running Win2k..

Use SRVANY.EXE from the W2k Server Resource kit.. I use it to make my JRec and othe java apps run as services. Just do NOT logon as the account you use to run those services. If you do, then logout.. The services stop..

Now that was the FREE way..

The Small cost, but more reliable and configurable is to use FireDaemon. Its like $25.00 and much much more configurable.

Go http://www.firedaemon.com/ for firedaemon

Paul, I've gotten past "waiting for retry" on my linux machine by messing sound with the dhcpd.conf as you suggested. On linux I now getting the menus to come up correctly but can't play anything. I get "tune mismatch" errors.

Anyway I switched over to using trio/jreceiver on XP and am getting a similar errors. Rio just hangs on "buffering" and I get this message on my PC:

WindowManager (/192.168.1.103): windowDeactivated
WindowManager (/192.168.1.103): windowDeactivated
WindowManager (/192.168.1.103): windowDeactivated
### startPlayback. streamStatus: 0, pbStatus: 0
PlayerStream (/192.168.1.103) - streamStart()
Bad music server http response opening tune connection: 404: Not Found
PlayerStream (/192.168.1.103) - sent Purge(). dataLen: 0
PlayerStream (/192.168.1.103) - discarding DataRequest - tuneSeqNo mismatch. tuneSeqNo: 0, startTuneSeqNo: 2, streamTuneSeqNo: 2
PlayerStream (/192.168.1.103) - discarding DataRequest - tuneSeqNo mismatch. tuneSeqNo: 0, startTuneSeqNo: 2, streamTuneSeqNo: 2
PlayerStream (/192.168.1.103) - discarding DataRequest - tuneSeqNo mismatch. tuneSeqNo: 0, startTuneSeqNo: 2, streamTuneSeqNo: 2
WindowManager (/192.168.1.103): windowDeactivated

Any idea what is going wrong?

Your real problem here is the "Bad music server http response opening tune connection: 404: Not Found". My initial guess is that your menu-server/content-server setting aren't quite right - need to be the same setting for both.

PM me a copy of your trio.xml and I'll have a look.

In the mean time, I'll beef up the error handling in this area to produce something more obvious looking.

Cheers
Paul

OK, I went back to the jreceiver logs and found the problem. I think jreceiver and the Audio Manager both were fighting over port 8080. I moved jreceiver to port 8081, updated trio.xml, and I got it working. Browse by artist then by album is what I've been looking for a long time. Only problem I see now is Album/Artist Name area on the display is just one solid block of pixels.

Now back to getting this working on Linux.
Thanks

The DHCP request the DAR makes does not include a Parameter Request List. Therefore, the DHCP RFC makes clear that the DHCP server is pretty much able to return whatever parameters it feels like. The Win2K DHCP server doesn't choose to return the table of routers. I can't find a way to force the Win2K DHCP server to return unrequested data in the options field of the DHCP message. The recommended fix for this situation is for the client to add a Parameter Request list.

I don't know much about the code in the client; I'm a Win32 coder, I don't know much Linux. However, I believe that the DHCP request is in the boot code in ROM, and so can't be touched. Can anyone suggest a work around to this? Not running the Win2K DHCP server isn't an option; I have to maintain the Win2K domain. Is there a way to get the trio client to make a different kind of broadcast? Perhaps do another DHCP request, this time including the Options Request List? Anyone have any suggestions. I'm willing to do a lot to get this working, but as I said, I'm not a Linux coder.

Oh, by the way, I find the scrolling display to be probably even cooler than the syncronized music. I use a homebrew music server because I have a lot of classical music in my collection and so make a lot of use of the ID3v2 fields "composer" and "conductor". Another effect of having lots of classical music is that my track names tend to be VERY long, like "Concerto for Flute, Harp, and Orchestra 'Pastorale': Movement 2: Andantino", and stuff is constantly too long to read on the DAR.

I *think* the setting that makes it work in my Linux dhcp config is: option routers 192.168.1.1 . The equivalent might be "default router" or "gateway" in NT-speak. But I could well be wrong.

On the scrolling banner side, have you noticed that it looks better if you turn the brightness up on the display. A setting of 54 looks good on mine. BUT BE WARNED: one of my LCDs has started to look a bit faded and I'm not sure if it's because I turned the brightness up too high. SO DO THIS AT YOUR OWN RISK.

Cheers
Paul

I PMd you to continue this. It's getting pretty long here.

>I PMd you to continue this. It's getting pretty long here.

Please keep us updated on the progress as I have the same issues ie. need to keep the 2K DHCP server.